Agencies move client sites more often than they plan to. You consolidate everyone onto your own hosting. A client switches host because a sales rep offered them a better deal. A business rebrands and wants the new domain live by a certain date. A site you have just taken over sits on a server nobody wants to touch. Each move is a small project with a large downside: if email stops, the checkout fails or the old URLs return errors, the client blames the agency, not the server.
White label WordPress migration is the arrangement where we carry out those moves for you and stay out of the client’s sight. You decide when the move happens and what the client is told; we plan it, copy it, test it and help you switch over. It sits under the broader approach in our guide to outsourcing WordPress work for agencies, and it is a different service from our migration work for business owners, which is sold directly and includes moves from other platforms.
Four kinds of move, four different risks
Host to host, same domain
The most common case. Files and database are copied to the new server, tested on a temporary address, and the domain’s DNS is pointed at the new host. The risk is concentrated in the switchover: DNS changes take time to reach everyone, and during that window some visitors see the old server and some the new one. Anything submitted to the old one, such as an order or a form entry, can be lost if nobody is watching.
Domain change
Moving to a new domain touches far more than files. Every internal link, image path and setting that stores the old address has to change, including values WordPress keeps in serialized form, which a plain find-and-replace will corrupt. Every old URL needs a redirect to its new equivalent, and the client’s Search Console property needs updating. Google’s own documentation on site moves is worth reading before any domain change, and Search Console has a Change of Address tool for this situation.
Onto your agency’s hosting
Consolidating client sites onto one account you manage is convenient and comes with responsibilities: who pays for the hosting, who owns the domain, and what happens when the client leaves. Settle those before the move rather than after. Our post on agency-managed versus client-owned hosting and domains sets out the trade-offs.
Off your hosting
The move nobody enjoys: a client is leaving, and their site has to go to a new host or a new agency. It still deserves a clean job, and a careful exit protects your reputation with a client who may come back. The post on ending a client relationship cleanly covers the access and file handover side.
The accounts are harder than the files
Copying a WordPress site is the easy part. The hard part is that a migration touches accounts that belong to different people: the old host, the new host, the domain registrar, the DNS provider if it is separate, and often an email provider. On agency client sites, those accounts are frequently spread between the agency, the client and a previous developer.
Before we plan anything, we ask you to confirm who holds each of these, and whether we can have access or whether someone else needs to make a change at a given moment. If the client holds the registrar login and will not share it, the plan includes a short, clear instruction you can send them. We never contact the client or their registrar directly.
Email is where moves go wrong
The quickest way to turn a smooth migration into a bad week is to break the client’s email. If their mailboxes are hosted on the old server, moving the domain’s DNS without planning for email means messages stop arriving or go to the wrong place. Even when email is hosted elsewhere, copying DNS records by hand can drop an MX, SPF or DKIM entry and leave messages landing in spam.
So every plan starts with a copy of the current DNS zone and a note of where email lives. If mailboxes need moving too, that becomes its own step with its own timing. Our hosting, DNS and email support for agencies covers that work when it grows beyond a migration.
How the switchover is timed
We test the copied site on the new server before the domain points at it, using a temporary URL or a local hosts-file override, so the client’s live site keeps running untouched while we check. Forms, logins, search, image loading and, on stores, the checkout are tested on the new copy. Only once you are happy do we agree a switchover time.
The time difference helps here. A switchover that happens while your US client’s business is closed and their customers are asleep falls during our working day, so the riskiest hour of the move happens when traffic is lowest. For stores, we agree a short content freeze so that no orders or edits are made on the old server after the final copy. If the client cannot pause, we plan a final sync of new orders after DNS has switched.
What your client sees
Ideally, nothing at all. The site is on a new server, it looks the same, it might load a little faster, and their email keeps working. What they hear about the move comes from you: a note before the switchover explaining when it will happen and what, if anything, they need to do, and a note afterwards confirming it is done. We can draft both in plain language for your account manager to send.
Everything we produce for you, from the migration plan to the checklist and final notes, is unbranded. If the client’s host needs to be contacted about the new account, you choose who does it and in whose name.
After the move
A site that loads on the new server is not finished. We check that the SSL certificate is valid on the new host, that redirects from HTTP and from the old domain behave as planned, that scheduled tasks still run, that outgoing email from the site’s forms is delivered, and that caching or security plugins are not still pointed at the old server’s paths. We keep the old server’s copy untouched until you confirm it can be closed.
Some problems only appear days later: a mixed-content warning on one page, a PHP version difference that breaks an old plugin, an image path stored in a page builder’s settings. If you are dealing with one of those on a site moved by someone else, our post on errors that appear after moving a WordPress site explains the usual causes.
When a migration is part of taking on a new client, it is a good moment to audit the site properly before you promise them anything. The post on checks to run before you take on a client site is useful whether or not we do the move.
What stays in your hands
You choose the destination host, approve the switchover time, decide what the client is told, and confirm when the old server can be cancelled. We bring the plan, the copy, the tests and the notes. If the move turns up work that was always needed, such as outdated plugins or a theme that will not run on a newer PHP version, we list it separately for you to quote, and it can move into our wider development and support work for agencies if you want us to handle it.
To plan a move, send the site address, where it is now and where it is going, who holds the registrar, DNS and email accounts, whether the domain is changing, and any date the client has in mind. We will reply with questions, a migration plan and an estimate before anything is copied.