Hosting migration checklist: move sites with less downtime

A migration that “mostly worked” still costs you

A hosting migration checklist sounds obvious until you’re explaining a missing mailbox, a broken SSL chain, or a stale DNS record to a client who expected a quiet move. Most migration pain isn’t caused by the server build. It comes from the handoffs between systems: DNS, mail routing, TTL timing, certificate installs, and the small-but-decisive differences between shared hosting and a VPS.

This is an operations-first checklist for moving websites (and email) with less downtime and fewer surprises. It’s aimed at small businesses, agencies, and in-house teams that want a controlled cutover—not a late-night scramble.

Hosting migration checklist: decide what you’re actually moving

Before you touch DNS or spin up a new server, lock the scope. Migrations go sideways when “the website” is treated like a single thing. In practice, you’re often moving several services that just happen to share a domain.

• Web: WordPress/PHP app, static assets, uploads, cron jobs, rewrite rules.
• Database: MySQL/MariaDB/PostgreSQL, user permissions, scheduled backups.
• Email: mailboxes, forwarders, aliases, autoresponders, spam filters.
• DNS: A/AAAA, CNAME, MX, TXT (SPF/DKIM/DMARC), SRV records.
• SSL: certificates, renewal automation, HSTS implications.

Support reality: the most common “post-migration bug” isn’t an application bug. It’s a missing record (often a TXT record) or mail flow breaking after MX changes.

Pick the destination that matches your workload (not your mood)

Moves go smoother when the destination matches what the site actually does. Under-size the plan or pick the wrong hosting type and you’ll “finish” the migration, then immediately start chasing performance issues.

• Shared hosting works for brochure sites, small WordPress installs, and email-first domains. If you want the simplest operational experience, see Hostperl shared hosting.
• VPS hosting fits growing sites, agencies with a few client sites, and apps needing custom PHP versions, server-side caching, or tuned database resources. This is the most common migration destination we handle: Hostperl VPS.
• Dedicated servers are for high traffic, heavy databases, busy WooCommerce, or compliance-driven environments that need isolation and predictable performance. Start here: Hostperl dedicated servers.

If you’re unsure, do a quick sanity check using numbers you can verify: peak concurrent users, database size, average CPU during traffic spikes, and email volume. For a sizing framework that maps to real hosting workloads, read our VPS sizing checklist.

Inventory and risk-map the current account

Do this before you copy a single file. You’re creating a “what exists” record so you can verify the move later. If you’re migrating for a client, this is also where you get clear on what’s included.

• Domains and subdomains: list every hostname in use (www, app, mail, staging, autodiscover).
• DNS exports: screenshot or export the current zone. Pay attention to non-obvious TXT records.
• Email list: mailboxes, forwarders, catch-all, aliases, autoresponders, filters.
• SSL details: current certificate issuer, expiration, whether HSTS is enabled.
• App behavior: cron jobs, background tasks, scheduled imports, webhook endpoints.
• Disk usage: total footprint and “large directories” (uploads, backups, cache).

Pitfall: agencies often move the site cleanly, then get caught by the “non-website” pieces—webhook endpoints on subdomains, or DNS TXT records used for third-party email and verification services.

Lower DNS TTL early (and do it safely)

DNS controls where users land. If TTL is high, your “cutover time” is mostly hope.

• 48–72 hours before cutover, lower relevant TTL values to 300 seconds (5 minutes).
• Only lower records you plan to change: typically A/AAAA for root and www, and possibly MX if moving email.
• Leave unrelated records alone. Extra edits create extra risk.

If you want a plain-English view of what happens after you change DNS, including what “propagation” looks like for customers in different regions, see DNS propagation for hosting migrations.

Backups: take one you can restore, not one you can brag about

You need at least two backups: one before any changes, and one just before cutover. If email is in scope, treat it as its own backup job, not an afterthought.

• Files: verify archive integrity (don’t trust a zip that never gets tested).
• Database: confirm you can import the dump into a test database without errors.
• Email: export mailboxes or ensure server-side migration copies messages accurately.
• DNS: save the full zone file so you can reconstruct quickly.

Quick operational check: store at least one backup off-server (object storage, external backup location, or your own secure archive). A backup sitting on the same hosting account won’t help during account suspension or disk failure.

Stage the new environment like you’re going live tomorrow

Staging is where you win the migration. Build the destination so it’s production-ready before you send real traffic to it. Control panels help here: cPanel, Plesk, and DirectAdmin reduce the odds you miss a key setting during a busy week.

• Create accounts and vhosts: ensure document root paths match your plan (avoid “mystery paths”).
• PHP version and extensions: match the current site, then plan upgrades after go-live.
• Database server settings: set sane limits (connections, buffer sizes) appropriate to your plan.
• Uploads and permissions: confirm the web server user can write where needed, and nowhere else.

If you’re staging on Ubuntu and hosting multiple sites, consistent vhost structure makes troubleshooting faster. Our support team often references this pattern: Apache virtual hosts on Ubuntu.

SSL and HTTPS: plan the certificate story before cutover

SSL failures are loud because browsers don’t negotiate—they block. Decide how certificates will work on the destination before you switch traffic.

• Option A: re-issue via Let’s Encrypt on the new server. This is usually simplest.
• Option B: move existing certificates (common for EV/OV or third-party-managed certs).
• Option C: use a control panel’s integrated SSL tooling and renewal automation.

If you use HSTS: treat it as a hard constraint. Once browsers cache HSTS, users will force HTTPS even if you’re temporarily misconfigured. Don’t cut over until HTTPS is correct.

For multi-domain and SAN certificate setups, this guide is a solid baseline: multi-domain SSL with Certbot.

Email: decide whether you’re moving it, relaying it, or leaving it alone

Email is where “simple” migrations turn into long support threads. Start with a clear strategy. There isn’t a single best choice—just tradeoffs.

• Leave email where it is: common if your email already runs on Microsoft 365/Google Workspace. You’ll still need to preserve TXT records and MX records.
• Move email with the website: typical for cPanel/Plesk-based email hosting where mailboxes live on the same host.
• Use a relay: send mail through a trusted relay while you stabilize deliverability on a new IP.

If you’re moving mailboxes, plan extra time for syncing and testing. A web cutover might take minutes; a full email move can take hours, especially with large IMAP mailboxes.

Two practical references our customers use a lot:

• Email hosting migration plan (cPanel/Plesk/VPS)
• VPS email hosting checklist

Deliverability pitfall: moving to a new server IP means updating SPF records and making sure DKIM signing matches the new host. If you miss this, mail can land in spam—or fail DMARC alignment outright.

Data sync: treat the “final copy” as a separate event

Most sites can’t pause publishing for long. A two-pass sync is the simplest way to avoid a long freeze on typical SMB moves.

• Pass 1 (bulk copy): copy site files and import the database to the new host.
• Verification window: test the staging site without changing public DNS (hosts file, temporary URL, or panel preview).
• Pass 2 (final sync): re-sync files that changed and re-dump/re-import the database close to cutover.

If the site writes constantly (WooCommerce orders, membership sites, forums), schedule a short maintenance window. Even 10–20 minutes in “read-only” mode can prevent data divergence that’s painful to unwind later.

Pre-cutover testing that catches real failures

Don’t stop after clicking the homepage. Test the paths that create support tickets.

• Checkout / forms: payment gateways, contact forms, SMTP sending, captcha callbacks.
• Login flows: session persistence, cookies, redirects, SSO.
• Media and uploads: upload a file, view it, delete it.
• Search: WordPress search, internal site search, or app-level queries.
• Admin tasks: plugin updates, image regeneration, background processing.

Quick diagnostic tip: if pages load but wp-admin (or your admin area) drags, check PHP opcache and database latency first. NVMe helps, but only if disk I/O is the real bottleneck. If you’re weighing that tradeoff, see when NVMe matters on a VPS.

Cutover communications: set a window, set expectations

Cutovers run cleaner when everyone knows what “normal” looks like. For agencies, this also reduces the client habit of repeatedly checking DNS and assuming something is broken.

• Share a cutover window (start time, expected duration, and “verification complete” time).
• Define what you will monitor: website availability, admin login, form delivery, and email send/receive.
• Agree on a content freeze if the site is write-heavy.
• Provide a rollback rule: “If X fails after Y minutes, we revert DNS.”

If your site is revenue-critical, pair this with a launch readiness review. This checklist helps even when you’re not migrating: Hosting uptime checklist.

Post-cutover: monitor the boring stuff that breaks first

The first 24 hours matter. Not because servers are fragile, but because caches expire, background jobs start running, and third-party services finally notice you moved.

• HTTP status codes: watch for 404 spikes and redirect loops.
• Error logs: PHP errors, permission issues, plugin failures.
• Email queue and bounces: sudden outbound failures or “rate limited” responses.
• Disk growth: log files and caches can fill small disks fast after a move.
• Backups: confirm scheduled backups run on the new host.

One easy win after migration is tighter operational reporting. Daily log digests catch problems early, especially for agencies managing multiple client sites. Example: Logwatch daily digests on Ubuntu.

Rollback planning: your checklist needs an “exit ramp”

Rollback isn’t failure. It’s basic risk management. You want a known, rehearsed path back to stable service if something unexpected shows up.

• Keep old hosting active for at least 7 days (often 14) after cutover.
• Don’t delete the old DNS zone export or old SSL assets immediately.
• Document what changed: DNS records, mail routing, cron jobs, app config.
• Have a “rollback trigger” (payment failures, login failures, email loss).

Support reality: rollback is fastest when you changed fewer things at once. If you also upgraded PHP, switched web servers, and changed email providers in the same move, rollback gets messy. Migrate first. Upgrade second.

Where Hostperl fits: migration-friendly hosting choices

Hostperl is a New Zealand-based hosting provider. We spend a lot of time helping customers move without DNS, email, and SSL surprises—especially across NZ/AU/APAC where resolver caches and user locations can vary.

• If you want the simplest management path for small sites, start with shared hosting and move up only when your workload demands it.
• If you’re moving from shared hosting because you’ve outgrown limits or need consistent performance, choose a Hostperl VPS sized for your peak hours, not your quiet hours.
• If your migration is driven by heavy databases or sustained traffic, step into dedicated server hosting and stop fighting noisy-neighbor constraints.

Not sure which tier fits your scope? Read these upgrade signals and decide based on symptoms you can confirm.

FAQ: quick answers for common migration questions

How long should a hosting migration take in 2026?

For a typical SMB site, the build plus bulk copy usually fits into a day. Once testing is done, cutover is often minutes. Email adds time—sometimes hours—depending on mailbox size and whether you’re doing a parallel sync.

Should I migrate website and email at the same time?

Only if you need to. Moving both raises the coordination cost: MX records, SPF/DKIM, and mailbox sync. If your email is already stable and separate (Microsoft 365/Google Workspace), leaving it alone reduces risk.

What’s the safest TTL for cutover?

300 seconds is a practical target for records you plan to change. Lower it 48–72 hours ahead of time so caches expire naturally before your migration window.

Why does the site work for me but not for some users after DNS change?

Different networks cache DNS differently. Some users may still hit the old server until their resolver refreshes. That’s normal during the propagation window, especially if you didn’t lower TTL in advance.

What should I monitor first after cutover?

Start with HTTP errors, PHP/app errors, contact form delivery, and email bounces/queues. Those tend to surface user-impacting issues first.