Planning a Domain + Hosting Migration Without Downtime

Migrations Do Not Have to Be Scary

Migrating a website to a new hosting provider — or transferring a domain to a new registrar — is one of those tasks that people postpone indefinitely because the risk feels overwhelming. What if the site goes down? What if email breaks? What if DNS propagation takes forever and half your visitors see the old server while the other half see the new one?

These concerns are valid, but they are all manageable with proper planning. A well-executed migration results in zero or near-zero downtime, intact email delivery, and visitors who never notice the transition. This guide walks you through the entire process: preparation, TTL management, parallel runs, database cutover, verification, and rollback planning.

Phase 1: Preparation (Two Weeks Before)

Inventory Everything

Before touching anything, document your current setup completely:

• DNS records: Export your entire DNS zone. Every A, AAAA, CNAME, MX, TXT, SRV, and CAA record. Missing a single record during migration can break email, subdomains, or certificate validation.
• Server configuration: Document your web server configuration, SSL certificates, firewall rules, cron jobs, and any custom server settings. If you use a control panel, export the configuration if possible.
• Applications and databases: List every application, database, and file directory. Note database versions, application runtime versions, and any dependencies that need to be installed on the new server.
• Email: Document your email setup — provider, MX records, SPF, DKIM, and DMARC records, mailbox accounts, and forwarding rules.
• Third-party integrations: Any service that connects to your hosting via IP whitelist, webhook URL, or API endpoint needs to be updated.

Set Up the New Environment

Provision and configure the new server or hosting account before the migration. Install the same software stack, apply the same configurations, and verify that the environment is ready to receive your applications. This parallel setup phase is where you catch compatibility issues — different PHP versions, missing extensions, database version differences — without any time pressure.

Lower DNS TTL

This is the most important preparatory step. DNS records are cached by resolvers worldwide based on their TTL value. If your TTL is 86400 seconds (24 hours), changing a DNS record means some resolvers will continue serving the old value for up to a day. Lower your TTL to 300 seconds (5 minutes) at least 48 hours before the migration. Wait for the old TTL to expire before proceeding — the TTL you lowered to is not effective until the previous TTL has elapsed.

Phase 2: Data Migration

Files

Copy your website files to the new server. For large sites, use rsync with incremental transfer — it copies only changed files, which makes subsequent syncs fast. Run the initial copy well before the cutover date. Then run a final incremental sync during the migration window to catch any files that changed since the initial copy.

Database

Database migration requires care to avoid data loss:

1. Create a logical dump of your production database using native tools (pg_dump, mysqldump).
2. Import the dump into the new server's database.
3. Verify the import: check table counts, run application-specific validation queries, and verify that the application works against the imported database.
4. During the final cutover, you will either put the old site into read-only mode or accept a brief window of data divergence while you take a final dump and import.

Email Migration

If you are changing email providers, migrate mailbox contents using IMAP synchronization tools. These tools copy the full mailbox — folders, messages, flags — from the old provider to the new one. Run the initial sync in advance, then do a final incremental sync close to the DNS cutover.

Phase 3: The Cutover

Final Data Sync

At the start of your migration window, run a final rsync for files and a final database dump and import. If your application has continuous writes, consider putting the old site into maintenance mode briefly to ensure no data is written during the final sync. This creates a clean cutover point.

Verify on the New Server

Before changing DNS, verify that the site works correctly on the new server. Test by modifying your local hosts file to point your domain to the new server's IP address. Browse the site, test critical functionality (forms, login, checkout, search), verify SSL certificates, and check email sending and receiving.

Update DNS Records

Once the new server is verified, update your DNS records to point to the new server's IP addresses. Because you lowered the TTL in advance, propagation will be fast — most resolvers will pick up the new records within 5-10 minutes. Update A, AAAA, and any other records that reference the old server's IP.

If you are changing nameservers entirely (moving DNS hosting), update the NS records at your registrar. This change may take longer to propagate, so plan accordingly.

Update MX Records (If Applicable)

If your email provider is changing, update MX records at the same time as the other DNS changes. Verify SPF, DKIM, and DMARC records reflect the new email provider's settings.

Phase 4: Verification and Monitoring

Post-Migration Checks

• Verify the site loads correctly from multiple geographic locations using online testing tools.
• Check SSL certificate validity — if you issued a new certificate on the new server, ensure it is properly installed and the chain is complete.
• Test email sending and receiving. Send test messages to external addresses and verify delivery.
• Verify that all DNS records are correct using dig or nslookup from multiple resolvers.
• Check monitoring systems — update any IP-based monitors to point to the new server.
• Verify that backups are running on the new server.

Keep the Old Server Running

Do not decommission the old server immediately. Keep it running for at least 48-72 hours after the DNS cutover. Some resolvers may cache the old records longer than expected, and visitors or email might still reach the old server. Having it running ensures no requests are lost during the transition.

Phase 5: Rollback Plan

Every migration needs a rollback plan. If the new server has problems that cannot be resolved quickly, you need to be able to revert DNS to point back to the old server. Because you kept the old server running and the TTL is low, a rollback is simply updating DNS records back to the old IP addresses. Within minutes, traffic returns to the old server.

Define a rollback trigger: if the new server shows persistent errors, data loss, or performance issues within the first 24 hours, roll back. Fix the issue on the new server in isolation, verify, and try the cutover again.

After the Migration

Once you are confident that the migration is successful and the old server has received no traffic for 48-72 hours:

• Raise DNS TTLs back to normal values (3600-86400 seconds).
• Decommission the old server. Wipe data and cancel the service to avoid ongoing charges.
• Update any third-party integrations, webhooks, or IP whitelists that referenced the old server.
• Document the migration: what you did, what worked, what you would do differently. This documentation is invaluable for future migrations.

Domain Transfers

If you are also transferring your domain to a new registrar, handle this separately from the hosting migration. Domain transfers do not affect DNS or hosting — they only change who manages the domain registration. Transfer the domain after the hosting migration is complete and verified, so you are only changing one thing at a time.

Unlock the domain at the current registrar, obtain the authorization code, initiate the transfer at the new registrar, and confirm the transfer via email. The process typically takes 5-7 days. During this time, your DNS and hosting remain unaffected.

The Bottom Line

A well-planned migration is a non-event for your visitors. Lower TTLs early, set up the new environment in advance, verify before cutting over, keep the old server as a fallback, and monitor aggressively after the switch. The key is planning and patience — rushing a migration is how outages happen. Take your time, follow the process, and your migration will be seamless.