Sequencing a multi site migration over several weeks

Move one site first, learn from it, then move the rest in batches ordered so that failure lands on the cheapest site rather than the most valuable one. The order is a risk decision, not a convenience decision. The most common and most expensive mistake is starting with the flagship, on the theory that if the hard one works the rest are trivial. It reverses the logic: your process is least rehearsed on the day the stakes are highest.

Choosing the pilot

The pilot has two jobs that pull against each other. It must be cheap to break, and it must be similar enough to the others that what you learn transfers. Optimise only for the first and you will pick a site that teaches nothing.

• Low traffic and low commercial value, so a bad hour costs little.
• Few moving parts, but not zero. A brochure page with no database tells you nothing about the nine database-backed sites behind it.
• Same stack as the majority: same CMS, same language runtime, same certificate arrangement, same mail path.
• An owner who is reachable during the window and can confirm the site behaves normally.

If your estate is genuinely mixed, run two pilots, one per stack. A single pilot that resembles a third of the portfolio is a pilot for a third of the portfolio.

What the pilot has to produce

The pilot is finished when it has produced a written record, not when the site loads. Capture at minimum:

1. What the old environment was silently supplying: cron entries, scheduled tasks, runtime extensions, rewrite rules the old panel injected, mail routing you never configured yourself.
2. Where the real configuration values live, including any credential hardcoded somewhere nobody documented.
3. How long the write freeze actually had to be, versus how long you assumed.
4. Every surprise, written as a step for site two rather than as a war story.

Then split that record into fixed steps and per-site variables. The fixed steps become the runbook. The variables become the list you fill in per site so nothing is copied from the previous one by accident.

Ordering the remaining sites

Running both environments in parallel

Keep the old environment paid for and intact after each cutover. The point of the overlap is that the old copy stays available as a reference and a fallback, not that it keeps serving. Two rules make the overlap safe. First, one environment is authoritative from the moment of cutover, and you enforce that by removing write access on the old side rather than asking people to be careful. Second, reach the old copy by direct hostname or a local host override, never by leaving it publicly resolvable alongside the new one.

The commit point

Commit when the new environment has carried a full business cycle including your weekly peak, when scheduled jobs have run at least one complete rotation, when a backup taken on the new side has been restored successfully, and when no fix in recent days has required touching the old environment. That last condition is the real test. Any dependence on the old side means you are still running two systems.

At commit, take one cold archive of files and database from the old environment, store it somewhere that is neither host, and only then stop paying. Other sequencing material sits in moving in, and if a batch involves address assignments or a partner who must be coordinated with, raise it through contact before you fix the order.