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

Overview

A cloud hosting migration is more than copying website files from one server to another. It is a controlled change to the environment that serves your pages, runs application code, stores databases, handles certificates, and sometimes manages email or background jobs.

The safest approach is to separate the migration into four phases:

1. Inventory and preparation: document the current site, dependencies, domains, DNS records, scheduled tasks, integrations, and backup process.
2. Build and transfer: configure the new cloud environment, copy files and databases, and match the required runtime settings.
3. Test before cutover: use a staging address or hosts-file override to verify functionality without changing public DNS.
4. Switch and monitor: update DNS, confirm traffic is reaching the new host, and watch availability, errors, performance, search visibility, and data integrity.

Keep the existing hosting account available until the new site has passed its observation period. A rollback is only useful if the old environment remains intact and its data is reasonably current.

For a broader task list, use the cloud hosting migration checklist. If you are still comparing platforms, the guide to website builders versus managed hosting can help clarify which operating model fits the project.

What to track

1. Site inventory and dependencies

Record every component that must work after the move. Include the primary domain, subdomains, aliases, database names, upload directories, environment variables, PHP or other runtime versions, extensions, web server rules, content delivery settings, cron jobs, webhooks, payment integrations, analytics, search tools, and third-party APIs.

Pay particular attention to functions that do not appear on the homepage. Test account registration, login, contact forms, checkout flows, file uploads, search, comments, transactional email, administrative access, and any scheduled imports or exports.

2. Backups and data freshness

Create at least one full backup of the current website and verify that it can be opened or restored. A useful backup normally includes site files, databases, media, configuration, certificates or certificate settings, and a record of DNS values. Keep a dated copy outside the current server where practical.

Before the final transfer, identify how much new data the site receives during the migration window. A brochure site may only need a final file sync. A store, membership site, or publishing platform may require a database export close to cutover, temporary maintenance mode, or a final incremental sync to avoid losing orders, accounts, comments, or form submissions.

3. URLs, redirects, and indexability

Crawl or export the current URL list before changing anything. Compare it with the new site after transfer. Check status codes, canonical URLs, robots directives, XML sitemaps, pagination where relevant, and internal links.

Preserve URL paths whenever possible. If a path must change, create a server-side permanent redirect from the old URL to the closest equivalent new URL. Avoid sending many unrelated pages to the homepage. Keep a redirect map with the old URL, new URL, status, and test result.

4. DNS, SSL, and email

Copy the existing DNS record inventory before making changes. This may include A, AAAA, CNAME, MX, TXT, and verification records. Change only the records required for the website unless you have deliberately planned an email or service migration.

Confirm that the new host serves the correct certificate for every required hostname, including the preferred domain and any active subdomains. Test both HTTP and HTTPS behavior, and verify that HTTP requests redirect to the intended HTTPS URL. For a step-by-step setup reference, see the guide to domain, hosting, DNS, and SSL setup.

5. Technical health and performance

Compare the old and new environments using the same representative pages and actions. Track response time, page loading behavior, server errors, cache behavior, image delivery, database queries where available, and resource use during normal traffic. Do not treat a single speed test as a complete verdict; test the homepage, a content page, a media-heavy page, and an interactive or authenticated workflow.

Cadence and checkpoints

A migration should have explicit checkpoints rather than one large “go-live” decision.

Before the transfer

• Confirm ownership and access for the domain registrar, DNS provider, current host, and new cloud host.
• Record DNS values, application versions, scheduled jobs, integrations, and current URL behavior.
• Take and verify backups.
• Lower DNS record time-to-live in advance only if your DNS provider and migration plan support it; do not assume every resolver will update immediately.
• Define the migration window, responsible operator, validation list, and rollback condition.

During staging

• Import the database and files into the new environment.
• Set production-like environment variables without exposing secrets in public files.
• Check file ownership, permissions, upload limits, rewrite rules, and runtime extensions.
• Test forms, logins, checkout or payment callbacks, emails, scheduled jobs, and integrations.
• Confirm that staging is not unintentionally indexable and that test emails or transactions cannot affect real users.

At cutover

1. Complete the final file and database sync.
2. Pause writes briefly if needed to prevent new data from landing on the old site during the final copy.
3. Update the planned DNS records and note the exact time.
4. Verify DNS resolution from more than one network or checking location.
5. Test the new site directly, including redirects, SSL, key journeys, forms, and administrative access.
6. Keep the previous environment available while DNS changes propagate and monitoring confirms stability.

After cutover

Check the site several times during the first day, then daily during the initial observation period. Record uptime incidents, HTTP status errors, application logs, database errors, resource limits, certificate warnings, email delivery, analytics activity, and search crawling signals. A simple dated change log makes it easier to connect a problem with a configuration change.

How to interpret changes

Not every change after migration indicates a hosting problem. First separate propagation effects from application defects. A few users may still reach the old server while DNS caches update, whereas a consistent error from the new server points to configuration, code, permissions, or database issues.

Use patterns rather than isolated observations:

• 5xx errors: investigate application crashes, unavailable dependencies, database connectivity, runtime limits, and server logs.
• 404 increases: compare requested paths with the redirect map, rewrite rules, and transferred files.
• Slow or inconsistent pages: check cache configuration, database performance, external requests, image handling, and resource saturation.
• Missing form submissions or orders: verify database writes, email services, webhook destinations, and whether some traffic is still reaching the old host.
• Traffic or search changes: check redirects, canonical tags, robots directives, sitemap availability, analytics configuration, and accidental no-index settings before assuming the migration itself caused a ranking change.
• Email disruption: compare MX and mail-related TXT records with the pre-migration inventory. Website DNS changes should not silently remove records used by mail or domain verification.

If the evidence points to the new environment, fix forward when the issue is understood and reversible. Roll back when the site is materially unreliable, data integrity is uncertain, or the cause cannot be isolated within the agreed recovery window. After either decision, document what happened and update the runbook.

When to revisit

Do not treat migration as complete the moment DNS changes. Revisit the checklist after the first day, at the end of the first week, and again during the first monthly or quarterly operations review. The exact schedule should reflect the site’s traffic, transaction volume, and tolerance for interruption.

At each review, compare the current state with the baseline recorded before migration:

• availability and incident count;
• server response and page performance;
• 5xx, 4xx, timeout, and redirect errors;
• database size, storage use, backups, and restore-test results;
• resource usage during busy periods;
• form, order, login, email, and integration success;
• analytics continuity, organic landing pages, and crawl or indexing warnings;
• certificate expiry, DNS records, access permissions, and software versions.

Reopen the migration documentation whenever the domain structure changes, a major application release is deployed, traffic grows materially, the provider changes its infrastructure, a backup restore fails, or recurring errors appear. Remove the old hosting environment only after the retention period agreed by the site owner and after confirming that no active DNS, email, integration, or recovery process depends on it.

For the next action, create a dated migration sheet with three columns: check, result, and owner. Complete it before changing DNS, repeat it immediately after cutover, and schedule the first post-migration review. That small operating habit turns a one-time hosting transfer into a controlled, repeatable process.