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, then crawl again to confirm each one resolves to a live page with a single hop. Google’s site move guidance treats this as the make-or-break step. For the signal-by-signal detail, the 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 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.
What has to be exported while the old site is still live?
Six things, because every one of them lives inside software you are about to switch off and none can be reconstructed from the public site afterwards.
| What to export | Where it lives | Cost of losing it |
|---|---|---|
| Titles, descriptions, canonicals | SEO plugin | Rewritten from memory, positions wobble |
| Existing redirect rules | SEO plugin or server config | Years of earlier moves silently undone |
| Form routing and recipients | Each form plugin’s settings | Enquiries deliver nowhere, and nobody notices |
| Two years of analytics pages | Analytics export | Landing pages the crawl never reached |
| Search Console pages and queries | Search Console export | URLs Google knows that you do not |
| Structured data settings | SEO or schema plugin | Rich results disappear without explanation |
The redirect table is the one that hurts most. A site that has moved before carries rules accumulated across years, and losing them breaks links that have worked since before anyone currently involved was hired.
Which checks belong on launch day itself?
Six, in this order, and each is a yes or no answer available within an hour rather than a judgment call.
Crawlability first, because it is the most damaging error and completely invisible to visitors. Read the live robots file on the production domain, then view source on three pages looking for a stray noindex left over from staging.
Redirects second. Request every mapped URL automatically, following redirects, and record the chain and final status. The pass condition is one hop at most, ending in a 200, on a page about the same subject.
Forms third. Submit every one and confirm it arrives at each recipient it used to reach, including any autoresponder.
Analytics fourth. Load the site, watch the real time report, and confirm the tag fires on every template rather than on the homepage alone.
Checkout fifth if you sell anything, with a real transaction taken and refunded.
Sitemap sixth: submit the new one, and leave the old sitemap reachable for a few weeks so retired addresses stay in the recrawl queue.
What should you measure before you switch?
A baseline, while the old site is still live, because without one you cannot tell a normal dip from a real loss.
Record impressions and clicks for the last three months, the twenty pages that bring the most traffic with their positions, total indexed page count, and conversions or enquiries per month. Screenshot the coverage report as it stands.
That takes twenty minutes and it is the only thing that makes the following six weeks interpretable. Owners who skip it end up arguing from memory about whether traffic used to be higher, which is an argument nobody wins.
Take the same measurements at week two, week four, and week eight. A clean migration shows a shallow dip and a return to baseline. A broken one shows a drop that keeps deepening, and the difference is obvious against a baseline and invisible without one.
When is this checklist overkill?
When no URL is changing at all. A rebuild on identical paths, or a move to a new host that keeps every address, needs backup discipline and launch testing rather than a redirect map, because search engines have nothing to relearn.
It is also more than a new site needs. A site launched three months ago with no backlinks and an archive nobody reads has no accumulated equity for the checklist to protect, and the hours are better spent on content.
And the redirect sections are unnecessary when the old site is genuinely being retired rather than replaced, for example a temporary campaign site coming down on purpose. Returning gone is the honest answer there.
The checklist earns its length on sites with history: years of addresses, links from other people’s pages, and rankings that took time to build. That is exactly where skipping steps costs the most, and exactly where people are most tempted to, because the site is large and the work is dull.
Which items do people skip, and what does each cost?
Four, consistently, and each has a characteristic failure that shows up weeks later rather than on launch day.
The full crawl gets skipped because the sitemap looks like the same thing. It is not: a sitemap lists what the site wants indexed, while a crawl finds what it actually serves. The cost is a category of URLs, usually paginated archives or tag pages, appearing as 404s in week four.
The baseline gets skipped because the old site is still there and it feels like something you can do later. You cannot, and the cost is six weeks of not knowing whether the dip is normal.
Content parity gets skipped because the new pages look better. The cost is pages that arrived shorter than the ones that were ranking, which reads as a mysterious partial recovery.
Launch day verification gets skipped because the redirect map exists and reviewing it felt like checking it. The cost is whichever rows were wrong, and you will not know which until traffic tells you.
All four share a shape: they are cheap before launch and expensive afterwards, which is precisely why a checklist exists at all.
Who should own each step?
Somebody named, because steps owned by everybody are owned by nobody and that is how items get skipped.
The crawl, the redirect map, and launch verification belong to whoever is building the site. They are technical, they are mechanical, and they need doing by the person who knows what the new URL structure is.
The exports belong to whoever has admin access today, because they need doing while the old site is live and they are mostly clicking through plugin screens.
The baseline belongs to whoever watches the numbers afterwards, so the person interpreting week four is the person who recorded week zero.
The content sign off belongs to one person in the business, not a committee. A staging review with four reviewers and no decision maker is where launch dates go.
Write those four names down before the project starts. It takes five minutes and it removes the most common reason a checklist item does not happen, which is that each person assumed somebody else had it.
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.
Common questions about this move
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.
What has to be exported while the old site is still live?
Titles, descriptions and canonicals from your SEO plugin, every existing redirect rule, each form’s routing and recipients, two years of analytics pages, your Search Console pages and queries, and any structured data settings. None of it can be reconstructed from the public site afterwards, and the redirect table is the costliest, because it holds every earlier move the site has made.
What should I measure before switching platforms?
A baseline while the old site is live: three months of impressions and clicks, your twenty best pages with their positions, the indexed page count, and monthly conversions. It takes twenty minutes and it is the only thing that makes the following six weeks interpretable. Without it you end up arguing from memory about whether traffic used to be higher.
Which checklist items get skipped most often?
Four: the full crawl, because a sitemap looks like the same thing and is not. The baseline, because the old site is still there and it feels like something you can do later. Content parity, because the new pages look better. And launch day verification, because the redirect map exists and reviewing it felt like checking it. All four are cheap before launch and expensive after.
