Will my emails break after the migration?

Not if MX, SPF, DKIM, and DMARC records are inventoried and moved precisely before the DNS switch — email only breaks when those records are forgotten.

Cloud Migration Checklist

Home

Checklists

Cloud Migration

This checklist is for companies moving their websites and systems from shared hosting, on-premise servers, or an ageing VPS to modern cloud infrastructure. "Cloud migration" is not copying files and flipping DNS; it covers databases, email, cron jobs, third-party integrations, monitoring, and a written rollback plan for when cutover night does not go to script. We compiled 72 practical items from migrations we have actually run over 12+ years — written by sysadmins, not marketers.

Tick each item as you complete it — your progress is saved automatically in your browser, and you can print the checklist or download it as a DOCX to share with your team.

⬇️ Download the checklist (DOCX)

0/72

0% Reset

1 Assessment & inventory 0/8

Inventory every application and map its dependencies. List every site, service, and database and what talks to what — the forgotten dependency is always the first thing to break after a move.
Record current server specs and a utilization baseline. Monitor CPU, RAM, disk, and IO for at least two weeks; real usage — not the spec sheet — is what you size the new environment from.
Measure data volume and growth rate. Database and file sizes plus monthly growth determine transfer time, the sync plan, and the storage you need.
Inventory licenses tied to the current server. Control panels (cPanel/Plesk), commercial plugins, and some database licenses are bound to hardware or core counts and may need transferring or repurchasing.
Define compliance and data-residency requirements. Some sectors legally require data to stay inside a specific country — this constrains provider and region choice before anything else.
Identify stakeholders and agree freeze windows. Decide in advance who signs off on cutover, and freeze code and content changes around the migration date.
Document your current monthly cost baseline. Hosting + licenses + admin time; without a cost baseline you will never know whether the cloud actually saved you money.
Define measurable success criteria. Target response time, acceptable error rate, cost ceiling, and recovery objectives (RTO/RPO) — otherwise nobody knows when the project has actually "succeeded".

2 Planning & architecture 0/9

Choose a migration strategy per application. Rehost (lift-and-shift as-is), replatform (small changes such as a managed database), or refactor (rebuild for the cloud) — the right answer differs app by app.
Set provider and region selection criteria. Latency to your users, the services you need, egress pricing, and data-residency requirements.
Write a sizing and autoscaling plan. Size from the measured baseline plus sensible headroom, and define when and how the system scales at peak.
Design the network: VPC, firewall, VPN. Isolated private networks, explicit firewall rules, and admin access only via VPN or fixed IP addresses.
Plan the DNS TTL reduction. Lower TTLs to 300 seconds 24–48 hours before cutover so the DNS switch propagates in minutes instead of a full day.
Write a backup and rollback plan. Define the decision point: when do we roll back, who decides, and how do we return to the old environment in minutes rather than hours?
Prepare a migration runbook with an owner per step. Every step in order, with expected duration and a named owner — nothing left as "implicitly understood".
Plan a staging environment matching the target. A full replica of the new environment to test against before touching production.
Get written sign-off on budget and timeline. With buffer for both time and cost; migrations rarely follow the plan to the letter.

3 Security & compliance 0/8

Apply a least-privilege access model. SSH keys instead of passwords, a named account with sudo for each person, and never a shared root login.
Manage secrets outside the code. Database passwords and API keys live in environment variables or a secrets store — never in the code or the Git repository.
Plan encryption at rest and in transit. Disk encryption, plus SSL/TLS certificates ready for every domain before cutover day, not after it.
Set a firewall and security-groups baseline. Deny by default, and open only the ports each service genuinely needs.
Prepare DDoS protection and a WAF. A service such as Cloudflare in front of the site — enabled on the new environment before the DNS switch, not after the first attack.
Enable centralized audit logging. Who logged in, who ran what, and when — with a defined retention period and a central place for logs.
Define a patching policy. Who updates the OS and packages, and when? Enable unattended security updates as a minimum.
Verify data protection and residency before moving data. Confirm the chosen region actually meets your legal requirements before the first byte is transferred.

4 Migration execution 0/8

Provision and harden the target first. Build the servers and apply the full security baseline before any real data arrives.
Migrate databases with real verification. After the transfer, compare checksums and row counts between source and target — "completed without errors" does not mean the data matches.
Sync files with rsync — dry-run first. Start with a dry-run to review what will move before it moves, and watch permissions, ownership, and symlinks.
Replicate cron jobs and queue workers. Per-user crontabs, systemd timers, Supervisor processes, and queue workers — the single most forgotten item in any migration.
Inventory email and DNS records completely before cutover. MX, SPF, DKIM, DMARC, every subdomain, and API senders — migrate them precisely, or leave external mail strictly untouched.
Install monitoring agents before cutover, not after. You want metrics and alerts live at the moment of the switch, not installed after the first outage.
Run an initial sync, then a delta sync. Move the bulk of the data days ahead, leaving a small delta that transfers in minutes on cutover night — this is the secret behind "near-zero downtime".
Keep the old environment as a read-only fallback. Do not shut it down or wipe it; set it read-only until every post-cutover check has passed.

5 Validation & cutover 0/8

Run a full functional test via a staging URL or hosts file. Point your machine at the new server through the hosts file and test every page and function before any visitor sees it.
Compare performance against the old baseline. Response times on the new environment must match or beat the old ones — fix any regression before cutover, not after.
Validate SSL certificates on every domain. Every domain and subdomain must serve a valid, current certificate from the new server.
Test forms, payments, and integrations end to end. Real test purchases, webhooks, and third-party callbacks — from first click to final notification.
Switch DNS in a low-traffic window. With TTLs already lowered, and a named person actually watching while the change propagates.
Monitor error rates for the first 24–48 hours. Logs, queues, cron output, and error rates — most real problems surface in the first two days.
Verify that backups actually restore. Perform a real restore from a backup of the new environment; a backup that has never been restored does not count as a backup.
Communicate the cutover to stakeholders. One notice before the window and one after it succeeds, with a support team ready to respond.

6 Post-migration optimization 0/7

Decommission old servers only after 2–4 weeks. After a full billing cycle and complete verification of every function — and keep a final snapshot before cancelling.
Right-size instances from real usage. After two weeks of real metrics, scale servers down or up — initial sizing is always an estimate.
Set cost alerts and budgets. Directly with the provider and with clear thresholds, so the monthly invoice is never your first warning.
Enable a CDN and caching layers. A CDN for static assets and the right cache for the app (OPcache/Redis/page cache) — usually the biggest performance win after migrating.
Document the new architecture now, not later. An architecture diagram, an access list, and operations runbooks — while the team's memory is still fresh.
Run a disaster-recovery drill. Simulate a full failure and measure actual recovery time against the agreed RTO/RPO targets.
Schedule periodic security reviews. A quarterly review of patching, access rights, open ports, and logs — security is an ongoing process, not a ticket you close.

7 Database migration checklist (deep-dive) 0/8

Choose dump-and-restore vs replication based on your downtime budget. A plain dump/import is simplest but freezes writes for the whole import; binlog replication keeps the new database in sync and shrinks cutover downtime to seconds.
Match engine versions, charset, and collation before importing. Import into the same or a newer database version, and verify utf8mb4 and collation settings match — mismatches corrupt Arabic and emoji text silently, and you find out from customers.
Verify row counts and checksums after every sync. Compare table row counts and checksums (CHECKSUM TABLE or pt-table-checksum) between old and new — "the import finished without errors" is not proof the data is complete.
Migrate users, grants, triggers, events, and stored procedures explicitly. Default dump settings skip some of these; an application that connects fine but fails on one nightly job usually lost an event or a grant.
Plan a delta sync for cutover night. After the initial bulk copy, sync only what changed (replication catch-up or targeted re-dump of hot tables) so the final switch moves minutes of data, not days.
Schedule a short read-only window for the final delta. A few minutes of read-only mode at your lowest-traffic hour guarantees zero lost orders during the last sync — announce it and script it in advance.
Rebuild statistics and compare the slow-query baseline after import. Run ANALYZE/OPTIMIZE on the new server and compare the slow-query log against the old baseline — different RAM and disk change the query planner's behavior.
Test the application against the migrated database at production data volume. Queries that fly on a 100-row staging copy can time out on 10 million rows — always test with a full-size copy, never a sample.

8 Cloud migration testing checklist 0/8

Write the smoke-test list of critical user journeys before you migrate. Login, signup, checkout, payment, contact forms, file uploads — agreed and written down first, so cutover night is ticking a list, not improvising.
Crawl and diff key pages between old and new environments. Compare HTTP status codes, redirect chains, and page content on the top URLs — a silent 500 on one template or a lost redirect is exactly what a diff catches.
Load-test the new environment to your old peak plus a margin. The new server must prove it handles your busiest hour before it owns production traffic — test to the real peak from your logs, not to a guess.
Verify SSL certificates, HTTPS redirects, and the full chain on the new origin. Check the certificate chain, HTTP→HTTPS redirects, and HSTS behavior directly against the new server before DNS moves — browsers cache SSL failures painfully.
Confirm cron jobs and queue workers actually fire on the new environment. Watch each scheduled job run once for real — the classic post-migration failure is the invoice or backup job that silently never ran again.
Re-verify third-party integrations from the new server's IPs. Payment gateways, SMS providers, and mail APIs often whitelist source IPs or callback URLs — update them and fire a real test webhook from the new environment.
Stand up monitoring and alerting on the new stack before cutover, not after. Uptime checks, resource alerts, and error tracking must be live on day zero — the first 48 hours are exactly when you need them most.
Rehearse the rollback once, for real, and time it. A rollback plan nobody has executed is a wish, not a plan — switch back once in a rehearsal and record how long it actually takes.

9 Application & CDN cutover checklist 0/8

Recreate environment configs and secrets through a secure channel. .env files, API keys, and credentials get re-entered via a password manager or encrypted transfer — never mailed or pasted into chat, and always with rotated values if exposure is possible.
Verify file permissions and ownership after the transfer. rsync between different users silently changes ownership — a wrong www-data/user mismatch shows up as upload failures and broken cache writes hours later.
Move session and cache storage deliberately. File-based sessions do not follow the code; decide whether users get logged out at cutover or sessions move to Redis/database first, and say so in the plan.
Repoint the CDN origin and purge everything after cutover. Update the CDN's origin to the new server, then purge the full cache — otherwise the edge keeps serving the old site (or a mix of both) for hours.
Warm the cache for your top pages after the purge. Hit the most-visited URLs immediately after purging so real users do not pay the cold-cache penalty — protects Core Web Vitals through the transition.
Keep the new origin reachable by the CDN before DNS moves. Firewall rules on the new server must already allow the CDN's IP ranges — a blocked edge node looks like random 522/523 errors for some visitors only.
Verify caching headers behave identically through the CDN. Compare Cache-Control, Vary, and real-visitor-IP restoration on the new origin — a lost header can either kill your hit ratio or cache private pages.
Keep the old server alive and read-only for 7–14 days. It is your fallback and your final audit: one last file/database diff before you cancel it catches anything the migration missed.

⬇️ Download the full checklist (DOCX)

The 5 most common migration failures we get called in to fix

DNS TTL surprises. The cutover happens while the TTL is still 86,400 seconds, so part of your traffic keeps hitting the old server for a full day — and on a store that means orders split across two databases that cannot easily be merged. The fix is simple and free: lower the TTL a day or two before cutover. It is also the item most DIY migrations we review skip.
Forgotten cron jobs. The site works perfectly after the move and everyone celebrates — then a week later it turns out invoices were never sent, backups never ran, and scheduled reports silently stopped. Scheduled jobs never show up in a "click around the site" test; they must be inventoried and moved item by item.
Email breaking. The A records get moved and the rest of the zone gets forgotten: MX, SPF, or DKIM — and suddenly company mail lands in spam or stops entirely. Sometimes nobody notices until a customer asks why you never reply.
Untested backups. Everyone "has backups" right up until the first restore attempt: a corrupt archive, a database dump missing tables, or a backup that has been overwriting itself for months. A backup that has never been restored in a real test is worth nothing.
Nobody owning rollback. A serious problem appears at 2 a.m., nobody knows who decides to go back to the old environment or what the steps are, so the outage runs for hours while the team "fixes forward". A written rollback plan — with a decision point and one named owner — is the difference between a minutes-long incident and a lost night.

DIY vs managed migration — an honest comparison

When DIY makes sense

A small or mostly static site with no purchases or integrations.
Standard WordPress with common plugins only.
You have an in-house sysadmin with real time for the job.
You can tolerate a scheduled downtime window without meaningful loss.

When you need a managed migration

The site directly generates revenue and cannot afford downtime.
Large databases, queues, workers, and scheduled jobs.
Email hosted on the same server.
Compliance or data-residency requirements.
No in-house ops team to watch things after cutover.

DIY saves the service fee but transfers all of the risk to you — every item on this checklist exists because skipping it broke a real migration somewhere. We run managed migrations with a near-zero-downtime approach (initial sync plus delta sync, with TTLs lowered in advance) and a written rollback plan both sides sign off on before cutover night — and we can take over server management and monitoring afterwards if you want us to.

Related resources

Server ManagementMonitoring, security, and day-to-day management of your infrastructure after the move Web HostingManaged hosting with guaranteed performance and security Digital TransformationMove your whole business onto modern digital infrastructure Project Brief GeneratorTurn your project requirements into a shareable document App Cost CalculatorInstant, realistic cost ranges for your mobile app Laravel + Cloudflare Edge CachingHow we cut origin load with edge caching — a practical write-up

Cloud migration FAQs

How long does a cloud migration take?

It depends on size and complexity: a small site moves in hours to a day, a typical business site in 3–7 days including testing, and complex platforms (large databases, queues, integrations) usually need one to three weeks of work.

Is downtime unavoidable during a migration?

No. With TTLs lowered in advance and an initial data sync followed by a small delta sync on cutover night, downtime approaches zero. Occasionally a short read-only window for the database is needed for a few minutes — scheduled at your lowest-traffic time.

What does a managed migration cost?

Indicatively: a small site takes a few hours of work, while complex platforms take one to three weeks. Send your details via the contact page or see our server management service — an exact written quote is free within 24 hours.

Which cloud provider is best?

Honestly: there is no single answer. It depends on your workload, budget, where your users are, and data-residency requirements. We work across AWS, Google Cloud, Hetzner, and OVH, and recommend what fits your case — not what costs the most.

Will my emails break after the move?

Not if the MX, SPF, DKIM, and DMARC records are inventoried and moved precisely before the DNS switch — which is exactly why they get their own item on this checklist. Email only breaks when those records are forgotten.

Do you offer post-migration support?

Yes. We provide ongoing monitoring and management after the migration — updates, tested backups, hardening, and performance follow-up — as part of our server management service.

Can I migrate a database to the cloud with zero downtime?

Very close to zero, yes. The pattern is: bulk-copy the database first, keep it in sync with replication or a delta sync, then take a read-only window of a few minutes at your quietest hour for the final catch-up before switching the application over. The database deep-dive section above covers each step.

How do I test a cloud migration before going live?

Four layers: a written smoke-test list of critical user journeys, a crawl-and-diff of key pages between old and new, a load test to your real traffic peak, and one timed rollback rehearsal. If all four pass, cutover night is boring — which is the goal.

Ready to move to the cloud without surprises?

We run managed migrations with a near-zero-downtime approach and a written rollback plan — and an exact written quote is free within 24 hours.

Request a quotation 📲 WhatsApp us directly Contact Web Pioneer

Get the DOCX + a managed migration quote

Submit your details and the download starts immediately — plus an exact written quote, free within 24 hours.

Or download the DOCX directly here — no sign-up needed.

Web Hosting

Shared Hosting

Windows Servers

Linux Servers