How to Migrate a Website to Cloud Hosting Without Losing Traffic or Email

Overview

A hosting migration changes where your website files and application run. It does not necessarily change your domain, but the domain's DNS records must eventually point visitors to the new environment. Email may use some of the same DNS infrastructure, so changing records without documenting them can interrupt mail delivery even when the website itself works.

The safest approach is to separate the migration into preparation, testing, DNS cutover, and verification. Keep the existing hosting account active until the new site and its email services have been checked. The exact control-panel labels vary between providers, but the underlying tasks remain similar.

Before choosing a destination, record the current setup. Note the domain registrar, DNS provider, nameservers, A and AAAA records, CNAME records, MX records, TXT records, subdomains, cron jobs, PHP or runtime version, database version, SSL arrangement, and any external services connected to the site. A cloud hosting plan comparison can help structure this review.

Checklist by scenario

1. Before moving the website

• Confirm ownership and access for the domain registrar, DNS provider, current host, new host, CMS administrator, database, analytics, and transactional email service.
• Export the DNS zone or copy every record into a migration worksheet. Include records for the root domain, www, staging subdomains, mail, verification services, and third-party applications.
• Create a full backup of website files, databases, uploaded media, configuration files, and application-generated data. Store at least one copy outside the current hosting account and test that the archive can be opened or restored.
• Record the current website's important URLs, redirects, canonical settings, robots directives, XML sitemap location, forms, and integrations.
• Review the destination's supported runtime, database engine, extensions, storage paths, scheduled-task system, outbound mail options, and access method.
• Lower the DNS TTL for records you expect to change, if your DNS provider permits it. Do this in advance rather than immediately before the cutover, and record the original TTL so it can be restored later.

2. Build and test the new environment

• Provision the new hosting account, application, database, users, permissions, and environment variables.
• Transfer the files using the provider's migration tool, secure file transfer, version control, or another documented method. Avoid copying temporary caches, logs, and unnecessary backup archives unless the application requires them.
• Import the database and update the application configuration with the new database name, user, password, host, and port where necessary.
• Use a temporary hostname, hosts-file entry, password-protected staging URL, or provider preview address to test the site before changing public DNS.
• Install an SSL certificate for the production domain and confirm that HTTP redirects to HTTPS. Review the provider's renewal process rather than assuming certificates are managed automatically.
• Test login, checkout or enquiry forms, file uploads, search, contact notifications, administrator functions, scheduled tasks, images, CSS, JavaScript, and any external API connections.
• Check that the new site generates the intended canonical URLs, robots.txt file, XML sitemap, and redirect responses. Use the technical SEO and hosting checklist for a broader deployment review.

3. Prepare the DNS and email cutover

• Compare the new provider's required A, AAAA, or CNAME records with the existing zone. Do not replace the entire DNS zone unless you have copied records that must remain.
• Preserve MX records if email will stay with the existing mail provider. Also preserve relevant SPF, DKIM, and DMARC records, as well as verification records used by other services.
• If email is moving too, create mailboxes, aliases, forwarding rules, autoresponders, and user accounts at the destination before changing MX records.
• Plan mailbox migration separately from website file migration. Export or synchronize messages using the tools supported by the mail providers, and tell users when new mail may be delivered to the new system.
• Document the intended final records. For example, an A record may point the root domain to the new web server, while a CNAME may point www to the hosting platform. Use the destination provider's exact values rather than examples from another service.

4. Cut over and verify

• Take a final database backup immediately before the change. If the site receives orders, registrations, comments, or form submissions, identify how to capture changes made during the final transfer.
• Put the site into maintenance or read-only mode only when needed. A short freeze can prevent new database records from being written to the old server during the final sync.
• Update only the necessary DNS records, then note the time and exact changes. Avoid changing nameservers and individual records at the same time unless you have planned and tested that approach.
• Test the website through the root domain and www hostname, on HTTP and HTTPS, from more than one network or DNS resolver.
• Send and receive test messages from multiple mailboxes. Check inbound delivery, outbound delivery, aliases, forwarding, attachments, and spam handling where applicable.
• Monitor server errors, application logs, uptime, analytics, search-console data, forms, and key conversion paths. Keep the old hosting service available until the agreed validation period has passed.

What to double-check

DNS scope: Website records are only part of a DNS zone. A migration can break email, domain verification, remote access, or subdomains if unrelated records are omitted. If nameservers are changing, compare the complete old and new zones before delegating the domain.

Redirects and URL consistency: Preserve existing paths whenever possible. If URLs must change, create one-to-one permanent redirects from each old URL to its closest relevant destination. Avoid sending every old page to the homepage. Check redirect chains, trailing-slash behavior, uppercase and lowercase paths, and HTTP-to-HTTPS handling.

SSL and application URLs: Confirm that the certificate covers every hostname visitors use. Update hard-coded HTTP asset URLs, callback URLs, webhook endpoints, and CMS settings. Mixed content or an incorrect site URL can make a migration appear broken even when DNS is correct. See the SSL and HTTPS troubleshooting guide for a focused review.

Email authentication: SPF, DKIM, and DMARC records may be controlled by different systems. Copying an SPF record without checking its permitted senders can create delivery problems. Generate or confirm DKIM keys through the active mail provider, and change DNS only according to that provider's instructions.

Backups and rollback: A rollback is more than pointing DNS back. Define which DNS records will be restored, how database changes will be reconciled, how mail will be handled, and who can make the change. Keep a dated copy of the pre-migration configuration and a tested restore archive. The website backup and disaster recovery checklist provides a useful companion review.

Common mistakes

• Changing nameservers without copying mail, verification, and subdomain records.
• Deleting the old hosting account immediately after DNS changes, before caches and secondary resolvers have updated.
• Testing only the homepage while missing forms, logins, uploads, checkout steps, scheduled jobs, or API integrations.
• Forgetting that a database may continue receiving changes during the final file transfer.
• Moving the website but leaving email accounts, aliases, or MX records undocumented.
• Using a staging URL that search engines or the public can access without appropriate controls.
• Assuming the new host's backup, SSL, caching, or email features work exactly like the old provider's features.
• Changing URLs during the hosting move without an inventory of redirects and internal links.

For a domain and hosting move, keep the DNS worksheet, backup locations, test results, change timestamps, and rollback steps together. That record is often more valuable than relying on memory when an issue appears after cutover.

When to revisit

Reuse this checklist before every hosting migration, domain change, nameserver update, major platform upgrade, or email-provider move. Revisit it before seasonal planning cycles when traffic, campaigns, or staffing may change, and whenever a hosting control panel, DNS provider, mail workflow, or application runtime changes.

After launch, perform a post-migration review at a defined interval rather than stopping when the homepage loads. Confirm that traffic patterns, indexed URLs, redirects, uptime, page speed, forms, analytics, backups, and email remain healthy. If an incident occurs, use the uptime monitoring and incident response runbook to document the investigation.

Final action: create a dated migration worksheet today. List every DNS record, mailbox, application dependency, backup, test URL, and rollback owner. Do not switch production DNS until the new site has passed the worksheet's checks and you can explain how to restore the previous state.