Website Migration: The Complete Checklist and Risk Framework

A website migration is one of the highest-risk technical projects a business can take on. Handled without a plan, it wipes out years of accumulated search rankings inside a fortnight. Handled properly, it is the moment you consolidate authority, clear technical debt, and set the site up to outperform the one it replaced.

This checklist covers every phase of a website migration, from discovery weeks before launch through to post-launch monitoring and disaster recovery. It is written for UK marketing managers, developers, and business owners who need an operational framework with named owners on every task.

You will find guidance on team roles, UK GDPR obligations when hosting changes, realistic timelines, and what to do if organic traffic drops after go-live.

What a Website Migration Is and Which Type You Are Running

A website migration is any change that alters where your site lives, how its URLs are structured, or what technology serves it. That is broader than most business owners expect. Moving from HTTP to HTTPS counts. So does a redesign that leaves the domain untouched but rewrites every URL slug.

The definition drives risk calibration. Each type carries a different failure profile, and your protocol should match the one you are running. Treating a domain change like a hosting move is how businesses lose six months of organic revenue.

Website Migration Types, Risk Levels and Recovery Periods

Many projects combine two or three of these at once. A business moving from a legacy CMS to WordPress on a new host with a fresh URL structure is running three migrations at once, and should plan against the highest risk band in that combination rather than the average. Where the build changes as well as the address, scoping it alongside professional web development keeps the rebuild and the redirect map on one timeline.

A pure server move sits at the low end of the table, but still needs solid managed hosting and maintenance on the receiving end to avoid downtime and speed regressions.

Why Most Website Migrations Fail

Technical errors get the blame, but missing redirects are rarely the sole root cause. Most failures trace back to three areas outside the redirect map entirely.

The first is stakeholder misalignment. When a director sees a 15% traffic drop in week two with no warning, the reaction is to demand mid-flight fixes that break redirect logic which was working fine.

The second is legacy debt. Moving thousands of thin, outdated pages into a new environment dilutes crawl budget and carries every existing problem with it. A website migration is the moment to decide what to move, what to merge, and what to remove. That call is commercial rather than technical, which puts it inside strategic digital planning rather than the developer’s backlog.

The third is compressed timelines. Discovery gets squeezed because the launch date was fixed before anyone scoped the URL mapping. That is a project management failure, and the most common of the three.

Assembling Your Website Migration Team

Most migration guides cover technical steps and say nothing about who does them. A website migration without assigned roles becomes a project where critical tasks are assumed to be someone else’s job until something breaks in production.

A well-structured team covers three functions, each owning a layer of the project and talking to the others throughout rather than only at handover.

The Core Roles You Need

The SEO lead owns the URL mapping document, redirect logic, ranking benchmarks, and post-launch monitoring. Whether that sits in-house or with an agency handling search engine optimisation, they belong in the room from the first planning meeting, not handed a redirect list on launch day.

The developer or technical lead handles server configuration, DNS, staging setup, robots.txt, and redirect implementation. They own the go-live sequence and stay available for at least 48 hours after launch.

The project manager owns internal communication. Before go-live, decision makers need to understand that a temporary dip is part of the settling period, not a sign of failure. Setting that expectation early prevents panicked rollback calls based on one bad day of data. Where internal teams have never sat through a migration, a short session of team training services on the settling period removes most of that pressure.

“The migrations that go wrong are almost never the ones where somebody misconfigured a redirect. They are the ones where nobody could say, on launch day, who was allowed to make the call to stop,” says Ciaran Connolly, founder of ProfileTree.

Defining the Decision-Making Chain

Before any work starts, agree who has authority to approve a rollback. Migrations often go wrong because decisions get made in a crisis with no chain of command.

Document three answers in writing: who approves the go-live, who approves a delay, and who approves a full rollback. Get sign-off from everyone named before work begins.

B2B Versus E-commerce Migrations

The risk profile shifts depending on what you are moving. A lead-generation site with 50 landing pages and a few high-value backlinks is a very different proposition from an e-commerce store with thousands of SKUs, category pages, faceted navigation URLs, and transactional pages carrying real link equity.

For e-commerce, URL mapping alone can take weeks. SKUs need one-to-one mapping, category structures need preserving or careful consolidation, and parameterised URLs need handling that avoids generating thousands of duplicate chains. Build that complexity into the timeline from the outset rather than discovering it in week three. If the move involves a visual rebuild, treat conversion-optimised design as a separate workstream from redirect mapping so neither blocks the other.

Phase 1: Pre-Migration Discovery and Benchmarking

The pre-migration phase is where most of the work happens. Compressing it is the most common reason a website migration fails. Plan four to six weeks minimum on a standard site, and longer for large or complex properties.

Everything here produces a document you use later, feeding directly into the staging checks and post-launch diagnostics.

Technical Site Audit and Crawl

Crawl the existing site with a tool such as Screaming Frog and export every indexable URL. That export is the foundation of your redirect mapping document.

At the same time, pull benchmarking data from Google Search Console: organic clicks over the last three months, impressions, average position, and click-through rate for every page that matters. This snapshot is what you compare against after launch to judge whether the migration performed within tolerance. It also becomes the baseline for any later work on improving search visibility.

Run a content audit at this stage too. Identify which pages are worth moving in full, which should be consolidated, and which should be removed or noindexed. Do not carry thin or duplicate content across.

Embedded media needs its own line in that audit. Pages carrying video content creation assets need their embeds checked on the new template rather than assumed to survive intact.

The URL Mapping Document

The URL mapping document is the most important deliverable of the entire website migration. It records every old URL and the new URL it redirects to. Every page changing address needs a row: subpages, tag pages, category archives, and any URL holding backlinks or organic traffic.

The 80/20 principle applies. Concentrate on the 20% of pages carrying the most link equity, because a missing redirect there does the most damage. Pattern-based bulk rules handle the long tail efficiently.

Build it with four columns minimum: old URL, new URL, redirect type, and status. Add a fifth for the named owner if more than one developer is implementing.

UK GDPR and Data Privacy Considerations

This is the section most migration guides skip, and for UK businesses it is not optional. When a website migration changes hosting provider, user data including form submissions, CRM records, analytics and email lists may move between servers in different jurisdictions.

Moving from a UK server to a US host, or the reverse, means reviewing your Privacy Policy and confirming your data transfer mechanisms meet UK GDPR requirements. This is a pre-launch task, not something to tidy up afterwards.

Update your Privacy Policy, Cookie Policy, and Terms of Service to reflect the new environment and any change to how data is collected, stored, or processed. If your CMS stores user data in a database that will be exported and re-imported, confirm that transfer is documented and compliant. A provider with clear data residency terms, or website hosting services that document where data physically sits, removes most of this uncertainty before it becomes a compliance question. Where you are still unsure, consult the ICO’s guidance on international transfers or take legal advice first.

Phase 2: Staging Environment and Safety Checks

Never test a website migration on a live site. Staging is a private, non-indexed copy of the new build where you run every check and fix every error before a real visitor or crawler touches production. This is not a shortcut worth taking on any budget.

Staging is where the URL mapping document stops being theoretical. Every row gets tested, and the errors you find here are the ones that would otherwise surface in front of customers.

Blocking Search Engines from Staging

Confirm search engines are blocked before you do anything else on staging. Two mechanisms exist: a noindex meta tag in the head, and a Disallow: / rule in the staging robots.txt. Use both.

If staging gets indexed accidentally, you create duplicate content problems that persist past go-live. Verify the block by opening robots.txt in a browser rather than trusting the CMS toggle.

Testing Redirects in a Sandbox

Work through the URL mapping document and verify every redirect. Check each old URL resolves to the correct destination, returns a 301 rather than a 302 or meta refresh, and does not sit in a chain pointing to an intermediate URL that redirects again.

Chains consume crawl budget and dilute link equity. Flatten every one to a single hop. Use a crawler that tests responses in bulk rather than checking URLs individually, which is where teams lose patience and start sampling instead of testing.

Core Web Vitals Benchmarking

Run a Core Web Vitals assessment on staging before go-live. Record Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint, then compare against the live site.

If the new platform or theme scores worse on any metric, fix it before launch. A website migration that improves content structure while degrading page performance is a net negative for rankings. Common culprits are unoptimised images, render-blocking scripts, and uncached resources on a new host that has not been configured properly yet. A theme built on user-focused web design principles normally scores better than a heavily templated alternative carrying features you never use.

Staging is also the moment to test across browsers and devices, confirm forms submit, and check analytics, CRM connectors and chat tools fire correctly. Any AI chatbot development on the old site needs its scripts and knowledge base re-pointed at the new URLs before launch.

Phase 3: Launch Day Execution Protocol

Launch day is not when the hard work begins. It is when completed work gets executed in a precise sequence. If discovery and staging were done properly, launch day should feel methodical rather than stressful.

Sequence matters more than speed. Several steps below cause real damage if performed out of order.

The DNS Switch and Propagation

Never launch a website migration on a Friday. If something breaks, your development team needs to be available, and that drops sharply over a weekend. Mid-week launches, typically Tuesday or Wednesday, give two full working days of support cover.

When you update DNS records, propagation takes anywhere from a few minutes to 48 hours depending on TTL settings and provider. Lower your TTL to the minimum your registrar allows, ideally 300 seconds, at least 24 hours before go-live. Raise it back once the migration is stable.

Keep the old hosting environment active for at least 30 days. Your 301 redirects on the old server need to stay live to pass link equity through the re-indexing period.

Removing Noindex Tags and Updating Robots.txt

Once DNS has propagated and the site is confirmed live, remove the noindex tags and update robots.txt to allow crawling. The order is not negotiable: confirm the site is live first, then open it to search engines.

Afterwards, check the live robots.txt in a browser. Confirm no accidental Disallow rules cover important sections, and verify canonical tags point at the correct URLs on the new structure.

Submitting the Change of Address in Search Console

If the website migration involves a domain change, submit a Change of Address notification in Google Search Console. It sits under Settings in the relevant property and requires both domains to be verified.

Upload your new XML sitemap to that property immediately afterwards. It gives Googlebot a complete map of the new structure and speeds up re-crawling. Do not wait for Google to find the URLs organically.

Update destination links in ad accounts, email signatures and social profiles the same day. Profiles used for social media marketing still pointing at old URLs keep pushing visitors through redirects you want to retire.

Phase 4: Post-Launch Monitoring and Recovery Diagnostics

The 72 hours after a website migration goes live are the most information-dense period of the project. Issues invisible in staging surface in production, and the faster you spot them, the less damage they do. Monitoring here needs to be active and structured, not a passive glance at a dashboard each morning.

Every migration should also carry a recovery plan written before launch day, because decisions made in a crisis without a framework are rarely good ones.

The 72-Hour Critical Watchlist

Within three hours of go-live, verify four things: the site is accessible, old URLs redirect correctly, the sitemap is submitted and accepted, and analytics is firing. Tracking code failing to carry over is a common oversight, and it leaves you blind when you most need data. Rebuilding those dashboards is also the point to confirm any AI-powered marketing automations feeding off that data still receive it.

Across the first 72 hours, monitor Search Console crawl reports closely. A rise in 404s means URLs are returning not-found responses instead of redirecting, pointing to mapping rows that were never implemented. Fix them as they appear rather than batching for a weekly review.

Expect ranking volatility for two to four weeks. That is normal re-indexing behaviour. A failed website migration is one where rankings decline and never recover past week eight, or where large volumes of pages stay unindexed.

Diagnosing a Traffic Drop

A post-launch drop falls into one of three categories, and the fix differs for each. Diagnose before you act, and bring in professional SEO support if the pattern maps cleanly onto none of them.

• Redirect failure: pages that carried organic traffic return 404s or land on the wrong destination. Compare the Search Console coverage report against your mapping document.
• Content issue: pages were consolidated, pruned, or rewritten and Google is re-evaluating them. This drop is gradual rather than immediate and hits specific query clusters, not the whole site.
• Technical issue: noindex tags left in place, robots.txt blocking crawlers, canonicals pointing at old URLs, or degraded Core Web Vitals. These cause broad suppression rather than isolated page losses.

If you have server log access, reviewing it now shows how Googlebot is crawling the new site and whether it is spending time on low-value pages instead of commercial ones.

When to Trigger a Rollback

A rollback is a last resort, not a first response to a difficult week. It introduces fresh disruption and can compound volatility. Three conditions make it the right call.

Trigger one if more than 30% of previously indexed pages return 404s after 48 hours and cannot be fixed quickly; if a critical failure such as a broken checkout or contact form is causing commercial damage; or if user data has been exposed on the new platform.

Before triggering, confirm the old hosting environment is still active and the old files intact. This is why keeping old hosting live for 30 days is insurance rather than a suggestion.

The Stakeholder Communication Brief

When traffic drops, pressure to act usually comes from inside the business rather than from the data. Stakeholders never briefed on the settling period read a 15% dip in week one as a crisis.

Send a short brief before launch covering three points: what to expect in the first four weeks, what separates normal volatility from a real problem, and who owns monitoring and decisions. That buys the four to eight weeks the migration needs to settle.

Conclusion

A website migration handled at this level of preparation is not a gamble. It is a managed transition with defined checkpoints, named owners, and a documented recovery path. The businesses that come through without ranking damage are the ones that treated discovery as seriously as launch day.

Start with three actions this week: crawl your site and export the URL list, pull three months of Search Console benchmarks for your top pages, and name the person holding rollback authority. Those three outputs turn a website migration into a controlled project.

If you are planning a move and want a technical team that has run this process for SMEs across the UK and Ireland, talk to ProfileTree’s website development team about your project scope and timeline.

FAQs