What Is a Website Migration? What Moves, What Can Break and How It Is Planned

A website migration is a planned move of a site from one technical home to another: a new host, domain, platform, server setup, or URL structure. The pages may look unchanged to visitors, but the move can affect links, images, email, speed, and search visibility unless each part is checked before and after launch.

For a small business, a migration often starts as a practical decision: hosting is unreliable, the site has outgrown its builder, a rebrand needs a new domain, or maintenance has become difficult. The safest approach is to treat it as a controlled project with a copy of the site, a list of URLs, a clear launch window, and a rollback plan. A rushed “copy and switch” can leave a polished homepage online while contact forms, old links, or product pages quietly fail.

What actually moves during a website migration?

A site is more than its visible pages. The migration inventory should include the database, theme or templates, plugins and extensions, uploaded media, user accounts, forms, redirects, analytics tags, consent settings, and any integrations such as payments or email delivery. Domain DNS records and business email may be managed separately, so changing a website host should not accidentally interrupt mail.

There are several common kinds of migration. A host migration moves the site to a different server while keeping the same domain and platform. A platform migration changes the software, for example from a hosted builder to WordPress. A domain migration changes the address, perhaps after a rebrand. A structural migration changes URLs or reorganises sections. Projects can combine more than one type, but combining a platform switch, new domain, and complete redesign at once makes it harder to identify the cause if something breaks.

What can go wrong when a site is moved?

The most visible failure is downtime, but a site can stay online and still lose important functions. Images may point to the old server; forms can stop sending; payment callbacks can fail; HTTPS may show a certificate warning; and pages can return “404 not found” because their addresses changed. Search engines may temporarily see duplicate pages, missing pages, or a new site that blocks crawling.

Search visibility is especially sensitive to URL changes. Google recommends mapping old URLs to their new equivalents and using permanent redirects where a page has moved. A redirect should lead to the closest matching page, not send every old URL to the homepage. Keep a record of the old-to-new mapping and test it after launch. Google’s site move guidance explains the search steps, including redirects and sitemap updates.

Also readGit status, Git log and Git diff: Reading Your Project's History (Part 8)→

How should you plan a migration?

Start with a written inventory. Export or crawl the current URLs, identify the pages that bring customers or search traffic, note the forms and integrations, and save a full backup of both files and database. Capture baseline analytics and Search Console data so the team can compare performance after the move. Decide who owns DNS, hosting, email, content approval, and the final launch decision.

• Build and test the new site on a staging address that is not publicly indexed.
• Check key pages, navigation, mobile layouts, images, forms, checkout, logins, and accessibility.
• Prepare redirects before launch, and verify that each important old URL reaches the right new page.
• Lower DNS time-to-live in advance if the DNS operator recommends it, then make the switch during a low-traffic window.
• Keep the old site and backup available until the new site has passed its checks.

What should you check immediately after launch?

Open the site in a private browser and test the paths a real visitor uses: home page to service page, product to checkout, contact form to inbox, and mobile menu to the right destination. Check a sample of old links, images, redirects, SSL certificates, robots.txt, canonical tags, and XML sitemap. Search Console’s redirect documentation and URL inspection tools can help spot crawl and indexing issues, but they do not replace testing your own forms and transactions.

Monitor server errors, 404s, page speed, traffic, and conversions daily at first. A short dip in impressions after a substantial move can happen while search engines crawl and process changes, but persistent errors deserve investigation. Do not delete the old environment immediately: it is valuable for comparing files, restoring data, and finding a page that was missed.

How long does a migration take?

There is no reliable one-size-fits-all timeline. Moving a small brochure site with unchanged URLs may take days of preparation and a short launch window. A large shop, multilingual site, or platform change needs more time for product data, custom features, redirects, and testing. The calendar date for launch is less important than having a tested backup, a complete URL map, and someone available to fix issues.

Also readYour First Git Repository and First Commit, Step by Step (Part 7)→

What is H View’s practical advice?

Do not approve a migration on the strength of a homepage preview. Ask the team to show the URL map, the backup and restore process, the list of tested forms and integrations, and the person responsible for monitoring after launch. In our view, a careful migration is one that customers barely notice: their bookmarks still work, their enquiries arrive, and the business can explain what changed if a problem appears.

Frequently asked questions

Will a website migration erase my Google rankings?

It does not automatically erase rankings, but missing pages, incorrect redirects, blocking rules, and broken content can reduce visibility. Preserve relevant URLs where possible and map any changes carefully.

Can I keep the same domain when changing web hosts?

Yes. In a host-only move, the domain can stay the same while DNS is updated to point to the new server. Confirm that email records are preserved before changing DNS.

Should I redesign and migrate at the same time?

It can be done, but it increases the number of variables. If you must combine them, document each URL and feature change and test against the old site page by page.

Verdict

A migration is a technical move and a customer-service change. Plan the pages, data, redirects, email, and recovery path before launch; then check the real user journeys after it. That is what protects the site’s usefulness while its infrastructure changes.

Sources: Google Search Central: site moves with URL changes; Google Search Central: redirects and Google Search; WordPress.org: moving WordPress.