Migrating Hosts With Zero Downtime — A Step-by-Step Plan

Most downtime during a hosting migration has nothing to do with the actual move. Files copy, databases transfer and email accounts sync without issue. The outage happens when DNS propagates before the new server is ready, or when old DNS records linger after the cutover. Here is the step-by-step plan to migrate hosts with zero measurable downtime.

Pre-migration preparation

Before you touch a single file, document everything about your current setup. You need a complete inventory: every domain and subdomain, every email mailbox and alias, every database, every cron job and every SSL certificate, including expiry dates.

Check with your new host whether they offer free migration assistance. Most reputable providers, including Almada, migrate your site at no charge. If you are doing it yourself, confirm that the new host supports the same software versions — PHP, MySQL, Python or Node — that your site requires.

Take a full backup of files, databases and email. Store it locally and on a third location such as cloud storage. A backup is your safety net: if the migration goes wrong, you restore the old server and no one notices.

TTL lowering — the critical step

The single most important step in a zero-downtime migration happens before the move. Lower the Time To Live (TTL) on your DNS records to 300 seconds (five minutes) at least 48 hours before cutover.

TTL tells DNS resolvers around the world how long to cache your records. A typical TTL is 3600 seconds (one hour) or 86400 seconds (one day). During a migration, those caches point to the old server. After you update the DNS to the new IP, visitors whose resolver still holds the cached old record will hit the old server, which is now empty or offline.

Lowering TTL to 300 seconds means that after you flip the DNS record, the change propagates globally within minutes instead of hours. Do this early: many DNS providers cache the TTL itself, so a change made on the day of migration may not take effect until the old TTL expires.

Setting up on the new host

While the old site is still live, configure the new hosting environment. Create the same directory structure, install the same software versions, upload your SSL certificate and set up email mailboxes with the same names and passwords.

Copy your files and databases to the new server. Use rsync or SCP for files and mysqldump for MySQL databases. Do not point the domain yet — you can access the new server via its temporary URL or IP address.

Test everything on the temporary URL. Click through every page, submit a form, send and receive an email. Check that SSL works on the new server. Fix any issues while the old site is still running. This is the only time you can compare the two side by side.

Data copy methods

The method you use to copy data determines how long the cutover window takes. A naive FTP upload of 10 GB could take hours, during which users may see incomplete content.

For files, rsync is the best option. The initial transfer copies everything. Subsequent rsync runs copy only the changes since the last run. On cutover day, a final rsync takes seconds or minutes regardless of total site size.

For databases, use mysqldump to export and mysql to import. If your database is large (over 1 GB), consider replicating the database from the old server to the new one ahead of time, then redirecting application traffic on cutover day. For smaller sites, a single dump and import during the maintenance window is sufficient.

Email migration depends on the protocol. If you use IMAP, tools like imapsync can copy mailboxes between servers while preserving folder structure. If you use POP3, email is stored locally and migration is more complex. Consider a short overlap period where both servers accept mail.

DNS cutover

With the new server fully configured and the old one still running, change your DNS A record (and www CNAME) to point to the new IP address. Because you lowered the TTL to 300 seconds, the change propagates within five minutes globally.

Do not delete the old hosting account yet. Keep it running for at least 48 hours. Visitors who resolve to the old IP due to cached DNS will still see the live site. Any emails sent to the old server during propagation will still be delivered.

Monitor your site from multiple locations using a tool like Pingdom or UptimeRobot. If you see errors from some locations, wait for DNS to finish propagating. If the new server has issues, you can flip the DNS back to the old IP in minutes — again, thanks to the low TTL.

Testing and rollback plan

After cutover, run a full test suite. Check that every page loads, every form submits, every image displays and every email address sends and receives mail. Verify that SSL certificates are valid and that cron jobs run on schedule.

Create a rollback plan before you start. It should list the exact steps to revert: point DNS back to the old IP, confirm that the old server still has the latest data, and notify the team. A rollback should be a calm, practiced procedure, not a panic.

Keep the old hosting account for at least a week after the migration. Transfer the domain registrar lock only after you are confident the new host performs as expected. Then and only then cancel the old account.