Website migration, as a purchasable service

Website migration means moving an existing website to a new host, a new platform, or both. It does not change what the site looks like or what it says. That distinction matters because “migration” is routinely quoted alongside a redesign as though they were one job. Bundling them is one of the most common causes of migrations going wrong. When something breaks, nobody can tell whether the move caused it or the redesign did.

Measured for Australia and recorded in research/outer-volume-au.json, “website migration” draws 70 searches a month at a keyword difficulty of 0 — the lowest difficulty of any commercial service term measured for this site. An earlier check of research/national-volume-au.json returned null for this exact phrase; the two datasets were pulled separately and the newer, more complete one governs. AI assistants recorded 32 prompts a month on the same phrasing in research/ai-vol-keywords.json, with no measurable Google volume of its own for that plain-language form. That is consistent with this being a “living with a website” question people increasingly put to an assistant rather than a search box. The result page pulled for the exact canonical target and read title by title shows genuine commercial intent. Two web agencies sell the service directly, two hosting companies sell it as a paid or complimentary add-on, one company sells it as a professional service, and two more items are buyer-education content published by commercial businesses in the same space. Only one of eight results is a plain vendor glossary entry with nothing to sell.

What a website migration actually moves

Three things move in a typical migration, and a quote should say which of them it covers. They are the files and code that make up the site. The content stored in its database — pages, posts, product listings, form submissions. And the domain’s associated services — email, DNS records, any subdomains in use. Missing the third is the single most common cause of a business losing email delivery for several days after a “successful” migration that only checked whether the website itself loaded.

Migration versus redesign versus rebuild: platform, hosting and WordPress

A migration preserves the site as it is and changes where or how it runs. A redesign changes how the site looks and reads, without necessarily changing where it runs. A rebuild does both — new platform, new design — at once. Website redesign versus rebuild sets out that distinction in more depth. The practical point here is that a quote combining migration with either of the other two should itemise them separately. The risk profile and the testing required for each is different. A single bundled figure obscures which part of the work is driving the cost.

Where migrations actually go wrong: URL, DNS and internal settings

Failure	Cause	What prevents it
Search rankings drop after the move	URLs changed with no redirects in place	A written URL-mapping and redirect plan agreed before the cutover
Email stops arriving	DNS records (MX, SPF, DKIM) not carried across, or carried across incorrectly	Documenting every existing DNS record before touching anything, not just the ones the migration team recognises
Content or form submissions go missing	Only the visible site was migrated, not everything in its database	Confirming what “the whole site” includes before the quote is agreed, not after
Extended downtime during the switch	No parallel-running period, or DNS propagation not accounted for	Running old and new in parallel before the final cutover — see below

Running the old and new sites in parallel

The lowest-risk way to migrate is to have the new version fully built and tested on a temporary address, while the live site keeps running unchanged. Switch DNS only once the new version is confirmed working end to end. Running the old and new website in parallel covers how that staging period is normally structured. A quote with no parallel-running period at all is quoting the fastest possible migration. It is not necessarily the safest one.

What a migration checklist should contain: export, migrate and move your site

A written, agreed checklist covers the URL map, the DNS records, the content inventory and a rollback plan if something goes wrong after cutover. That is the difference between a migration that is tested against a known list, and one that is tested against whatever the migration team happens to remember to check. What a migration checklist contains sets that list out in full. Ask to see the equivalent document before agreeing to any migration quote. Treat a supplier who has not written one down as quoting from memory, rather than from a process.

What to ask before agreeing to a migration service quote

Ask explicitly whether email and DNS are included in scope. Ask whether there will be a parallel-running period before the final switch. Ask what the rollback plan is, if something is found broken after the old site is taken down. Web development services covers the standing technical-service arrangements a migration is often quoted alongside. Treat migration as its own line with its own checklist, regardless of what else is bundled into the same project.