Hosting Migration Runbook for Agencies (2026): Zero Surprises

A migration that “should be quick” is usually the one that spawns the longest client email thread. The cause is rarely one big mistake. It’s TTLs nobody lowered, a WordPress cron still sending from the old IP, a forgotten subdomain, or an SSL renewal that refuses to cooperate on cutover day.

This hosting migration runbook is for agencies and small IT teams moving real client sites to new shared hosting, a VPS, or a dedicated server. It’s not a checklist you print and promptly ignore. It’s a sequence based on how migrations actually fail in support tickets—and how to keep those failures out of your week.

What a hosting migration runbook should cover (and what it shouldn’t)

A runbook isn’t a “migration guide.” It won’t teach you every tool or control panel. It tells you what to decide, what to verify, and what order to do things in so timing doesn’t trap you.

• It covers dependencies: DNS, email routing, SSL issuance, backups, and rollback options.
• It names owners: who changes DNS, who validates forms, who confirms mailbox delivery.
• It defines evidence: what “passed” looks like before you cut over.
• It avoids noise: you don’t need a new monitoring stack to move a brochure site.

At Hostperl, smooth migrations usually come down to two things: one person owns the timeline, and DNS + email get treated like first-class systems—not afterthoughts.

Hosting migration runbook: choose the destination based on support realities

Pick the destination you can run confidently for the next 12–24 months. Agencies often underestimate the ongoing differences between shared hosting, a managed VPS, and a dedicated server—until the first patch window, mail issue, or noisy-neighbour incident.

Shared hosting: simplest operations, fastest “done”

Shared hosting is still a sensible choice for many client sites, especially if you want stable WordPress/PHP hosting with cPanel-style workflows and predictable costs. If traffic is modest and you don’t need custom services, shared hosting keeps you out of “server chores” like kernel updates and mail queue tuning.

If that’s your target, start with Hostperl shared hosting and treat the runbook as change management: DNS, email, SSL, and content parity.

VPS: you gain control, but you also inherit responsibility

A VPS is the usual step up when you need consistent CPU/RAM, custom PHP versions, better isolation for multiple client apps, or a dedicated mail stack. The trade-off is operations. Patching, backup verification, and performance tuning become your problem unless you’re covered by managed support.

If you’re consolidating clients from scattered providers into one place, a Hostperl VPS can simplify your workflow: one support team, one billing context, one repeatable migration cadence.

Dedicated server: for performance headroom and noisy-neighbour immunity

Dedicated makes sense when you need predictable performance under load, heavy database usage, or strict isolation. It’s also the cleanest fix for “we’ve outgrown the VPS and we’re tired of chasing spikes.” If you’re on the fence, read our comparison, then come back and commit to a target: VPS vs dedicated server for hosting in 2026.

Pre-flight: inventory the site like you’ll have to support it

Most migration surprises come from missing inventory. Before you touch DNS or copy files, write down what exists in a way you can hand to support—or a teammate who’s picking this up mid-flight.

Capture an asset map (30 minutes that saves hours)

• Domains and subdomains: apex, www, staging, app, api, mail, autodiscover, autoconfig.
• DNS records: A/AAAA, CNAME, MX, TXT (SPF/DKIM/DMARC), SRV (Microsoft/VoIP), custom verification records.
• SSL: where certificates are issued, any wildcard needs, and expiry dates.
• Email: where mailboxes live, which provider sends outbound, any forwarders/aliases, catch-alls.
• Apps: CMS, plugins, payment gateway callbacks, cron jobs, webhooks, external APIs.
• Data: database size, media library size, and any object storage/CDN use.

If DNS is already messy, clean it up before cutover day. This guide helps you diagnose what’s really happening during propagation: DNS propagation troubleshooting for hosting migrations.

Decide your migration pattern

Pick one approach and stick to it:

• Lift-and-shift: fastest; best for stable sites; higher risk of carrying old issues.
• Clean rebuild: slower; best for sites with plugin bloat or unknown history; cleaner long-term.
• Hybrid: rebuild the app but migrate content/mail; common for agency “refresh + move” projects.

Timeline planning: the three clocks that matter (DNS, email, content)

You’re managing three separate timing systems. Keep them distinct and the move stays predictable.

1) DNS clock: TTLs and propagation windows

Lower TTLs (typically to 300 seconds) at least 24 hours before you intend to cut over. If you can’t, assume a longer mixed-traffic window where some users still hit the old server.

A common failure: the domain uses third-party DNS, and nobody on the project has access. Fix access early, not on cutover afternoon.

2) Email clock: routing and mailbox consistency

Email isn’t just MX records. It includes autoconfig, SPF/DKIM alignment, rate limits, and user expectations (“my sent folder can’t split”). If email is part of the move, plan it explicitly—even if the website side looks simple.

For a practical approach that minimises downtime and confusion, keep this nearby: email hosting downtime plan for cPanel and VPS moves.

3) Content clock: database writes and the “freeze” moment

Dynamic sites don’t sit still. Orders come in. Forms submit. Comments post. Your runbook needs a clear content freeze moment, even if it’s brief:

• For brochure sites: freeze can be “no content edits for 30 minutes.”
• For eCommerce: freeze usually means maintenance mode, or at least checkout disabled.
• For membership apps: freeze is often scheduled after business hours with a clearly communicated window.

Build the new environment first (and test like a support engineer)

The safest migrations treat the new host as a parallel environment until you can prove it’s ready. “The homepage loads” isn’t proof. A tight set of checks will catch the problems clients notice first.

Minimum “launch readiness” checks

• HTTP status: 200/301 where expected; no redirect loops; www and apex behave.
• SSL: correct certificate chain; modern TLS; auto-renew set.
• Forms: contact form delivers; transactional email doesn’t land in spam.
• Uploads: media uploads work; permissions are correct.
• Performance: TTFB acceptable from NZ/AU/Asia-Pacific locations if that’s your audience.
• Backups: scheduled and restorable (a backup that can’t restore is theatre).

Stage without public DNS changes

For many agency moves, the cleanest workflow is staging via a temporary URL or hosts-file mapping. That lets you validate the new server before switching the domain. If you’re using a control panel, keep staging isolated: separate account/subscription, separate database user, separate mail routing until you’re ready.

If you’re migrating cPanel accounts specifically, these operational notes map closely to real support cases: cPanel migration best practices.

DNS cutover: reduce mixed traffic and avoid “half-migrated” behaviour

Mixed traffic is where agencies burn time. Some users hit the new server, others hit the old one, and sessions/carts fail in ways that look random. Your goal is to keep the mixed window short and make behaviour consistent while it lasts.

Cutover checklist (DNS + web)

1. Confirm TTL is low on the records you’ll change (A/AAAA and relevant CNAMEs).
2. Put the old site into a controlled state: maintenance page or content freeze.
3. Take a final sync: database + uploads (or the platform equivalent).
4. Switch DNS: update A/AAAA (and www if separate). Keep old hosting available for at least 48–72 hours.
5. Verify from multiple networks: mobile data + office ISP + an external checker.
6. Watch logs and error rates on the new host for spikes (404s, PHP errors, permission failures).

Pitfall: CDN and “shadow DNS”

If the client uses a CDN, WAF, or DNS proxy, you may not be switching origin traffic the way you think. Document whether you’re changing origin IPs, proxy status, or both. Also look for extra DNS zones at registrars or legacy providers that still answer for forgotten subdomains.

Email during migrations: stop the quiet failures

Email problems rarely show up immediately. They appear the next day as missing messages, split sent folders, or delivery failures to one specific provider. Plan for a predictable user experience, plus a rollback you can execute quickly.

Decide: keep email where it is, or move it?

Many agencies move the website and leave email untouched. That’s often the right call if the existing mail service is stable and properly authenticated. If you are moving email, treat it as its own mini-project with its own testing and sign-off.

Practical validations that catch 80% of pain

• Outbound auth: SPF includes the new sending host; DKIM signs; DMARC aligns.
• Inbound delivery: test from Gmail + Microsoft + an external domain; confirm the message lands.
• Webmail access: users can log in and send. If you’re on cPanel, this helps users quickly self-serve: setup cPanel webmail access.
• Forwarders and aliases: confirm any business-critical forwarders still work (sales@, accounts@). For cPanel teams, keep this handy: setup email forwarders in cPanel.

Support reality: email reputation can dip after IP changes

If outbound mail moves to a new server/IP, some recipients may treat it cautiously for a short period. That’s normal. Plan for a warm-up: don’t blast newsletters on cutover day, and watch bounces and complaints closely.

SSL and security: keep renewals and admin access predictable

SSL is rarely complicated, but it often gets pushed to the last minute. That’s how you end up cutting over to a browser warning.

What to lock in before cutover

• Certificate coverage: apex + www + any app subdomains.
• Auto-renew mechanism: Let’s Encrypt or your preferred CA, installed and renewing.
• Admin access: confirm the right people can access the control panel and server.

On VPS and dedicated hosting, set a basic hardening baseline (SSH access hygiene, sensible firewalling, and brute-force protection). Not glamorous—just required. If you need a sensible starting point, see: VPS security hardening.

Backups and rollback: define “undo” before you touch anything

Rollback is what keeps you calm. Without it, every small issue turns into a crisis.

Rollback options to decide upfront

• DNS rollback: switch A/AAAA back to the old IP. Works best when TTLs are low.
• App rollback: restore files + database from a known-good snapshot on the new host.
• Partial rollback: keep web on new host but route email back to the old provider if mail breaks.

Make a restore test part of the runbook

A backup job that “ran” doesn’t mean you can restore. For at least one representative site, do a test restore to a staging location. You’ll quickly uncover permission issues, missing database users, or incomplete archives.

Launch day: communication that reduces support load

Clear communication prevents urgent tickets. Build a short message template into your runbook, plus a simple list of what clients should expect.

Client message template (copy/paste)

Internal “war room” checklist

• One owner for DNS changes and confirmation.
• One owner for web validation (forms, logins, payments).
• One owner for email validation (send/receive, SPF/DKIM/DMARC alignment).
• A single place to record findings (ticket, doc, or project board).

After cutover: the 72-hour stabilisation window

Don’t declare victory at “DNS changed.” The real test starts when normal users come back on their usual devices, networks, and saved passwords.

What to watch (and why)

• 404 spikes: often missing rewrite rules, case-sensitive path issues, or forgotten subdomains.
• 500/PHP errors: plugin incompatibility, PHP version mismatch, missing extensions.
• Cart/login complaints: mixed traffic or session storage differences.
• Email delivery: bounces, spam-folder placements, or intermittent delays.

Close-out tasks agencies forget

• Cancel the old hosting only after you’re certain no services still depend on it.
• Remove stale DNS records that point to the old IP (after you’ve confirmed they’re unused).
• Rotate passwords that were shared during the migration window.
• Document the new environment: panel logins, backup locations, renewal dates, and support contacts.

Summary: your runbook is a support tool, not just a plan

A good runbook makes migrations boring. It sets expectations, shortens mixed-traffic time, and gives you rollback options you can execute under pressure. If you handle multiple client moves each quarter, this becomes a reusable asset that saves real hours.

If you want a hosting environment that fits agency work—predictable performance, straightforward control panel operations, and a team that handles migrations daily—start with a managed VPS hosting plan or, for larger client fleets, consider Hostperl dedicated server hosting. Either way, we’ll help you plan cutover steps around your clients’ hours and your risk tolerance.

FAQ

How far ahead should I lower DNS TTL before a cutover?

Lower it 24–48 hours in advance where possible. That gives caches time to age out so your switch happens quickly and predictably.

Should I move email and website hosting at the same time?

Not always. If the current email service is stable, leaving email in place can reduce risk. If you do move email, plan it as a separate stream with separate validation and rollback.

How long should I keep the old hosting active after migration?

Keep it for at least 48–72 hours, longer if TTLs couldn’t be lowered or if the site has many integrations. It’s cheap insurance while you confirm nothing still depends on the old environment.

What’s the fastest way to detect mixed traffic problems?

Check for inconsistent sessions (logins/carts), conflicting content edits, and intermittent form failures. Mixed traffic often shows up as “it works for me but not for my colleague.”

What’s the single best ‘proof’ that a migration is safe to cut over?

A short set of validations you can repeat: homepage + key pages, login, a form submission, an upload, and an email send/receive test. If those pass on the staged environment, you’re usually in good shape.