If your agency hosts dozens of client sites, moving to a new VPS or dedicated server is one of the riskiest jobs on your calendar. The question is rarely whether it can be done. It is whether your own team should do it, or whether to bring in specialists. This guide compares outsourced vs in-house server migration for WordPress agencies, so you can decide based on your real constraints. If you already know you want help, you can talk to our server migration team.
Why Moving Many WordPress Sites Is Harder Than Moving One
Migrating a single WordPress site is a well-understood task. Migrating thirty, sixty or a hundred of them at once is a different kind of project, because the problems multiply and interact. Each site has its own PHP version needs, plugins, cron jobs, caching setup, file permissions and database. Some will have custom Nginx or Apache rules that nobody documented. Others will rely on a specific extension that exists on the old server only because someone installed it years ago.
On top of the sites themselves, there is everything around them:
- DNS cutover: lowering TTLs ahead of time, choosing the order of sites, and handling domains whose DNS is managed by the client rather than by you.
- Email: mailboxes, forwarders, SPF, DKIM and DMARC records, and any site that sends mail through the old server.
- SSL: reissuing certificates, validating domains before the cutover, and avoiding browser warnings at the moment of switching.
- Rollback: keeping the old server intact and able to serve traffic if something fails on the new one.
Agencies feel this more sharply than most because the clients are not abstract. Every site that breaks is a phone call to your account manager, and the cost lands on your reputation.
What an In-House Migration Really Involves
Doing it yourself has real advantages. Your team knows the sites, the clients and the quirks. There is no handover of credentials to a third party, and no one else needs to learn your stack. For a small number of simple sites on a familiar control panel, an in-house migration can be perfectly sensible.
The hidden cost is time and focus. Your developers and support staff are also running day-to-day client work. A migration needs careful inventory, a staging copy of every site, test plans, scheduled cutover windows and a clear person on call afterwards. If those people are pulled between tickets and the migration, steps get skipped. The most common casualties are the unglamorous ones: email records, cron jobs, redirect rules and certificate renewals.
In-house also means the person who knows the process may be one person. If they are unavailable on cutover day, the plan stalls. Be honest about whether your team has done a migration of this size before, because the first time is when mistakes are most likely.
What an Outsourced Migration Really Involves
Outsourcing means a specialist team handles the audit, the build of the new server, the data transfer, testing and cutover, usually while your team continues normal work. The main benefit is experience with the failure modes: mismatched PHP versions, hard-coded paths, mail records that break silently, and certificates that fail to issue because DNS has not propagated.
The trade-offs are also real. You must share access, so you need to trust the provider and agree how credentials are handled and removed afterwards. You need clear communication, because the provider does not know your clients as well as you do. And you should check who owns the documentation and runbooks at the end, so you are not dependent on the vendor for the next move.
Outsourced vs In-House: Side-by-Side Comparison
The table below summarises how the two approaches typically differ for a multi-site WordPress agency. It is a general guide, not a promise about any specific provider.
| Factor | In-house migration | Outsourced migration |
|---|---|---|
| Knowledge of your sites | Strong, since your team built or maintains them | Built during the audit, so you need to share context |
| Migration experience | Depends on whether the team has done similar moves | Usually repeated experience with common failure modes |
| Impact on daily work | High, as staff are pulled from client tickets | Lower, as your team stays on client work |
| DNS, email and SSL handling | Easy to overlook under time pressure | Should be an explicit part of the plan |
| Rollback readiness | Often improvised | Should be agreed and documented before cutover |
| Access and security | Credentials stay internal | Requires scoped, temporary access |
| Cost shape | Staff time and opportunity cost | Agreed scope and fee |
| Documentation afterwards | Often thin unless someone is assigned to it | Should be a deliverable you own |
How to Decide Which Route Fits Your Agency
Rather than looking for a universal answer, ask a few direct questions:
- Have we done a multi-site migration before? If yes, and it went well, in-house is more realistic.
- Who is free during the cutover window? If the same people handle support, the migration will compete with live issues.
- How much downtime can each client tolerate? Sites with stores, bookings or lead forms need a more careful plan.
- Do we know where all email is handled? If not, the audit alone is a reason to get help.
- Is the old server ageing or at risk? A deadline you do not control raises the stakes.
A hybrid approach also works well. Some agencies keep the simple sites in-house and hand the complex ones, such as WooCommerce stores, multisite installs and sites with custom mail setups, to specialists.
Common Mistakes Agencies Make During Server Moves
Whether you outsource or not, the same avoidable mistakes appear again and again. Knowing them helps you plan around them.
- Leaving DNS TTLs high. If records are cached for a long time, some visitors keep reaching the old server after cutover, and rollback becomes slow too.
- Forgetting outbound email. Contact forms and order notifications often send through the old server. If the new one is not authorised in SPF and DKIM, messages land in spam or vanish.
- Switching off the old server too early. Keep it available until you are certain nothing still depends on it, including cron jobs and webhooks.
- Testing only the home page. Logins, checkouts, search, file uploads and admin screens break more often than the front page.
- Skipping client communication. A short notice about the cutover window prevents panic if a client notices a brief blip.
Most of these come down to one thing: treating the migration as a file copy rather than a change to a live production environment with many moving parts.
Checklist: What a Safe Multi-Site Migration Must Cover
Whichever route you choose, make sure the plan includes each of the following before you start.
Before the move
- A full inventory of sites, domains, PHP versions, plugins, cron jobs and databases.
- A list of where DNS and email are hosted for every domain.
- Lowered DNS TTLs well ahead of the cutover.
- A complete backup that you have tested by restoring it.
During the move
- Staging copies of each site tested on the new server before any DNS change, for example by editing a local hosts file.
- A migration order that moves low-risk sites first.
- SSL issued or imported so certificates are valid at switch time.
- Mail records (MX, SPF, DKIM, DMARC) reviewed and matched on the new server.
After the move
- Checks on forms, checkout flows, logins, scheduled tasks and outgoing email for every site.
- The old server kept running, untouched, until you are confident everything works.
- A defined rollback path that says exactly how to point DNS back.
- Updated documentation for the new environment.
Questions to Ask Any Migration Provider
If you outsource, put these questions to every provider you consider:
- How do you audit the existing server before quoting?
- How do you handle DNS, email and SSL during cutover?
- What is the rollback plan and who decides when to invoke it?
- How is access granted, limited and revoked?
- Will we receive documentation of the new server setup?
- Is there a clear written scope, so there are no surprise charges?
Vague answers are a signal. A good provider can explain their process in plain terms and is happy to put scope in writing.
Why WordPress Agencies Choose CloudHouse for Server Migration
Agencies come to us because they need the migration done without putting their client relationships at risk. We plan around the things that go wrong on multi-site moves: DNS timing, mailboxes and mail records, SSL issuance and a rollback route you can trust. We work alongside your team, so you stay in control of client communication while we handle the technical move.
Conclusion: Choose the Route That Protects Your Clients
In-house migration makes sense when your team has the experience, the time and a quiet window. Outsourcing makes sense when the estate is large, the clients are sensitive to downtime, or your people are already stretched. Either way, a written inventory, tested backups, a clear email and SSL plan and a rollback path are not optional. If you want a specialist to review your environment and propose a scope, request a server migration quote. CloudHouse agrees scope and price only after reviewing your environment, so you know what you are getting before work starts.
