Three years ago, a client called us at 11 PM on a Tuesday. Their hosting provider had gone down - not a blip, a full outage. Their e-commerce store was dead during a flash sale they'd spent two weeks promoting. By the time the host came back online, they'd lost an estimated 8,000 EUR in sales and about 400 potential customers who would never return. The next morning, they asked us to move them. Within 72 hours, their site was running on our infrastructure. Downtime during the migration? Zero seconds.
We've migrated over 500 websites in the past decade. The average downtime across all of them: zero. Not "nearly zero." Not "a few seconds." Actual zero, because we've built a process that makes the old site and new site run simultaneously until we're absolutely certain the new environment is perfect.
Here's exactly how we do it.
Pre-Migration Audit: Know What You're Moving
The number one reason migrations fail is surprises. A forgotten cron job. An email account nobody mentioned. A hardcoded path buried in a plugin. We eliminate surprises with a comprehensive pre-migration audit.
The Audit Checklist
Before we touch a single file, we document everything:
- Files and directories: Full inventory, total size, file permissions, symlinks. A WordPress site might be 2 GB. A legacy application with 10 years of uploaded documents might be 85 GB. The approach changes dramatically based on volume.
- Databases: Number of databases, sizes, engines (InnoDB vs. MyISAM still matters during migration), character sets. We check for database users and their specific privileges - a common miss that breaks things post-migration.
- Email accounts: Every mailbox, every forwarder, every alias. If the old host handles email, we need to know before we change DNS, or people stop receiving mail. This trips up more migrations than any other single issue.
- Cron jobs: Scheduled tasks that run backups, send reports, clean temp files, process queues. Miss one and something silently breaks three weeks later when nobody connects it to the migration.
- SSL certificates: Type, issuer, expiration date, and whether they're host-specific (like cPanel AutoSSL) or portable (like a purchased wildcard). Let's Encrypt certificates need to be re-issued on the new server.
- Server configuration: PHP version, loaded extensions, custom php.ini settings, .htaccess rules, Apache vs. Nginx vs. LiteSpeed specifics. A site running on PHP 7.4 with ionCube loader is a very different migration than a modern PHP 8.2 Laravel app.
- Third-party integrations: Payment gateways with IP whitelists, API endpoints that reference the server directly, CDN configurations, external monitoring tools.
This audit typically takes two to four hours depending on complexity. It's the most important two to four hours of the entire migration.
Parallel Environment Setup
Once we know exactly what we're migrating, we build an identical environment on the destination server. Identical PHP version, identical extensions, identical configurations. We don't guess - we match.
For hosting migrations to our infrastructure, we provision the account with:
- Matching PHP version and extensions
- Database server with matching character sets
- Email accounts pre-created (but not active yet - that comes later)
- SSL certificate ready to deploy
- Cron jobs configured but disabled
The key principle: the new environment must be a mirror of the old one before any data moves.
Data Synchronization: The First Pass
Here's where the actual migration begins, and here's why there's no downtime - we do the heavy lifting while the old site is still live and serving visitors.
Files
For file transfer, we use rsync over SSH whenever possible. Rsync is intelligent - it only transfers changed files, it can resume interrupted transfers, and it preserves permissions and timestamps.
A typical first sync of a 10 GB site over a decent connection takes 20-40 minutes. But that first sync happens while the old site is still running. Nobody notices. Nothing changes for visitors.
Database
For the initial database copy, we use mysqldump with the --single-transaction flag for InnoDB tables. This creates a consistent snapshot without locking the database - meaning the live site keeps working normally during the dump.
For large databases (we've migrated databases up to 45 GB), we use parallel dump tools and compress the transfer. A 5 GB database typically takes under 10 minutes to dump, transfer, and import.
Again - all of this happens while the old site is live. Visitors are completely unaware.
DNS TTL Reduction: The Quiet Preparation
Here's a step that separates professional migrations from amateur ones. Three to five days before the migration, we reduce the DNS TTL (Time to Live) for all relevant records.
Default TTL values are often 86,400 seconds - 24 hours. That means after a DNS change, some visitors could be directed to the old server for up to a full day. That's not zero downtime; that's a mess.
We drop the TTL to 300 seconds (5 minutes) several days in advance. This ensures that when we make the final DNS switch, the entire internet points to the new server within minutes, not hours.
It's a small detail. It makes an enormous difference.
Testing on Temporary URL
Before any DNS changes, we test the site thoroughly on the new server using a temporary URL or hosts file modification. This step is non-negotiable.
What We Test
- Every page loads: Not just the homepage. We crawl the entire site using Screaming Frog or a custom script, checking for 404s, 500s, broken images, and missing assets.
- Forms work: Contact forms, search, login, shopping cart, checkout. Every interactive element.
- Database connections: Dynamic content loads correctly, queries return expected results.
- Email sending: We trigger test emails to verify SMTP configuration on the new server.
- SSL works: HTTPS loads without mixed content warnings. Certificate chain is complete.
- Performance: Page load times on the new server should be equal to or better than the old one. We run GTmetrix and Lighthouse tests to verify.
- Cron jobs execute: We manually trigger each scheduled task and verify it completes successfully.
If anything fails, we fix it before proceeding. The old site is still live. There's no pressure, no rushing, no "we'll fix it after the switch." We've had migrations where testing revealed plugin incompatibilities that took two days to resolve. That's fine. The old site kept running the entire time.
The Final Sync and Switch
Once testing passes, we do the final data synchronization. This is the only part where timing matters, and it's fast.
The Sequence
- Final rsync: Since most files were already synced in the first pass, this incremental sync typically takes under 60 seconds. Only changed files transfer.
- Database lock and dump: We briefly lock the database on the old server (preventing writes), dump the delta, and import it on the new server. For most sites, this takes 5-15 seconds. The old site is still serving cached pages during this window.
- DNS update: We change the A record (and AAAA for IPv6) to point to the new server's IP. With the pre-reduced TTL, propagation begins within minutes.
- MX record update: If email is moving too, we update MX records simultaneously.
- Monitoring begins: We watch access logs on both servers in real time. Traffic gradually shifts from old to new. Within 15 minutes, the majority of visitors hit the new server.
During the DNS propagation window, both servers have identical, current data. A visitor hitting the old server sees the correct site. A visitor hitting the new server sees the correct site. Zero downtime.
Post-Migration Verification
The migration isn't done when DNS changes. It's done when we've confirmed everything works in production.
The 48-Hour Watch
For the first 48 hours after migration, we:
- Monitor error logs on the new server every few hours
- Verify all cron jobs have executed on schedule
- Check email delivery and receiving
- Monitor traffic patterns for anomalies
- Keep the old server running as a fallback (we maintain it for at least a week)
Only after 48 hours of clean operation do we consider the migration complete.
Common Gotchas We've Learned the Hard Way
Twenty years of migrations have taught us where things go wrong:
Hardcoded URLs
Database entries and configuration files that reference the old server's IP address or a server-specific path. WordPress is notorious for storing full URLs in serialized data. We use WP-CLI's search-replace command with serialization awareness to catch these.
Email MX Records
The most common post-migration complaint: "I stopped getting emails." If the old host handled email and the new one doesn't (or uses a different mail server), you need to update MX records at the same time as A records. We've seen businesses lose a full day of email because someone forgot this step. We never do.
SSL Certificate Timing
If you switch DNS before the new server has a valid SSL certificate, visitors see a security warning. We pre-issue certificates using DNS validation or have them ready before the switch.
.htaccess vs. Nginx
Moving from Apache to Nginx (or to LiteSpeed, which we use)? Your .htaccess rewrite rules don't transfer automatically. They need to be converted. We've seen migrations where the site "worked" but every SEO redirect was broken - hundreds of 404 errors that tanked search rankings within a week.
Time Zone Differences
Cron jobs scheduled in UTC on the old server running at a different offset on the new one. Small detail, but a backup job that was supposed to run at 3 AM running at 3 PM instead can cause performance issues during peak hours.
Why We Offer Free Migration
Every hosting plan we offer includes free website migration. Not a coupon. Not "free for the first site." Free, period.
We do this because we know migration anxiety is the single biggest reason people stay with bad hosts. They know their current hosting is slow, unreliable, or overpriced - but the fear of breaking something keeps them stuck. We remove that barrier entirely.
Our team handles the entire process. You don't need to provide cPanel access at a specific time, you don't need to schedule downtime, and you don't need to worry about your visitors or customers experiencing an interruption.
Five hundred migrations and counting. Zero seconds of average downtime. That's not a marketing number - it's a process built on two decades of doing this work and learning from every edge case along the way.