Skip to content
Hosting Operations10 min read

Cloud Migration Step by Step: A Practical Hosting Operations Guide

Plan a safe cloud migration with backups, testing, DNS cutover, rollback steps, and practical checks for hosting teams.

Written by Abdul AbrorTechnical Hosting Support Engineer
Server workloads moving from a traditional hosting environment to a cloud platform
On this page

TL;DR — Key takeaways

  • A safe cloud migration starts with a complete inventory of websites, databases, DNS records, SSL certificates, email routing, cron jobs, and application dependencies.
  • The lowest-risk cloud migration approach is to back up first, test in a staging environment, reduce DNS TTL, migrate data, validate the application, and only then perform cutover.
  • Rollback planning is mandatory for cloud migration because DNS, database sync, file uploads, and application configuration can fail even when the server build looks correct.
  • Cloud migration troubleshooting should focus first on DNS resolution, firewall rules, database connectivity, file permissions, SSL configuration, and application logs.
  • Cloud migration is not only moving files; it is a controlled change to hosting architecture, monitoring, backups, access control, and operational responsibility.

Cloud migration means moving a website, application, database, or workload from one hosting environment to a cloud-based platform. For website owners and support teams, the goal is usually better scalability, easier recovery, improved availability, or more flexible infrastructure management.

This guide treats cloud migration as a hosting operations task, not a marketing trend. It focuses on practical steps, safe testing boundaries, backup and rollback planning, DNS cutover, and troubleshooting checks that junior support engineers and infrastructure teams can use during real migrations.

What Cloud Migration Means in Hosting Operations

In hosting operations, cloud migration is the process of moving a workload from its current environment to a cloud environment while preserving functionality, data integrity, security, and user access. The source may be shared hosting, VPS hosting, a dedicated server, an on-premises server, or another cloud provider.

A cloud migration can be simple, such as moving a static website to object storage and a CDN, or complex, such as moving a database-backed application with background workers, email services, scheduled tasks, file uploads, and external integrations. The more dependencies an application has, the more important planning and validation become.

  • Website migration: moving website files, application code, media, and configuration.
  • Database migration: moving MySQL, PostgreSQL, MariaDB, or another database engine with minimal data loss.
  • Email-related migration: preserving MX records, SPF, DKIM, DMARC, mailboxes, and application mail sending.
  • Infrastructure migration: rebuilding compute, storage, firewall, monitoring, backup, and access controls.
  • DNS cutover: changing records so visitors reach the new cloud environment.

Step 1: Create a Migration Inventory Before Touching Production

The first practical step in any cloud migration is inventory. Do not start by copying files. Start by identifying what exists, what depends on what, and what must continue working after the migration.

For support engineers, the inventory is also the best way to prevent ticket escalation later. Many migration issues happen because a hidden cron job, hard-coded path, custom PHP extension, external API allowlist, or old DNS record was missed during planning.

  • List all domains, subdomains, aliases, redirects, and parked domains.
  • Export current DNS records, including A, AAAA, CNAME, MX, TXT, SRV, and CAA records.
  • Identify the web server stack, runtime versions, database engine, cache layer, and required extensions.
  • Record application paths, environment variables, file permissions, upload directories, and storage mounts.
  • List cron jobs, queue workers, background scripts, webhooks, payment callbacks, and API integrations.
  • Check SSL certificates, renewal method, HSTS usage, and any CDN or proxy settings.
  • Confirm backup location, retention, restore procedure, and who has access.

Step 2: Choose the Right Cloud Migration Strategy

A cloud migration strategy defines how much you change during the move. The safest approach depends on the application, downtime tolerance, team skill level, and business risk. Avoid combining too many changes at once unless the team has tested them carefully.

For many hosting customers, a basic lift-and-shift migration is the most realistic starting point. This means moving the workload to a similar cloud server with minimal application changes. After the site is stable, teams can optimize storage, scaling, caching, and deployment workflows.

  • Rehost: move the workload with minimal code or architecture changes.
  • Replatform: make small improvements, such as changing the database service or storage backend.
  • Refactor: redesign parts of the application for cloud-native services, usually higher effort and higher risk.
  • Replace: move to a managed SaaS product instead of maintaining the application yourself.
  • Retire: remove unused services instead of migrating them.

Step 3: Prepare Backups, Rollback, and Testing Boundaries

Before migrating production data, create a verified backup. A backup is not complete until you know where it is stored, how it can be restored, and whether the restore was tested. For risky operations, keep the original environment intact until the new environment is validated and the rollback window has passed.

Safe testing boundaries are important. Test on a staging copy, a temporary hostname, or a hosts-file override before changing live DNS. Do not test destructive commands, schema changes, or cleanup scripts on production unless there is a reviewed rollback plan.

  • Take a full file backup and a database dump before migration.
  • Store backups outside the source server when possible, so a server failure does not remove both production and backup copies.
  • Document a rollback trigger, such as failed checkout, broken login, missing uploads, or unacceptable error rates.
  • Keep the old server online during cutover when possible.
  • Reduce DNS TTL before migration so DNS changes can propagate faster during cutover.
  • Avoid deleting old hosting data until the business owner confirms the new environment is stable.

Step 4: Build the Cloud Environment and Match Requirements

The new cloud environment should match the application requirements before data is copied. This includes operating system packages, runtime versions, web server configuration, database version compatibility, PHP or Node.js extensions, file upload limits, memory limits, and firewall rules.

Do not assume the cloud default configuration is secure or production-ready. Review SSH access, administrative users, security groups, open ports, backup schedules, monitoring alerts, and log retention before go-live.

  • Install only required services and close unused ports.
  • Use key-based SSH access where possible and restrict administrative access.
  • Apply current operating system and package updates before migration.
  • Configure web server virtual hosts, document roots, HTTPS, redirects, and compression.
  • Create databases and users with least-privilege permissions.
  • Set up backups, monitoring, log rotation, and disk usage alerts.
  • Confirm outbound mail behavior if the application sends transactional email.

Step 5: Migrate Files and Databases Safely

For file migration, preserve ownership, permissions, hidden files, symbolic links, and upload directories. For database migration, use a consistent dump or replication method appropriate for the database size and downtime tolerance.

For small websites, exporting the database and syncing files may be enough. For larger or active applications, plan a staged sync: copy the bulk of the data first, place the site into maintenance mode during final sync, migrate the latest database state, then run validation before DNS cutover.

  • Copy application files, public assets, private storage, and configuration files carefully.
  • Exclude cache directories when safe, but do not exclude user uploads or generated files that the application requires.
  • Import the database into the cloud environment and verify character set, collation, table count, and user permissions.
  • Update environment configuration for the new database host, credentials, storage paths, cache service, and mail settings.
  • Run application migrations only if they are intended for the target release and have a rollback plan.
  • Check file permissions after transfer, especially for upload, cache, session, and log directories.

Step 6: Validate the Application Before DNS Cutover

Validation should happen before public traffic reaches the new cloud environment. Use a temporary hostname, staging URL, or local hosts-file override to test the site as if it were live. This helps catch application issues without affecting all users.

Test both the homepage and the business-critical paths. A migration can look successful from the homepage while login, checkout, contact forms, file uploads, or admin dashboards are broken.

  • Check HTTP status codes, redirects, canonical URLs, and mixed-content warnings.
  • Test login, logout, password reset, forms, checkout, search, uploads, and admin functions.
  • Verify database writes by creating a test record and confirming it persists.
  • Review application logs, web server logs, and database logs for errors.
  • Confirm SSL certificate coverage for the main domain and subdomains.
  • Check robots.txt, sitemap availability, and noindex settings to avoid SEO mistakes.
  • Confirm analytics, monitoring, payment callbacks, and API webhooks if used.

Step 7: Perform DNS Cutover With a Rollback Window

DNS cutover is the point where users begin reaching the new cloud environment. Before changing DNS, confirm that the new server is ready, the old server is still available, backups are safe, and the rollback plan is understood by the responsible team.

If the application accepts user-generated content, comments, orders, bookings, or payments, use a maintenance window or a final sync process to prevent split-brain data, where some writes go to the old server and others go to the new one.

  • Lower DNS TTL in advance when possible.
  • Place the old site in maintenance mode if data consistency requires it.
  • Perform the final database export and file sync.
  • Update A, AAAA, CNAME, or load balancer records as planned.
  • Keep old MX records unchanged unless email migration is part of the approved scope.
  • Monitor traffic, logs, error rates, and user reports after cutover.
  • Rollback by restoring DNS to the previous target if critical issues appear and data consistency allows it.

Troubleshooting Common Cloud Migration Problems

Most cloud migration failures are not mysterious. They usually involve DNS, firewall rules, incorrect credentials, missing dependencies, file permissions, SSL problems, or application configuration values that still point to the old server.

Troubleshoot from the outside in: confirm DNS resolution, confirm the port is reachable, confirm the web server responds, confirm the application can connect to the database, then confirm logs show no fatal errors.

  • DNS still points to the old server: check authoritative DNS, TTL, cached records, and whether the correct zone was edited.
  • Site times out: check firewall rules, cloud security groups, web server status, and whether ports 80 and 443 are open.
  • Database connection fails: verify hostname, port, username, password, database name, bind address, and database user privileges.
  • White screen or 500 error: check application logs, PHP or runtime version, missing extensions, memory limits, and file permissions.
  • SSL error appears: confirm certificate installation, full chain, domain coverage, SNI, and redirect configuration.
  • Uploads fail: check directory ownership, disk space, upload limits, temporary directory permissions, and storage configuration.
  • Emails stop sending: verify SMTP credentials, DNS authentication records, provider restrictions, and application mail settings.

Quick troubleshooting checklist

  • Create a full inventory of domains, DNS records, applications, databases, cron jobs, SSL certificates, and integrations.
  • Choose a migration strategy such as rehost, replatform, refactor, replace, or retire.
  • Create and verify full file and database backups before making production changes.
  • Document rollback steps, rollback triggers, and who approves rollback.
  • Reduce DNS TTL before cutover when operationally possible.
  • Build the cloud environment with required runtimes, services, firewall rules, backups, and monitoring.
  • Copy files while preserving permissions, ownership, hidden files, and required storage directories.
  • Migrate the database using a consistent export, import, or replication method.
  • Update application configuration for the new database, paths, cache, mail, and storage settings.
  • Test the site through a temporary hostname, staging URL, or hosts-file override before DNS cutover.
  • Validate login, forms, checkout, uploads, admin pages, redirects, SSL, logs, and database writes.
  • Perform final sync during a maintenance window if data consistency matters.
  • Update DNS records only after validation is complete and rollback is ready.
  • Monitor logs, uptime, error rates, disk usage, CPU, memory, and user reports after cutover.
  • Keep the old environment and backups available until the new cloud environment is confirmed stable.

FAQ

What is cloud migration?

Cloud migration is the process of moving a website, application, database, or workload from an existing hosting environment to a cloud environment while preserving data, functionality, security, and user access.

What is the safest first step in a cloud migration?

The safest first step in a cloud migration is to create a complete inventory and verified backup before changing production files, databases, DNS records, or server configuration.

How do I reduce downtime during cloud migration?

To reduce downtime during cloud migration, lower DNS TTL in advance, pre-copy files, test the cloud environment before cutover, schedule a final sync during a maintenance window, and keep a rollback plan ready.

Should I move email during the same cloud migration?

Email should only be moved during the same cloud migration if it is included in the approved scope and tested carefully, because MX records, mailboxes, SPF, DKIM, DMARC, and application mail sending can affect business communication.

What should I check if the migrated website shows a 500 error?

If a migrated website shows a 500 error, check the application logs, web server logs, runtime version, missing extensions, file permissions, environment variables, database connection, and memory limits.

Related articles