Website Migration Checklist: DNS, Email, Files, and Testing
A website migration can mean moving to a new hosting provider, changing server software, restructuring an application, or moving a domain to a new account. The files are only one part of the job. Databases, DNS, email, SSL certificates, scheduled tasks, and external integrations can all be affected.
Build an Inventory
Before moving anything, list the domains and subdomains, application directories, databases, PHP versions, scheduled tasks, email accounts, DNS records, SSL requirements, and external services. Identify which components are actually moving and which will remain with the existing provider.
| Component | Migration question | Validation |
|---|---|---|
| Files | Are all application and upload files included? | Compare file counts or checksums |
| Database | Was a consistent export imported? | Test key records and application queries |
| DNS | Which nameservers are authoritative? | Query records from public resolvers |
| Are mailboxes and routing preserved? | Send and receive test messages | |
| TLS | Are certificates valid on the new endpoint? | Test HTTPS and renewal configuration |
| Scheduled jobs | Were cron entries recreated? | Run and inspect a test job |
Lower DNS TTL in Advance
If you control the DNS zone, lowering the TTL ahead of a planned cutover can reduce how long some resolvers cache the old answer. Do this sufficiently in advance for the previous TTL to expire. It does not guarantee instant global propagation, and it does not remove the need to keep the old service available during transition.
Copy Files and Database
Copy the full application, including hidden files where relevant. Export and import the database using a method appropriate for its size and consistency requirements. Update application configuration for the new database credentials and paths. For WordPress, account for serialized data when changing URLs; use tools that understand serialized values rather than a blind text replacement.
Test Before Changing DNS
Use a hosts-file override, temporary URL, or provider-supported preview method to test the new server before public traffic is switched. Confirm the homepage, administration area, forms, uploads, search, and any revenue-generating workflows. Check PHP errors, rewrite rules, permissions, and HTTPS.
Be careful with test submissions. A copied production site may still connect to real email, payment, or webhook services. Disable or sandbox those integrations until the cutover is ready.
Plan for Email Separately
Website hosting and email hosting are often separate services. If email is not moving, preserve the existing MX and related authentication records. If it is moving, plan mailbox migration, aliases, forwarding, SPF, DKIM, and DMARC. Do not assume that changing website A records should change mail routing.
Cutover and Data Changes
For a mostly static site, a final file sync may be sufficient. For a database-driven site, consider a content freeze or a documented synchronization method so new orders, registrations, or comments are not lost. The correct method depends on how the application handles writes.
Migration-Day Checklist
- Confirm backups and rollback access.
- Verify the new site is tested and ready.
- Synchronize final content and data.
- Confirm DNS records and mail routing.
- Switch the intended records or nameservers.
- Monitor requests, logs, and application workflows.
- Keep the old service available until the new site is stable.
Rollback Planning
Define what conditions trigger rollback and how it will be performed. DNS rollback may not be immediate because resolvers can cache answers. If users can write data to the new site, switching back to the old server without synchronizing that data can create split-brain behavior or data loss.
After the Move
Monitor the new environment for broken links, missing assets, email failures, scheduled-task errors, and unexpected resource use. Confirm backups are running on the new host and that certificate renewal is configured. Update documentation and remove temporary credentials or access rules.
Inventory Every Service Before Moving
A domain may support more than a website. It can also have mailboxes, aliases, forwarding rules, verification records, subdomains, API endpoints, and third-party services. Record the current DNS zone and identify which provider hosts each service. A website migration that preserves the A record but omits MX or TXT records can leave the site online while email or domain authentication fails.
Choose a Data Freeze or Synchronization Strategy
For a mostly static site, a final file and database copy may be sufficient if content changes are paused briefly. For a store, membership site, or busy application, new transactions can arrive during the migration. Decide how those changes will be preserved, whether writes need to be paused, and how the final synchronization will be performed. Never overwrite the new database with an older snapshot after accepting new orders or registrations.
Lower DNS TTL Ahead of the Cutover
If you control the DNS zone, reducing the relevant record’s TTL in advance can shorten the period during which resolvers retain the old answer. It does not eliminate caching, and changing the TTL immediately before a move may not help resolvers that already cached the previous value. Keep the old service available during propagation when practical.
Validate After the Switch
Test the site through the public hostname, not only by visiting the server’s IP address. Check HTTPS, redirects, forms, login, uploads, and any external integrations. Send and receive test email if mail is part of the move. Monitor logs and DNS resolution from more than one network, and keep a documented rollback decision point.
Final Thoughts
A migration is complete only when the services around the website work too. Use an inventory, test before cutover, preserve email deliberately, and keep a realistic rollback plan. For more on the process, review the GaugeHosting guide to moving a website without downtime.