← Back to the blog

WordPress Migration Cost & Downtime Estimator

WordPress Site Migration Checklist: 15 Steps to Avoid Downtime

By Hamza IqbalFounder, ToolsForge

Reviewed 7 min readHow we source numbers

Checklist clipboard beside a server and a moving box

A good website migration checklist is the difference between a quiet, uneventful host switch and a stressful day of broken pages and angry emails. Most migration problems aren't caused by the transfer itself — they're caused by skipped preparation or skipped verification. This checklist walks through all three phases: before the move, during it, and after, so nothing falls through the cracks.

Why most migration problems happen before or after, not during

It's tempting to think of a migration as a single event — moving files from one server to another. In reality, the file transfer is usually the easy part. The steps that prevent downtime and lost SEO happen in the planning stage, and the steps that catch silent breakage happen after launch. Skipping either end of that timeline is where most wordpress migration steps go wrong. If you're coming from Wix rather than another WordPress host, there are no files to transfer at all, so read how a Wix to WordPress migration works first.

Pre-migration: preparation (steps 1-6)

  1. Take a full backup of files and database on the current host, and confirm you can actually restore it — an untested backup isn't a real backup.
  2. Audit your plugins and themes for anything outdated, abandoned, or redundant; migrations are a natural point to retire what you no longer use rather than carrying dead weight to the new host.
  3. Document custom code and integrations — payment gateways, CRM connections, custom post types — so nothing gets missed when rebuilding on the new environment.
  4. Set up a staging environment on the new host and do the actual file/database transfer there first, keeping the live site untouched.
  5. Update internal configuration on staging — database credentials, file paths, and any hardcoded URLs — so the site functions correctly before it's public-facing.
  6. Lower your DNS TTL (time to live) a day or two ahead of the planned cutover — a shorter TTL means resolvers cache your record for less time before checking for an update, so the eventual switch propagates faster.

Migration day: the cutover (steps 7-11)

  1. Do a final content sync to capture anything published or changed since the initial staging transfer — new posts, comments, orders if you run WooCommerce.
  2. Install and configure SSL on the new server before going live, so visitors never hit an insecure-connection warning — most hosts can issue a free, automated TLS certificate through Let's Encrypt, so there's no cost reason to skip this.
  3. Test the staging site thoroughly one more time — forms, checkout flow if applicable, page speed, and key user paths — with fresh eyes before flipping DNS.
  4. Switch DNS to point to the new host, ideally during a low-traffic window, and keep the old server running untouched as a fallback.
  5. Monitor propagation and confirm the new server is serving traffic correctly as DNS updates roll out across resolvers.

Post-migration: verification (steps 12-15)

  1. Test all redirects, especially if any URL structures changed, to make sure old links land on the correct new pages rather than 404ing.
  2. Run a full broken-link and image check across the site — migrations frequently break relative paths or media references that aren't obvious from a quick glance.
  3. Resubmit your XML sitemap in Google Search Console — this helps Google discover and process the site's URLs faster after a move than waiting for a routine crawl — and verify the new host isn't accidentally blocking crawlers via a stray robots.txt restriction carried over from staging.
  4. Re-run a performance check (Core Web Vitals, load time) on the new host to confirm the migration actually delivered the performance improvement you expected, not just a change of address.

In short: what's the most important step in a WordPress migration?

The single most important step in any WordPress site migration checklist is testing everything on a staging environment before switching DNS — this keeps the live site fully functional throughout the process and lets you catch broken plugins, missing redirects, or configuration errors while visitors are still unaffected. Skipping staging is the most common cause of avoidable downtime.

Checklist at a glance

Phase Key risk if skipped Steps
Pre-migration Data loss, missed dependencies 1-6
Migration day Downtime, broken SSL, rushed testing 7-11
Post-migration Lost SEO rankings, broken links, silent errors 12-15

Treat this as a genuine site migration plan, not a rough guide — checking off each phase in order is what keeps a migration boring, which is exactly what you want.

Mistakes that turn a simple checklist item into a real problem

Even with a full site migration plan in hand, a few specific mistakes account for most avoidable migration headaches. Knowing them ahead of time makes it much easier to spot when a "simple" step is quietly at risk.

Skipping the backup restore test

Taking a backup is not the same as confirming it works. A surprising number of migration disasters trace back to a backup file that turned out to be incomplete, corrupted, or password-protected in a way nobody remembered — discovered only when it was needed. Restoring the backup to a throwaway environment before you rely on it costs very little time and removes this risk entirely.

Rushing the plugin audit

It's tempting to skip step 2 and just carry every plugin over as-is, especially on a site that's been running for years. Old, abandoned plugins are disproportionately likely to break on a new server environment or PHP version, and tracking down which one caused an error after the fact takes far longer than auditing them up front.

Treating DNS TTL as an afterthought

Lowering DNS TTL only makes a difference if it's done far enough in advance — changing it the same day as cutover doesn't help, because resolvers around the internet keep serving your old record until their own cached copy expires, and a longer TTL means that takes longer. This step needs to happen on its own timeline, separate from the rest of migration day.

Declaring victory too early

The most common post-migration mistake is stopping verification once the site visibly loads correctly. Broken redirects, blocked crawlers, and missing form integrations often don't show up in a quick visual check — they show up in analytics dips or lost leads weeks later. Running through steps 12-15 in full, not just a glance at the homepage, is what actually closes the loop.

Related guides cover migrating WordPress without losing SEO rankings and the signs you've outgrown your hosting.

FAQ

Start the pre-migration phase at least one to two weeks before your planned cutover date for a typical business site, longer for WooCommerce stores or sites with many integrations. This gives enough time to test thoroughly on staging without rushing the final steps.
Yes, even for small sites — staging costs little extra time but catches configuration errors before they affect real visitors. Skipping it on a "simple" site is a common reason simple migrations still end up with unexpected downtime.
Resubmitting the XML sitemap and checking robots.txt after migration is frequently forgotten, because the site "looks fine" to a human visitor even when a crawler-blocking setting carried over from staging. This can quietly hurt search visibility for weeks before anyone notices.
Most of it, yes — backups, staging, DNS TTL, redirects, and post-launch verification apply to any CMS migration. The plugin/theme audit step is WordPress-specific, but the underlying principle (audit what you're carrying over) applies universally.

WordPress Migration Cost & Downtime Estimator

Estimate the cost and downtime of moving your site.

Run the free tool

Written by

Hamza Iqbal

Founder, ToolsForge

Founder of ToolsForge and a WordPress & WooCommerce developer. Builds the free calculators on this site and writes the guides behind them — every guide pairs real, sourced numbers with a tool so you can run your own.