Migration Checklist

Generate the checklist for one specific WordPress move, rather than reading a generic article about them.

Runs on your deviceWordPressWorkingNo account needed

What this tool does

Migration Checklist assembles a written plan for shifting a WordPress site, in eight stages: the backup you prove works before touching anything, preparing the new server, moving the files, moving the database, the cutover, the things to do in the first ten minutes, verification, and the clean-up a month later. The steps are built from eleven settings — the host you are leaving, the host you are arriving at, both domains, the transfer method and six facts about the site — so the list names your own hosts and reads as the plan for this move.

Most of the branching turns on the two domain fields. Give different values and the list gains a serialisation-aware search and replace naming old → new, 301 redirects from every old URL to its match rather than to the home page, and the Change of Address tool in Search Console. Give the same value twice and those are replaced by a reminder to check siteurl and home in wp_options. That comparison is textual and case-sensitive: the scheme, any path and a leading www. are stripped first, so https://www.example.com/ and example.com are read as one site, while a move to a subdomain — or a difference only in capitals — counts as a domain change. The transfer method rewrites the database import line and, for WP-CLI, a plugin or a manual archive, prepends one step to the file copy; choosing "the new host is doing it" adds no file step of its own. Each checkbox then adds a step or two: lowering the DNS TTL, the http to https replacement plus the warning not to force HTTPS before the certificate resolves, the MX and SPF caution when email stays behind, a test order through the payment gateway and a check on order emails and stock, wildcard subdomains and wp_blogs for a network, and an rsync instruction for a large media library.

Anything the settings cannot know goes in the optional input box, one step per line, and comes back as a final Site-specific stage — a licence to re-activate against the new domain, an IP for the payment provider to whitelist, a nightly cron job to recreate. Lines beginning with # are skipped, so working notes can sit among them. The whole checklist is assembled in this browser tab from text that ships with the page: no host, DNS server or registrar is contacted, and nothing you type about your domains, servers or plugins is uploaded, which is the point when the fields you are filling in name a client's infrastructure.

The limitation is the plain one and worth stating first: this writes the plan, it does not perform the move. Nothing connects to either host, reads your DNS, runs the search and replace or confirms that a step was done — every box is ticked by you, elsewhere. The boxes are printed characters rather than controls, so no progress is stored: run it again and the list is rebuilt from the settings with everything unticked. The steps are also standard WordPress practice shaped by eleven answers, not knowledge of your site; it has not seen your plugin list, your server or your licences, multisite earns two extra reminders rather than a full network procedure, and a move onto or off WordPress entirely is outside what it describes.

How to use it

  1. Name both hosts. Type where the site lives now and where it is going. Both appear by name through the preparation and cutover stages, so the list reads as instructions rather than placeholders.
  2. Enter the current and the new domain. Leave them identical when only the hosting is changing. Different values switch on the search-and-replace, the redirect step and the Search Console notification.
  3. Choose how you are moving it. WP-CLI and rsync, a migration plugin, by hand over FTP and phpMyAdmin, or the new host doing it. The first three each prepend their own opening step to the file copy, and the choice decides whether the database import line is a wp db import command or the host's own tool.
  4. Tick what is true about the site. HTTPS changing, whether you control the DNS and can lower the TTL, email staying where it is, orders and payments, multisite, and a media library over roughly 2 GB.
  5. Add your own steps, then run. One per line in the input box, with # lines ignored. The summary counts the steps and stages you ended up with, and names the old and new domain when it treated the move as a domain change.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Moving a client site to a faster host

The domain stays put and only the servers change, so the list drops the rewrite work and concentrates on matching PHP versions, drop-ins and caches.

Rebranding onto a new domain

A domain change pulls in the serialisation-aware replace, redirects for every old URL and the Search Console step, which are the three most often left until traffic has already dropped.

Planning a go live window with a client

The stages give you something to agree in advance: when publishing freezes, when DNS moves, and how long the old host stays paid for afterwards.

Handing the site move to a colleague

Someone who has not done one before gets the order of operations, including the two steps that fail silently — re-saving permalinks and sending a real test email.

A shop that cannot lose an order

Ticking the e-commerce box adds a full test order through the gateway and a check that webhooks, tax rates, shipping zones and stock survived.

Questions

Does this move the site for me?
No. It produces a checklist and nothing else. No connection is made to either host, no file is transferred and no database is touched — the work is yours, and this is the order to do it in.
Is anything I type sent anywhere?
No. The list is built in this browser tab, so the host names, domains and site-specific notes you enter are not uploaded, logged or stored, and the page still works with the network disconnected.
Can I tick the boxes and come back to them?
Not here. The ☐ marks are text in the rendered list, and no progress is kept between runs. Track them wherever you track work; the same settings always rebuild the identical list.
What if only the hosting is changing?
Put the same domain in both fields. The search-and-replace and redirect steps disappear, and a check on siteurl and home in wp_options takes their place, since those two options survive the move pointing at nothing new.
Why does it warn against a plain SQL REPLACE?
Because WordPress stores arrays as PHP serialize() output, where each string carries its byte length. Editing the text without the numbers makes the row unreadable — WP-CLI search-replace handles it properly, and Serialized Data Fixer repairs the rows that are already broken.
Does it cover multisite?
Only in part. Ticking the box adds a check on wildcard subdomain support and a step for wp_blogs, wp_site and DOMAIN_CURRENT_SITE. A network with mapped domains needs more than those two lines.
Will it tell me whether the move succeeded?
No, it lists what to check. The verification you actually run is done elsewhere — Redirect Checker for the 301s, SSL Certificate Checker for the new certificate, and your own analytics for the top URLs.

Related tools