The source site stays the reference until the new copy passes QA
We do not point DNS at an untested destination. The target environment is prepared, the site is copied and critical functions are checked before the public cutover.
WORDPRESS MIGRATION / PERTH, WA
Move WordPress to a new host, domain or platform without treating migration as a copy-and-pray exercise. We stage the move, preserve URLs where possible, map redirects when they change, protect forms and integrations, plan DNS cutover and verify the live site after the switch.
full files + database backup before transferstaging copy tested before DNS cutoverURL inventory + redirect map where paths changeforms / analytics / checkout verified after launch THE RISK IS NOT COPYING FILES — IT IS WHAT CHANGES AROUND THEM
A migration touches more than wp-content and a database. DNS, SSL, PHP versions, email delivery, forms, caching, analytics, redirects and third-party integrations can all behave differently after the move. We inventory those dependencies first and build the cutover around them.
We do not point DNS at an untested destination. The target environment is prepared, the site is copied and critical functions are checked before the public cutover.
If domain names, slugs or platform structure change, we create a redirect map and verify that important old URLs resolve to the closest relevant new destination instead of dropping users into generic 404s.
WooCommerce orders, memberships, bookings and form submissions can change while the copy is being prepared. For those sites we define a maintenance window, content freeze or final database sync strategy before cutover.
Most providers publish TTL and DNS changes that can take from minutes to many hours to fully propagate. We lower TTL in advance when practical and verify both old and new endpoints during the change.
KNOW WHAT MUST MOVE BEFORE TOUCHING DNS
The pre-migration audit records the source environment, data size, WordPress dependencies, URLs and business-critical functions so the destination can be tested against a known baseline.
Record the current host, PHP/runtime, WordPress version, theme, plugins, cron jobs, caching layer and any host-specific features that may not exist at the destination.
Measure the site footprint and confirm that the backup contains the database, uploads, active theme, required plugins and configuration needed to recreate the live application.
Capture indexable URLs, important landing pages, canonical patterns and current redirects before a domain or platform move changes how those URLs behave.
List the functions that must survive the move: enquiry forms, SMTP, GA4, Search Console, CRM, payment gateways, shipping, bookings, maps, feeds and API connections.
COPY TO THE NEW ENVIRONMENT BEFORE THE PUBLIC SWITCH
A host-to-host move is staged and verified while the source remains available. The destination is configured for the actual site instead of assuming every WordPress host uses the same PHP modules, cache rules or server limits.
THE DOMAIN MOVE IS ITS OWN CHANGE PLAN
Domain, DNS and hosting are related but different systems. We map the records that actually control the website and avoid changing unrelated mail or verification records unless they are in scope.
Point the domain or subdomain at the new server only after the destination passes staging QA.
Preserve or update aliases used by www, CDN endpoints or platform-specific hostnames.
Do not overwrite MX records during a website-only migration unless email migration is explicitly part of scope.
Retain email-authentication, Search Console and third-party verification records that are unrelated to the website origin.
Provision and test HTTPS on the destination before or immediately around cutover so canonical URLs remain secure.
Lower TTL in advance where practical, then monitor both old and new endpoints while resolver caches expire.
MOVING TO WORDPRESS IS A CONTENT-MAPPING PROJECT
Wix, Squarespace, Shopify, Joomla and older proprietary systems do not map one-to-one into WordPress. We separate content, URL structure, media, forms and platform-only features so the new WordPress build preserves what matters without blindly recreating every limitation of the old system.
TRANSFER THE DATA, THEN PROVE THE APPLICATION STILL WORKS
Migration QA checks the transferred content and the application behaviour around it. The goal is not simply that WordPress loads, but that the destination contains the expected records and serves the assets and functions the business uses.
Migration work is delivered remotely across Perth metro. We can scope host changes for professional firms in Perth CBD and West Perth, larger media libraries for Osborne Park and Midland businesses, hospitality sites around Fremantle, and transactional WooCommerce sites serving Joondalup, Cannington, Wanneroo and Rockingham.
Use WordPress-aware search/replace methods where domains or paths change so serialized values are not corrupted by raw database replacement.
Check featured images, galleries, CSS backgrounds and downloadable files because a database can import correctly while media URLs still point at the old host.
Verify forms, ecommerce, bookings and other plugins that create their own tables rather than assuming wp_posts contains everything important.
Correct destination permissions where uploads, updates or caching fail because transferred files belong to the wrong server user.
Re-test form notifications and SMTP after migration because a new server, IP or DNS environment can change how outbound email behaves.
Purge source-era caches and regenerate destination caches so old domains, paths or stale HTML do not survive the move.
SEO PRESERVATION IS A URL-BY-URL RESPONSIBILITY
A migration can preserve rankings only when the signals that search engines rely on are deliberately carried forward. We record important URLs, map unavoidable changes, retain canonical intent and verify the result after launch.
Capture indexable URLs, status codes, canonicals and redirect chains before the migration so there is a reference set for post-launch comparison.
Output: source URL inventoryCreate one-to-one or closest-relevant 301 mappings for pages whose paths or domain change. Avoid redirecting unrelated legacy URLs to the homepage.
Output: approved redirect mapCarry forward titles, descriptions, headings, canonicals and structured content when the migration is not intended to rewrite them.
Output: SEO preservation checklistReplace internal links, media URLs, canonicals, sitemap references and structured data that still point to the old hostname or path.
Output: internal reference cleanupRe-crawl the destination, verify priority redirects and submit the correct sitemap / property changes where the type of migration requires them.
Output: post-launch migration QAMIGRATION PRICE FOLLOWS DATA, RISK AND LIVE FUNCTIONS
The first package covers a straightforward WordPress host move. The second adds more data, integrations and transactional QA. The third is for complex WordPress or platform-to-WordPress migrations where URL mapping and custom functionality need deeper handling.
Published Perth migration pricing currently places complete small migrations around A$800–A$1,200, medium business migrations around A$1,500–A$2,200 and complex migrations around A$2,500–A$3,500. Alpha guide rates use approximately 60% of the lower reference point: A$480, A$900 and A$1,500.For one standard WordPress site moving host or server with stable URLs, normal plugins and no complex live-data sync.
Typical delivery: 1–2 business daysFor larger sites or WooCommerce / booking sites requiring staging, integration checks, redirects and a planned final data sync.
Typical delivery: 2–4 business daysFor complex WordPress moves or platform-to-WordPress projects requiring content mapping, larger redirect sets and deeper launch QA.
Typical delivery: 4–8 business daysGuide prices are in AUD and assume the client can provide valid source-hosting, destination-hosting, WordPress and DNS access. Email mailbox migration, Microsoft 365 / Google Workspace migration, custom application redevelopment, premium licences, new hosting fees and major redesign work are separate. DNS propagation depends on external resolvers and cannot be guaranteed to complete at one exact minute.
Additional approved migration engineering: A$90/hrTHE MOVE IS NOT FINISHED WHEN DNS CHANGES
After cutover we check the destination as a production environment: caches are rebuilt, SSL and redirects are verified, forms and transactions are tested, and obvious performance or security regressions caused by the new stack are documented.
Explore WordPress Maintenance →Verify that the destination cache, CDN and PHP environment are actually active and that the move did not introduce obvious new response-time or asset issues.
Submit key forms and confirm notifications because sender reputation, DNS or PHP mail behaviour may differ on the destination.
Remove temporary migration users or exposed staging access, confirm HTTPS and review obvious permissions or unsupported runtime issues.
Keep the old host available long enough for rollback and propagation confidence, then decommission it deliberately rather than paying indefinitely for an unused server.
MIGRATION QUESTIONS BEFORE YOU CHANGE DNS
These answers focus on downtime, rankings, data integrity and what access is needed to move a WordPress site safely.
For a standard host-to-host move, the target is low or no noticeable downtime: the new copy is staged and tested before DNS changes. DNS propagation and dynamic-data cutover still depend on the domain, TTL, host and site type, so we do not promise an exact zero-downtime outcome without reviewing the setup.
A hosting-only migration with the same URLs should not intentionally change search intent, but performance, availability or technical mistakes can still affect crawling. Domain or URL changes need redirect mapping, canonical checks, sitemap updates and post-launch crawling to preserve signals as carefully as possible.
Our guide pricing is A$480 for a standard WordPress move, A$900 for a larger business or transactional site, and A$1,500 for a complex or platform migration. Final scope depends on data size, URLs, integrations, DNS complexity and live-changing data.
Yes. That is the simplest migration type when the domain and URL structure stay the same. We still check PHP/runtime compatibility, SSL, forms, caching and integrations because the new host can behave differently.
Yes, but platform-to-WordPress migration is not a direct file copy. Content, URLs, media and platform-only features need to be mapped to WordPress equivalents. Visual redesign and custom functionality are quoted separately when required.
A standard move is typically 1–2 business days, a larger business or store migration 2–4 business days, and a complex or platform migration around 4–8 business days once all access and destination hosting are ready.
Usually WordPress administrator access, source hosting or SFTP/database access, destination hosting access and DNS/domain access for cutover. Some migrations also need CDN, SMTP, payment, booking or API credentials for testing.
Yes, but live stores need a final-data strategy. Depending on traffic and platform constraints, that may mean a brief maintenance window, order freeze or final database sync immediately before cutover.
Website migration does not automatically include mailbox migration. We preserve existing MX and email-authentication records during a website-only move, and quote mailbox or Microsoft 365 / Google Workspace migration separately if required.
Yes. We work remotely with businesses across Perth CBD, West Perth, Subiaco, Osborne Park, Joondalup, Fremantle, Cannington, Midland, Wanneroo and Rockingham, and can migrate WordPress sites elsewhere in Australia.
SEND THE SOURCE AND DESTINATION FIRST
Tell us what is moving, where it is going and what cannot break.
Share the current website URL, source host, destination host or platform, whether the domain changes, and any checkout, booking, CRM or email functions that must survive the move. We will scope the migration before touching DNS.