The Complete Migration Playbook: Move a Live Site from Shared Hosting to Managed Cloud or VPS (Checklist + Step‑by‑Step Workflow)

Overview

A hosting migration usually involves more than copying website files. You may need to move a database, recreate email and DNS settings, match software versions, issue SSL certificates, preserve scheduled tasks, and confirm that every application integration still works. The safest approach is to separate the migration into four controlled stages: inventory, preparation, testing, and cutover.

Before choosing a target plan, document your current environment. Record the operating system, PHP or other runtime version, database engine and version, web server, enabled extensions, cron jobs, storage usage, traffic patterns, outbound email settings, and any external services connected to the site. For WordPress, also list active plugins, the theme, custom code, cache configuration, and integrations such as payment gateways or forms.

Managed cloud hosting can reduce the amount of server administration you handle, while VPS hosting generally provides more control over the operating system and configuration. The right choice depends on your technical requirements, maintenance capacity, resource needs, and tolerance for managing updates and security. For background, compare the characteristics of cloud hosting, VPS hosting, and shared hosting before selecting the destination.

Migration approaches

Regardless of method, keep the original hosting account active until the new site has passed testing and the DNS change has fully propagated. Do not treat a successful file copy as a completed migration.

Checklist by scenario

Before any migration

• Choose a low-risk maintenance window. Avoid launching a campaign, releasing a major feature, or changing the site immediately before the move.
• Confirm the destination supports your application’s required runtime, database engine, extensions, web server features, and background jobs.
• Measure current storage, database size, memory use, CPU load, and traffic patterns. Use these observations to size the new environment rather than relying only on disk space.
• Create and download a complete backup of website files, databases, configuration files, media, and relevant mail data.
• Test that the backup can be opened or restored. A backup that has never been verified is not a dependable rollback plan.
• Record DNS records, including A, AAAA, CNAME, MX, TXT, and any verification or subdomain records. The DNS records guide can help identify what each record does.
• Check domain registration access, nameserver settings, DNS provider access, and the expiry date. Hosting migration and domain transfer are separate tasks; do not combine them unless there is a clear reason.
• Lower the DNS TTL for the web records ahead of the planned cutover, subject to the limits and guidance of your DNS provider. Allow enough time for the lower TTL to take effect.
• List every person who needs access during the migration and use temporary credentials where appropriate. Remove temporary access afterward.

Moving a WordPress site

• Update WordPress core, the theme, and plugins only when you have a tested backup and a reason to update. Avoid combining unrelated upgrades with the hosting move.
• Check plugin and theme requirements against the destination PHP and database versions. Disable maintenance, security, caching, or optimization features that could interfere with copying if the migration method requires it.
• Copy the WordPress files, including wp-content, uploads, custom configuration, and any files outside the standard installation that the site uses.
• Export and import the database using a method appropriate to its size. Confirm character set, collation, table prefixes, and database credentials.
• Update the destination configuration with the new database name, user, password, host, and table prefix. Keep secrets out of public repositories and shared notes.
• Use a temporary hostname, staging URL, hosts-file override, or provider preview address to test the site before changing public DNS. Be careful with search engine indexing and canonical URLs when using a temporary address.
• Regenerate caches only after the site works on the new server. Review permalinks, media URLs, redirects, forms, login, search, comments, ecommerce functions, and scheduled publishing.

For a broader sequence, use the website migration checklist alongside this scenario-specific list.

Moving a custom application to a VPS

• Document the deployment process rather than copying an undocumented server state. Include environment variables, build commands, service definitions, reverse-proxy rules, file permissions, and scheduled workers.
• Install only the required packages and runtimes, then apply the destination provider’s security recommendations. Confirm firewall rules, SSH access, key-based authentication, updates, and log handling.
• Provision the database and verify connection limits, backup jobs, time zone settings, and remote access restrictions.
• Recreate queues, cron jobs, webhooks, object storage connections, email delivery, and third-party API credentials. Test each integration independently.
• Set resource alerts and uptime monitoring before the cutover. The uptime monitoring guide covers useful checks and incident-response basics.

During cutover

1. Place the site in maintenance mode or pause writes if the application supports it. This prevents new orders, posts, registrations, or form submissions from landing in only one database.
2. Take a final database backup and record its timestamp.
3. Perform the final file and database synchronization.
4. Confirm the destination is serving the correct content and that the application can read and write data.
5. Update the relevant A, AAAA, or CNAME record. Leave mail records unchanged unless email is intentionally being migrated.
6. Monitor both the old and new environments. Test the site through more than one network and device where possible.
7. Keep the old environment available until traffic is consistently reaching the destination and the rollback window has passed.

What to double-check

DNS and domain settings: Confirm the nameservers, DNS zone, apex domain, www hostname, staging subdomains, API endpoints, and mail records. A missing MX or TXT record can affect email even when the website appears healthy. If the domain itself must move, follow a separate domain transfer checklist.

SSL and redirects: Issue or install the certificate for every required hostname, then test HTTPS, HTTP-to-HTTPS redirects, canonical URLs, and mixed-content warnings. Use the SSL certificate troubleshooting guide if browsers report certificate or redirect errors.

Application behavior: Test login, logout, password reset, contact forms, file uploads, search, checkout, recurring tasks, webhooks, and transactional email. Check that uploaded files are writable but not unnecessarily executable.

Performance: Compare representative page loads, database response, cache behavior, image delivery, and server resource usage with your pre-migration baseline. Faster hardware will not correct an inefficient query, a broken cache, or an oversized application.

Backups and recovery: Confirm that new backups run on the destination, are stored separately from the server, and can be restored. The website backup and recovery plan provides a practical framework for this verification.

Rollback: Define the exact condition for reverting DNS, who can authorize it, and which data must be synchronized first. If users can create or change data after cutover, reversing DNS without reconciling the database can cause data loss.

Common mistakes

• Changing nameservers too early: Build and test the destination before directing public traffic to it.
• Forgetting non-website records: Copying only the web record can disrupt email, verification services, APIs, and subdomains.
• Skipping a final database sync: Files may be current while orders, comments, or form entries remain on the old server.
• Changing too many variables at once: Avoid pairing the move with a major redesign, platform upgrade, plugin replacement, or URL change unless the combined change is necessary and fully tested.
• Assuming a control panel copied everything: Review cron jobs, SSL certificates, redirects, mailboxes, databases, aliases, permissions, and scheduled tasks manually.
• Deleting the old account immediately: Preserve the old environment until monitoring, backups, and application checks show that the migration is stable.
• Ignoring indexing and caching: Check robots directives, canonical tags, cache layers, and temporary-domain settings so the migration does not create duplicate or inaccessible pages.

When to revisit

Reuse this checklist before seasonal planning cycles, traffic spikes, renewals, major marketing launches, or a planned move from shared hosting to scalable hosting. Revisit it whenever the application adds a payment provider, email service, external API, background worker, or storage integration.

Update provider-specific steps before publishing or using them again. Check the destination’s supported PHP, database, and runtime versions; control-panel workflow; migration-service scope; backup and restore commands; DNS interface; SSL process; and pricing model. These details can change even when the overall migration method remains the same.

After the move, schedule a short review of uptime, error logs, resource usage, backups, forms, email delivery, and search visibility. Record what worked, what required manual repair, and how long rollback remained viable. That migration record becomes the starting point for the next upgrade instead of relying on memory.

Action plan: choose the destination, capture the current-state inventory, verify a restorable backup, build and test the new environment, lower DNS TTL in advance, define rollback criteria, complete the final synchronization, change DNS, and monitor before retiring the old hosting account.