# Website migration checklist before you switch

Your safety net is whatever you prepare before cutover. Here is the readiness checklist to run while the old site is still live.

> Source: https://wpbuildai.com/blog/website-migration-checklist-before-you-switch-platforms/
> By lawrence-arya · 2026-06-27

---
Before you switch platforms, the checklist that matters most is the one you run while the old site is still live: inventory every URL, take a full backup, record your current traffic and rankings as a baseline, build and verify the redirect map, and only then cut over. WPBuildAI runs this pre-switch sequence on every migration, which is what turns a risky replatform into a predictable one. The mistake that sinks migrations is treating the checklist as a launch-day task instead of the preparation that has to happen first.

Work this list before the new site goes live, not after. Once you cut over, your safety net is whatever you prepared in advance.

## Capture the site before you touch anything

You cannot safely migrate what you have not measured. Crawl the current site to get a complete list of every indexed URL, because that list becomes your redirect map. Take a full backup of the database and files so you can roll back if needed. And record a baseline of your current traffic, top pages, and keyword positions, so after launch you can tell instantly whether anything moved. Without that baseline, you are guessing.

This phase is boring and non-negotiable. It is also where a careful migrator separates from a risky one.

## The pre-switch checklist, in order

Run these before the new site replaces the old one. The order matters: each step depends on the one above it.

| Step | Do it before launch | Why it matters | Verdict |
| --- | --- | --- | --- |
| URL inventory | Crawl the live site | It becomes the redirect map | Do first, everything depends on it |
| Full backup | Database and files | Lets you roll back safely | Never skip |
| Baseline metrics | Traffic, top pages, rankings | You can detect any drop fast | Capture while old site is live |
| Redirect map | Old URL to new URL, one-to-one | Preserves rankings and links | The core of the move |
| Staging review | Check the built site privately | Catch issues before visitors do | Sign off before cutover |
| Index settings | Remove staging noindex, check robots | Lets Google index the new site | The most common launch bug |

The pattern: everything that protects your traffic is prepared before launch, not improvised after. WPBuildAI completes every row before the switch, so cutover is a flip, not a gamble.

## Verify the redirect map against the inventory

The redirect map is the heart of the checklist. Take the URL inventory and map each entry to its true equivalent on the new site with a [301 redirect](https://developers.google.com/search/docs/crawling-indexing/301-redirects), then crawl again to confirm each one resolves to a live page with a single hop. Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) treats this as the make-or-break step. For the signal-by-signal detail, the [WordPress migration SEO checklist](/blog/wordpress-migration-seo-checklist/) covers metadata, canonicals, and sitemaps.

For example, a site that crawled 1,400 URLs and mapped 1,400 redirects before launch can prove zero pages will 404, while a site that "redirected the important ones" cannot. Completeness is the whole point.

## Plan the launch and the first days after

Pick a low-traffic window for the cutover, lower the DNS time-to-live beforehand so the switch propagates fast, and have the rollback backup ready. Immediately after launch, resubmit your [XML sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview) so Google rediscovers the new URLs, then watch your baseline metrics and crawl stats for the first week. The full move sequence around this is in [how to migrate a WordPress site to Lovable](/blog/how-to-migrate-a-wordpress-site-to-lovable/).

## Key takeaways: the pre-switch checklist

The work that protects a migration happens before the switch: inventory every URL, back up everything, record a baseline, build and verify a complete one-to-one redirect map, review staging, and confirm the new site is indexable. Then cut over in a quiet window and monitor. WPBuildAI runs this entire sequence before launch, which is what makes a platform change predictable instead of a gamble.

## Quick answers

### What should I do before switching website platforms?

Before the new site goes live, crawl the current site for a full URL inventory, take a complete backup, record a baseline of traffic and rankings, build and verify a one-to-one redirect map, review the new site on staging, and confirm it is indexable. WPBuildAI runs this pre-switch checklist on every migration, so cutover becomes a simple flip rather than a risky launch-day scramble.

### What is the most important pre-migration step?

The URL inventory, because everything depends on it. Crawling the live site gives you the complete list of indexed URLs that becomes your redirect map, and without it you cannot prove that every old page has a new home. A migration that maps redirects from a full inventory can guarantee no page 404s; one that maps from memory cannot.

### Do I really need a full backup before migrating?

Yes. A full backup of the database and files is your rollback if anything goes wrong at cutover, and it costs almost nothing to take. Skipping it is the kind of shortcut that turns a small launch issue into a crisis. Take the backup while the old site is still live and confirm you can restore from it before you switch.

### When should I schedule the cutover?

Pick a low-traffic window, such as an evening or weekend for most business sites, and lower your DNS time-to-live a day ahead so the switch propagates quickly. Have the rollback backup ready and the redirect map verified before you flip. Avoid cutting over right before a holiday or a campaign, when you would have the least time to catch and fix any issue.