There is no shortage of guides on moving a WordPress site to a new host. Moving two hundred of them, on behalf of clients who did not ask for it and will not forgive an outage, is a different problem.
The difference is not the amount of work. Copying files is copying files. The difference is that a mistake no longer affects one site, your sequencing decides how bad any mistake gets, and every client is a separate relationship that can be damaged independently. This is the runbook.
Why Moving 200 Sites Is Not 200 Migrations
Three things change when the number gets large.
Blast radius. A single migration that goes wrong is one apology. A batch that goes wrong at three in the afternoon is forty simultaneous phone calls, and you cannot answer forty phone calls.
Variance. Across two hundred sites you will find sites on ancient PHP versions, sites with hard-coded absolute paths, sites with a plugin licensed to a server IP, sites where a developer left something in cron that nobody documented. You do not know which ones until you look.
Coordination cost. Every client who needs to approve something is a delay you do not control. The technical work is the small part.
What "Zero Downtime" Actually Means
Worth being precise, because the phrase gets used loosely and the loose version is what gets agencies into trouble.
Zero downtime does not mean the site is never served from two places. It means no visitor ever sees an error. Those are different claims. During a properly run cutover the site is live on the old host and the new one simultaneously, and traffic drains from one to the other as DNS caches expire. Nobody sees a gap because there is no gap in service, only a gap in which machine answers.
What breaks that promise is almost never the copy. It is:
- DNS records with a long TTL, so traffic keeps arriving at a server you have already stopped maintaining
- A database that carried on taking orders on the old host after you copied it
- An SSL certificate not yet issued on the new host when the domain starts pointing there, which produces a browser warning far more alarming than a slow page
Step 1: The Audit
Before moving anything, build a spreadsheet with a row per site. This is the step agencies skip and then regret.
| Column | Why it matters |
|---|---|
| PHP version | Sites on very old versions may not run on a current stack without work |
| Database size | Anything unusually large needs a different copy method and a longer window |
| Total disk size | Media libraries in the tens of gigabytes change the plan |
| Ecommerce? | Live transactions mean the database moves last and fast |
| Membership or logins? | Sessions and user tables are write-heavy, same problem as ecommerce |
| Email on the same domain | Decides whether the DNS change is safe to make casually |
| Custom cron or scripts | The most commonly forgotten thing, and it fails silently |
| IP-licensed plugins | Some licences bind to a server address and need reissuing |
| Who signs off | The client contact who will actually reply |
| Current TTL | Determines how far ahead you need to start |
The audit's real output is not the data, it is the sorted list. You now know which sites are boring and which will fight you.
Step 2: Batch By Risk
Never move in alphabetical order. Move in order of what you can afford to get wrong.
- Your own sites first. Your agency site, your staging boxes, anything where the only person you have to apologise to is yourself. This is where you find out what the new host does differently.
- Small, static, low-traffic client sites. Brochure sites with no logins and no transactions. Ten or twenty at a time.
- Larger content sites. More traffic, more plugins, still no money moving through them.
- Ecommerce and membership sites, individually. Never batched. Each one gets its own window, its own checklist and its own rollback.
- The awkward ones. Whatever the audit flagged. By now you know the new platform well enough to deal with them.
Between batches, stop and wait. A day is enough. If something is going to surface, it surfaces within a day, and you want to find it on twenty sites rather than two hundred.
Managed Hosting solutions for WordPress backed by Speed, Security and Scalability
Talk To Sales →Step 3: Lower Your TTLs First
The single highest-value thing you can do, and it happens before you copy a single file.
A DNS record's TTL tells resolvers how long to cache it. If it is set to 86400 seconds, some resolvers will keep sending traffic to the old server for a full day after you change the record. You cannot shorten that window retroactively.
So, at least 48 hours before a batch moves, drop the TTL on those domains to 300 seconds. Once every resolver has picked up the short value, a cutover propagates in minutes rather than a day. Put the TTL back to something sensible a week after the move.
This is why the audit records the current TTL. A domain sitting at 86400 needs the clock started two days earlier than one already at 300.
Step 4: Copy, Rebuild, Verify
For each site in the batch:
- Copy files and database to the new host. The WordPress migration documentation covers the mechanics, and WP-CLI makes it scriptable across many sites at once, which is the only sane approach at this volume.
- Bring it up on a temporary address on the new host, not the live domain. A preview hostname, or your own hosts file.
- Issue the SSL certificate now, before the domain points anywhere. Most hosts can do this ahead of the DNS change. Getting this wrong is the most common cause of a visible failure.
- Verify. Load the home page, an inner page, a form, the login, and anything the audit flagged. Check the cron jobs exist. Check the mail sends.
- Freeze the old site for sites where content changes: tell the client not to publish during the window, or accept that you will re-sync the database at cutover.
For anything transactional, the database moves at the last possible moment and the site goes into a brief maintenance state while it does. A few minutes of a maintenance page is vastly better than losing an order.
Step 5: The Cutover
With TTLs low and the site verified on the new host, the cutover is a DNS change. Point the A record, or the nameservers, at the new host.
Two rules:
- Do not touch the old server. Leave it running, serving the old copy, for at least a fortnight. It costs one more month of hosting and it is the cheapest insurance you will ever buy.
- Watch, do not assume. For the first hour, load the sites yourself. Check the new host is actually receiving the traffic. A cutover that silently did not take is worse than one that failed loudly.
Step 6: After The Move
Within 24 hours, for each site: confirm forms deliver, confirm scheduled posts publish, confirm backups are running on the new host, and confirm any payment webhooks still arrive. Webhooks are the classic delayed failure, because nothing breaks until the next transaction.
Within a week: restore TTLs, decommission the old environment once you are confident, and check Search Console for crawl errors on the larger sites.
The Rollback Plan
Write this down before you start, because you will not be thinking clearly when you need it.
If a site is broken on the new host and you cannot fix it inside your agreed window, you point the DNS back at the old server. That is the whole plan, and it works only if two things are true: the old server is still running untouched, and the TTL is still short. Both are decisions you made days earlier.
The one case where rollback is not clean is a site that has taken writes on the new host, an order or a signup. Then reverting loses that data. This is precisely why transactional sites move individually, with a short maintenance window, rather than in a batch.
If you would rather not run this yourself, this is the sort of thing a host's migration team should do for you. Ours moves sites by hand and rebuilds each one on a private URL for checking before anything changes. Our guide to migrating a single WordPress site covers the mechanics in more depth, and managing multiple WordPress sites covers what happens after everything has landed.
Email Is A Separate Project
The most common way a portfolio migration goes visibly wrong is email, and it is avoidable by not doing the two things together.
When you change a domain's nameservers, you move the MX records along with everything else unless you deliberately carry them over. Get that wrong and mail stops arriving, which a client notices within the hour and in a way they will remember.
Even done correctly, mail is harder than web because messages in transit go wherever the sending server resolved a few minutes ago. A website served from two places is invisible. A mailbox split across two servers means half the messages are somewhere the client is not looking.
So: copy the existing MX, SPF, DKIM and DMARC records to the new DNS before you change the nameservers, verify them, and leave email exactly where it is. Move mailboxes later, as their own project, with their own notice period. If email is not moving at all, note that in the audit so nobody helpfully tidies the records up afterwards.
A Worked Timeline For 200 Sites
| When | What happens |
|---|---|
| Week 1 | Audit every site. Sort by risk. Agree the batches internally |
| Week 1 | Tell clients the supplier is changing, with a date range and what to expect |
| Week 2 | Move your own sites. Find out what the new platform does differently |
| Week 2 | Drop TTLs on batch one |
| Week 3 | Batches one and two, twenty sites each, two days apart |
| Week 4 | Batches three to six. Pace set by what went wrong in weeks two and three |
| Week 5 | Ecommerce and membership sites, individually, in agreed windows |
| Week 6 | The awkward ones. Restore TTLs on everything already moved |
| Week 8 | Decommission the old environment, once nothing has come back |
The two weeks between the last move and decommissioning are not padding. They are the window in which the delayed failures surface: a monthly cron that has not run yet, a payment webhook that fires on renewal, a scheduled report nobody thought about.
What Actually Goes Wrong
| Failure | When you notice | Prevention |
|---|---|---|
| SSL not issued before cutover | Immediately, loudly | Issue certificates on the new host first |
| Long TTL still cached | Hours, in confusing halves | Drop TTLs 48 hours ahead |
| Database copied before last orders | When a customer chases | Move transactional sites in a maintenance window |
| Cron jobs not recreated | Days later | Record them in the audit, verify after |
| Payment webhooks pointing at the old host | Next transaction | Update endpoints, then test one payment |
| Plugin licence bound to old IP | At the next update | Reissue licences during the move |
| MX records overwritten | Within an hour | Copy mail records before touching nameservers |
| Hard-coded absolute URLs | Random broken assets | Search-replace with serialisation support |
Six of those eight are prevented by the audit rather than by skill during the move, which is the argument for spending a week on a spreadsheet before touching anything.
What To Tell Clients
Two communications, and they do different jobs.
Ahead of the project, tell them the supplier is changing, why it benefits them, and that they do not need to do anything. Keep it short. Clients who receive a technical explanation start asking technical questions you then have to field for two hundred people.
Ahead of their specific site, only if there is something they must do or notice: a maintenance window on a store, a request not to publish during a window, or anything touching email. If the move is genuinely invisible, a second email inviting them to look for problems is not reassurance, it is an invitation.
Afterwards, say it is done. The single most useful line is the one confirming that the old environment is still available for a fortnight, because it turns "we moved your site" into "we moved your site and we can undo it".
If The Host Does The Moving
Most managed hosts will migrate sites for you, and at portfolio scale it is worth asking exactly what that covers. This is one of the things an agency hosting plan should include rather than bill for before you assume it replaces the work above.
The questions that separate a real migration service from a file copy: do they move sites by hand or run an automated importer, will they rebuild each site on a private URL for you to check before anything changes, who decides the batching, do they handle the SSL issuance ahead of cutover, and what happens if a site does not work on arrival.
Even with a host doing the moving, the audit stays yours. You are the only one who knows which client publishes every Tuesday, which plugin licence is bound to an IP, and which site cannot be down at month end. That knowledge is what makes the sequencing right, and no host can supply it.