Migrating by FTP drag-and-drop
FTP copies lose permissions, symlinks, hidden files, and anything open at copy time — and it silently truncates on flaky connections. rsync with checksums exists for a reason.
ranjan@ranjan.info:~$ man services/website-migration
Zero Downtime Website Migration
Move hosts without your visitors ever noticing
A migration fails at the seams: the mailbox nobody remembered, the cron job on the old box, DNS TTLs that weren't lowered. After 1,200+ of these, the process is boringly reliable — full sync, staged verification, low-TTL cutover, and a rollback path that means the old server stays untouched until the new one is proven.
What is a zero-downtime website migration?
A zero-downtime website migration moves a site — files, databases, email, DNS — to a new server while the old one keeps serving visitors until the new one is proven. The sequence: full data sync, verification on the new host, DNS TTLs lowered days in advance, then a cutover measured in seconds with the old server held as instant rollback. Done this way, visitors never see an outage and nothing in transit is lost.
Written by Ranjan Chatterjee, Infrastructure Consultant · Linux Server Specialist · 15+ years in production Linux · Last reviewed
ranjan@ranjan.info:~$ dmesg | tail
Signs you need this now
Migrations get postponed until the pain outgrows the fear. These are the signs the move is already overdue.
- Your site got slower and support got worse after the host's latest "upgrade"
- Renewal pricing has doubled since you signed up
- You've outgrown the plan and the next tier doesn't add up
- Your control panel or OS version is approaching end of life
- The provider keeps having outages — and you keep explaining them to customers
- You need a different region, compliance posture, or provider ecosystem
- You want off a proprietary platform that makes leaving deliberately hard
- A previous migration attempt failed and everyone's scared to retry
ranjan@ranjan.info:~$ cat scope.txt
What this covers
- Shared hosting, VPS, dedicated, and cloud-to-cloud migrations
- cPanel, DirectAdmin, Plesk, and CyberPanel — same-panel or cross-panel
- Apache, Nginx, and LiteSpeed stack transitions
- Email migration with mailbox integrity verification
- Database migration with checksum verification
- DNS cutover planning: TTL staging and rollback windows
- SSL certificate migration and reissue
- Cron jobs, scripts, and the invisible dependencies nobody documents
ranjan@ranjan.info:~$ man first-aid
How to prepare for a clean migration
Whether I run the move or you do, these five steps decide how smooth cutover day is.
-
1
Inventory everything, not just the website
Cron jobs, mailboxes, forwarders, subdomains, API webhooks, license keys tied to IPs — migrations fail at the pieces nobody listed. Write it all down before anything moves.
-
2
Lower DNS TTLs now
Drop your records to 300 seconds at least a day before cutover. It costs nothing and turns "propagation might take 24 hours" into a switch that completes in minutes.
-
3
Test-restore a backup
Before trusting any migration, prove your safety net: restore one site's backup somewhere and confirm it actually works. Migration day is the wrong time to learn the backups were broken.
-
4
Freeze major changes near cutover
A plugin update or schema change mid-sync creates drift between old and new servers. Hold non-urgent changes for the final sync window.
-
5
Map credentials and third-party dependencies
Payment gateways pinned to an IP, SMTP relays, license activations, firewall allowlists at partners — list what has to be updated the moment the new server goes live.
ranjan@ranjan.info:~$ grep -i "oops" ~/incidents.log
Mistakes that turn migrations into outages
Every one of these comes from a real engagement — usually from before I was called.
Cutting DNS with a day-old TTL
Switching DNS while records still carry a 24-hour TTL splits your traffic between two servers for a day — orders landing in one database, mail in another. TTLs come down before cutover, not during.
Forgetting the mail
The website moves, MX records get overlooked, and mail keeps arriving at a server someone is about to cancel. Email deserves its own checklist in every migration plan.
Cancelling the old server on cutover day
The old server is your rollback and your audit trail. Keep it running (even stopped-but-preserved) for at least a week after cutover — the money saved by cancelling early has destroyed businesses.
Skipping the hosts-file preview
Pointing your own machine at the new server via /etc/hosts lets you test every site fully before DNS moves. Cutting over to an unverified server is the leading cause of "the migration broke my site".
ranjan@ranjan.info:~$ diff --options
DIY, provider support, or a specialist?
An honest comparison — each option is right in some situations, including the free ones.
| Option | The right choice when… | Limits & risks |
|---|---|---|
| Host's free migration | Simple sites moving into a mainstream panel host — many do a fine job with standard cPanel accounts and it costs nothing. | Best-effort and queue-based: no cutover planning, DNS is your problem, email often "transfers" as empty mailboxes, and nobody verifies the result. Fine for a blog; risky for a business. |
| DIY with plugins/scripts | A single WordPress site, a comfortable admin, and tolerance for a rollback-and-retry if something breaks. | Plugin migrations time out on large sites, skip cron/mail/DNS entirely, and the one-click restore is unverified until you need it. Total time cost is usually underestimated 3–5×. |
| Independent specialist | Revenue is on the line, many accounts or mailboxes, cross-panel or cross-cloud moves, or a hard cutover deadline. You want verification, a rollback plan, and one accountable engineer. | Costs real money and needs access to both environments. A fixed quote up front removes the meter-running risk — but a specialist can't fix a broken destination host; choosing the target is still a shared decision. |
What you get
- Every site, mailbox, and database on the new server — verified, not assumed
- A cutover executed at the hour you choose, with the old server held as instant rollback
- A migration map documenting what moved where, and post-cutover monitoring
Why work with me on this
- 15+ years inside production Linux — this exact work, done at fleet scale
- Founder-operator of two hosting platforms: I've owned the uptime, not just the ticket
- Every change documented and reversible — you keep a written trail, not a mystery
- Plain-language updates and honest timelines you can plan a business around
ranjan@ranjan.info:~$ ./engage --how
How it runs
The same disciplined path on every engagement — scoped, planned, executed with checkpoints, handed off clean.
-
01
Scope
A short brief or call to understand your stack, the real problem, and what a good outcome looks like.
-
02
Plan
A clear architecture plan — steps, risks, rollback and timeline — agreed before anything touches production.
-
03
Execute
Hands-on work with checkpoints. You see progress; nothing changes on your servers silently.
-
04
Handoff
Documentation, access cleanup and a clear path for what comes next. No lock-in, no mystery.
ranjan@ranjan.info:~$ faq --service website-migration
Common questions
Is "zero downtime" actually zero?
For visitors, yes — the site serves from the old server until DNS switches to a new server that's already live and verified. The only theoretical gap is DNS propagation, which staged low TTLs reduce to seconds.
How long does a website migration take?
A single site typically completes within a day, including verification. Full servers with hundreds of accounts run about a week: initial sync, account-by-account verification, then a scheduled overnight cutover. The calendar time is mostly careful verification — the actual downtime is the part that stays at zero.
How much does a migration cost?
A fixed quote based on account count and stack complexity — agreed before anything moves, so there's no incentive to let it drag. Simple single-site moves are inexpensive; large multi-account or cross-panel projects are quoted per scope. If your host's free migration would honestly serve you fine, I'll tell you.
Will migrating affect my SEO rankings?
Not if it's done properly. Search engines don't penalize a change of hosting — what hurts SEO is downtime, broken URLs, lost HTTPS, or missing redirects during a sloppy move. A verified cutover preserves URLs, SSL, and response codes, so crawlers see the same site answering faster.
Can you migrate between different control panels?
Yes — cPanel to DirectAdmin and similar cross-panel moves are routine. Accounts, mail, databases, and DNS zones are converted and verified rather than dumped and hoped for.
What happens to email mid-migration?
Mailboxes sync continuously until cutover, so mail keeps arriving on the old server and re-syncs before DNS moves. No mailbox goes read-only and nothing in transit is lost.
What about my SSL certificates?
Certificates are migrated or reissued on the new server before cutover, so HTTPS never breaks. Let's Encrypt certificates are reissued automatically; purchased certificates move with their private keys, or get replaced if the new stack manages them differently.
Can you move very large sites — hundreds of gigabytes?
Yes. Size changes the method, not the outcome: initial syncs run in the background over days if needed, and the final delta pass still completes in minutes because only changes move. The practical constraints are the source host's transfer limits — which is a solvable planning problem, not a blocker.
Can you migrate away from managed WordPress hosts?
Yes, including the ones that make export deliberately awkward. Site files and the database always have an extraction path, and the move includes rebuilding the pieces those platforms handle invisibly — caching, CDN, redirects — so performance doesn't regress on the new stack.
Do you do cutover at night or on weekends?
Cutover happens at the hour you choose — usually your lowest-traffic window, which for most businesses means late night or weekend. The heavy work is done in advance precisely so the cutover itself is a short, boring, scheduled event.
ranjan@ranjan.info:~$ man glossary
Terms you'll hear during a migration
Plain-language definitions — so the report reads like information, not incantation.
- TTL
- Time-to-live on a DNS record — how long the internet caches it. Low TTL = fast cutover; forgotten high TTL = a day of split traffic.
- Cutover
- The planned moment traffic switches to the new server, typically a DNS change executed after everything is verified.
- Propagation
- The period during which DNS caches worldwide pick up your change. Managed properly with low TTLs, it's minutes, not days.
- rsync
- The transfer tool of choice: checksums, permissions, resume, and delta-sync — only what changed moves on the final pass.
- imapsync
- Mailbox-level migration tool that copies mail continuously and verifiably between servers until the moment MX records move.
- Hosts-file preview
- Editing your own computer's hosts file to see the site from the new server before DNS changes — full verification with zero public impact.
- Rollback window
- The agreed period the old server stays intact after cutover, so any surprise has a one-step undo.
- Delta sync
- The final quick pass that copies only what changed since the full sync — the trick that makes near-zero-downtime possible.
ranjan@ranjan.info:~$ ls ../related
Related services
Engagements that commonly pair with this one.
Email Migration & Recovery
Workspace, Microsoft 365, cPanel, IMAP — synced, verified, and deliverable.
View serviceHosting Control Panel Services
Migration, repair, optimization, and WHMCS automation for panel-based infrastructure.
View serviceServer & Website Performance Optimization
Web server, PHP, MySQL, cache layers — tuned from measurements, not folklore.
View serviceranjan@ranjan.info:~$ ssh [email protected]
Ready when you are
One paragraph is enough: your stack, the symptom, and when you need it solved. Emergencies are answered first.