Hosting migration: what should your transition plan cover?

Inventory before copying

List domains, websites, databases, mailboxes, scheduled tasks and external connections. Hosting may contain a subdomain or old form that is absent from the main menu but still in use. Do not leave DNS zone and email configuration backups until the last minute.

Assign an owner and a test to each item. For a contact form, browser submission and email delivery are separate checks. Handle access through secure channels. Do not copy passwords into migration documents; record where access is managed and who is authorized.

Test the new environment separately

Copy files and the database, then check the runtime: versions, extensions, write permissions and background tasks. Test the website at a temporary address or using local name resolution while live visitors still use the old system. Check the SSL certificate and redirects.

Do not count it as success just because the homepage appears. Open internal pages, images, downloads and administration too. Test uploads and email. A file transfer error may remain hidden until someone requests a rarely used document.

DNS and email: two separate changes

A website’s address and email routing are different settings. When changing website records, check MX and related TXT records separately. If email stays with the old provider, preserve the necessary records in the new DNS zone too.

TTL affects caches according to previously stored responses; lowering it does not immediately clear them. During a transition, different visitors may reach different servers. Test email both to and from an external mailbox.

What happens to new data?

A brief editing pause may suffice for a brochure website. In an online store or customer system, new orders and users may have appeared since the initial copy. Define the final data transfer time, maintenance window and how to avoid simultaneous writes.

For example, do not launch the new store with yesterday’s database without reconciling orders received since then. Acceptable data loss is a business decision. Document who can stop the process and when to return to the old system.

Post-migration checks and search visibility

If only hosting changes, preserve existing URLs. Domain or path changes require a URL map and appropriate redirects. Check canonicals, internal links, the sitemap and whether the test environment’s noindex setting was accidentally retained in production.

Close the old environment only after reconciling data and completing the monitoring period. Check error logs, traffic, forms and email. A migration completion report can be brief: what was tested, which data was transferred, where backups are stored and whether anything remains outstanding.

Example: the website moves, but email disappears

A common misconception is that a website opening successfully proves the whole domain migration worked. If the new name servers contain only website records, email routing may be missing. Incoming messages may no longer reach the usual mailbox. First compare the old and new zones, then check the records specified by the email provider.

Back up the current state before making repairs. Hastily restoring a whole DNS zone can send a working website back to the old hosting. Record website and email tests separately, and have everyone responsible use the same migration notes.

When is migration complete?

Completion requires successful functionality tests, data reconciliation and a known backup state. Check that the same scheduled task is not running on both servers: for example, two systems must not send reminders or billing requests simultaneously. You can then close access to the old environment and stop paying for resources no longer needed.

Monitor search traffic and broken URLs after migration too. Not every change indicates a migration fault, so investigate specific URLs and timestamps. Do not choose when to shut down the old site using a generic number of days; consider traffic, caches, email and rollback requirements.

• Inventory: website, database, mailboxes and background tasks.
• Testing: internal pages, files, HTTPS, and sending and receiving email.
• Recovery: acceptable data loss, an owner and a working backup.