Ask an agency owner why they are still with a host they complain about weekly and the answer is never price, features, or loyalty. It is fear of the move. Fifty client sites, fifty sets of DNS, hundreds of mailboxes, and one imagined catastrophe: the Tuesday morning when a client rings to say their site is gone and their email with it.
The fear is rational — badly run migrations really do go that way. But a well-run migration is not a leap; it is a checklist executed in a sensible order, and the failures that make the horror stories all come from skipping the same few steps. Here is how a client-book migration works when it is done properly, and — since the receiving host does most of the work — what you should demand from any host before trusting them with yours.
Step one: audit before anything moves
Every calm migration starts with an inventory, and every disastrous one starts without it. Before a single file is copied, you need, per client:
- What actually runs the site. Platform and version, PHP version, database, cron jobs, and the awkward extras — that one client’s licensed plugin, the other one’s ancient bespoke booking system pinned to an old PHP branch.
- Where the domain is registered and who controls it. The single most common source of migration delay is discovering, mid-move, that the domain is registered to a director who left in 2019, at a registrar nobody has credentials for. Find these cases in week one, not on cutover night.
- The complete DNS zone. Not just the website records — the MX records, the SPF and DKIM entries, the verification TXT records for the client’s other services, the forgotten subdomain that turns out to run their warehouse system. Anything not copied is something that breaks silently.
- Email reality. Which mailboxes exist, how big they are, who actually uses them, and what devices they collect on. Mail is where migration mistakes hurt most, because lost mail is unrecoverable in a way a re-uploaded website is not.
A competent receiving host will run this audit with you rather than handing you a form. It is also your first quality signal: a host that starts by asking for your zone files and mailbox lists is planning; a host that starts by asking for your card details is hoping.
Step two: build and verify in parallel — while the old site still runs
The cardinal rule of zero-downtime migration is that nothing is switched until the new copy is proven. Each site is replicated onto the new platform — files, database, correct PHP version — while the original continues serving traffic. Then it is tested against a checklist, not a glance: pages render, forms submit and their notifications arrive, checkout completes in test mode, admin logins work, SSL is issued and valid.
The professional trick is that all of this happens before any DNS changes, by pointing a test hostname (or a local hosts-file override) at the new server. Your client’s live site is untouched; the new one is being rehearsed. If something is wrong, you have found it at leisure on a copy — not at midnight on the live site. This is also where per-site staging pays off: on FXRM’s Enhance-based platform each site is verified on the new infrastructure before cutover, and the migration of an agency’s first five client sites is done by FXRM’s team, free — with payment only after every migrated site is verified live. That “verified before you pay” structure is worth looking for from any host, because it aligns their incentives with your checklist.
Step three: the DNS choreography
Cutover is a DNS change, and DNS rewards preparation. Two details do most of the work:
Lower the TTLs in advance. A DNS record’s TTL tells the world’s resolvers how long to cache it. If your records carry a 24-hour TTL on cutover day, some visitors will reach the old server for a day after the switch. Drop the TTLs to a few minutes at least a day or two beforehand, and propagation stops being the bogeyman of hosting folklore — the change completes in minutes, and rollback (just point the record back) is equally fast.
Move the records, then the delegation. Recreate the full zone on the new nameservers first, verify it answers correctly, and only then change the delegation at the registrar. For agencies moving to white-label nameservers as part of the move — your own ns1.youragency.co.uk on FXRM’s PowerDNS infrastructure, with DNSSEC — this is the moment your brand takes over the top of the client’s stack, and it deserves the same verify-first discipline as everything else.
Keep the old hosting live and paid for through the transition. It is your rollback plan and your safety net for stragglers on stale DNS, and one overlapping month costs less than one panicked evening.
Step four: email, the part that actually keeps people up at night
Websites are stateless; mailboxes are not. The mail plan needs three things done in order. First, provision every mailbox on the new platform before MX records change, and copy existing mail across so the moment a user reconnects, their history is there. Second, sequence the MX change carefully — mail in transit retries for days by design, so a correctly executed MX cutover loses nothing, but a mailbox that does not exist yet on the new side turns retries into bounces. Third, re-verify authentication after the move: the SPF record must reflect the new sending infrastructure, DKIM keys must be published for the new platform, DMARC kept intact — on FXRM these are configured on every domain as standard, so the post-move state is stronger than most client books’ pre-move state, with email continuity handled as part of the managed migration rather than left as your homework.
Step five: batches, not big bangs
Never move fifty sites in a weekend. Move three the first week — sensible, low-drama clients whose sites you know well. Verify, learn, refine the checklist. Then move in batches of five or ten, on a rhythm, with each batch boringly identical to the last. Batching turns an existential project into a routine, contains any surprise to a small blast radius, and gives you a genuine story for the nervous clients: “we have done this thirty times this month”.
On client communication, experienced agencies converge on the same advice: do not announce a Migration with a capital M. Tell each client, briefly and confidently, that their site is being moved to newer, faster UK infrastructure on a given date, that no action is needed, and that email carries on as normal. Anxiety is contagious; so is calm.
Step six: the hypercare week
The migration is not finished at cutover; it is finished a week later. Keep a short “hypercare” period per batch: watch the new sites’ logs and uptime monitoring, check that scheduled jobs actually fired on the new platform, confirm contact-form and order emails are arriving (send test ones — do not wait for silence to be noticed), and sweep DNS for any stragglers still resolving to the old infrastructure. Most snags found in this window are ten-minute fixes; the same snags found by a client three weeks later are trust repairs. When the week passes quietly, decommission deliberately: final backup of the old environment taken and archived, then the old account closed — on a date in the diary, so you do not pay two hosts out of inertia for a year.
What to demand from the receiving host
The migration is the receiving host’s audition. Hold them to this:
- They do the heavy lifting — audit, replication, mail copy, DNS choreography — with a named human you can actually talk to, not a knowledge-base article and good luck.
- Verification before payment. You should not be paying for infrastructure that has not been proven live.
- Zero-downtime as method, not slogan. Ask them to describe the sequence — if the answer does not involve TTLs, parallel running, and mail continuity, the slogan is doing the work.
- Engineers on the phone during cutover windows — including evenings, because sensible cutovers happen outside business hours.
- Somewhere better to arrive. The move is only worth making if the destination fixes what made you leave: per-client isolation, no per-account licence fees eroding your margin, email authentication by default, UK data centres, and support that speaks your language.
FXRM’s standing offer to agencies is built on exactly this shape: first five client sites migrated free, full DNS transfer, email continuity, zero downtime, nothing to pay until everything is verified live. Not because migration is trivial — but because a host that runs migrations every week has the checklist, and a host confident in its platform can afford to let the results close the deal.
The angry phone call never comes from the client whose site was moved carefully. It comes from the client whose agency stayed too long on a platform everyone had stopped trusting. Move deliberately — but move.
