Shared Hosting to Cloud Hosting Migration Checklist

Overview

This guide gives you a practical checklist for a shared hosting to cloud hosting move, with enough structure to support both small business sites and developer-managed projects. Instead of treating migration as a single switch, it helps you break the work into phases: assessment, preparation, transfer, cutover, and post-launch review.

Shared hosting often hides complexity behind a simple control panel. That convenience is useful, but it can also mask the details your website depends on: PHP versions, cron jobs, email routing, database users, file permissions, caching behavior, DNS records, and background tasks. Cloud hosting usually gives you more flexibility, but it also puts more responsibility on your team.

Before you move a website from shared hosting, define what success looks like. For most teams, that means:

• No data loss
• Minimal or no visible downtime
• Working SSL and DNS after cutover
• Equal or better page speed
• No missing forms, emails, media files, or scheduled jobs
• A backup and rollback plan if something fails

If you are still comparing architectures, it helps to clarify whether you need fully managed cloud hosting or a more hands-on setup. Teams with limited time may prefer a managed environment with backups, staging, security updates, and support built in. Teams that need deeper control may want a cloud instance they configure themselves. For a broader setup path, see How to Host a Website on the Cloud: Beginner-to-Intermediate Setup Guide.

Use the checklist below as a working document. Mark each item before cutover, not after.

Checklist by scenario

This section breaks the hosting migration checklist into reusable scenarios so you can focus on the parts that match your site.

1. Pre-migration checklist for any website

• Inventory the current site. List domains, subdomains, CMS versions, plugins or extensions, themes, server-side languages, database versions, cron jobs, email accounts, SSL setup, redirects, and third-party integrations.
• Document current DNS records. Save A, AAAA, CNAME, MX, TXT, and any verification records before changing anything. A separate DNS mistake can look like a hosting problem later. If needed, review DNS Setup for a New Website: Records, Propagation, and Common Mistakes.
• Check application requirements. Confirm the target cloud environment supports the needed runtime, database engine, memory limits, and file system behavior.
• Create a full backup. Back up site files, databases, configuration files, uploads, and any custom scripts. Store a copy off-server. For a more detailed approach, see Website Backup Strategy Checklist: What to Back Up, How Often, and Where to Store It.
• Reduce DNS TTL in advance. Lower TTL values before cutover if your provider allows it. This can make DNS changes propagate more smoothly when you are ready to switch.
• Choose a migration window. Pick a low-traffic period and avoid active campaign launches, product drops, billing runs, or major content updates.
• Define rollback steps. Know exactly how you would point traffic back to the old host if the migration fails.

2. Checklist for WordPress cloud hosting migrations

• Export both files and database. A working WordPress move needs both, including uploads, themes, plugins, and the complete database.
• Match PHP and database compatibility. Test the site in a staging or temporary URL before going live.
• Review plugin assumptions. Some plugins rely on server modules, writable paths, image libraries, or scheduled tasks that differ between hosts.
• Rebuild wp-config settings carefully. Confirm database credentials, salts if needed, debug settings, memory limits, and any environment-specific constants.
• Validate scheduled tasks. Shared hosting may have relied on pseudo-cron behavior from web traffic. Cloud hosting may need a proper scheduled task setup.
• Check caching layers. Remove old host-specific caching plugins or page cache rules that conflict with the new environment.
• Use staging first. For a safer test workflow, review Staging Environment Setup Guide for WordPress and Custom Websites.
• Review hosting feature parity. Compare backups, staging, caching, and security controls against your old setup with help from WordPress Hosting Features Checklist: Backups, Staging, Caching, and Security.

3. Checklist for custom PHP, CMS, or database-driven sites

• Audit environment variables and secrets. Make sure API keys, SMTP credentials, app secrets, and database passwords are moved securely.
• Review file permissions. Shared hosting permissions are often broad; cloud environments may require more deliberate ownership and permission settings.
• Verify rewrite rules and redirects. Apache and Nginx behavior differs, especially for rewrite logic, trailing slash handling, and access controls.
• Confirm background jobs. Queue workers, cron tasks, report generation, or import jobs must be recreated on the new server.
• Check upload paths and storage. If the application uses local file storage, confirm paths, symbolic links, and retention rules are still valid.
• Test transactional flows. Logins, checkout, search, contact forms, admin actions, and password reset flows should be tested before launch.

4. Checklist for ecommerce or high-change websites

• Plan for data freshness. Stores and membership sites change often. Avoid a long gap between final export and DNS cutover.
• Pause risky changes. Temporarily avoid large catalog imports, plugin updates, design edits, or payment setting changes near migration time.
• Review payment and email integrations. Confirm webhook endpoints, transactional email delivery, tax tools, shipping tools, and order notifications still work.
• Test checkout end to end. Validate cart persistence, account login, coupon logic, order emails, and confirmation pages.
• Monitor error logs after launch. Subtle failures often appear first in logs, not in visible pages.

5. Cutover checklist

• Put the site in maintenance mode if appropriate. This is especially useful for sites with frequent content or order changes.
• Take a final backup immediately before switching.
• Sync final file and database changes.
• Update DNS records. Point the domain to the new cloud hosting environment.
• Install and verify SSL. Make sure the certificate covers the correct domain names and redirects work over HTTPS. For details, see SSL Certificate Setup Guide for Small Business Websites.
• Check the live domain, not only the temporary URL. Cookies, canonical tags, mixed content, and secure sessions can behave differently after the domain switch.
• Keep the old hosting account active temporarily. Do not cancel it until the new site has been validated and DNS propagation is complete.

6. Post-migration validation checklist

• Test the top pages. Home page, landing pages, product or service pages, blog posts, contact forms, and admin login should all work.
• Verify forms and outgoing email. Many migrations fail quietly here.
• Review redirects and canonical tags. Make sure existing URLs still resolve correctly and search engines are not being given conflicting signals.
• Check robots.txt and indexing settings. A staging noindex setting accidentally carried into production is a common issue.
• Measure speed and basic responsiveness. Confirm the move actually improved fast web hosting outcomes rather than adding latency or heavy cache misses.
• Confirm backup jobs are running. Backup setup does not automatically carry over just because the site files do.
• Watch uptime and logs. Monitor for 404s, 500s, PHP errors, database connection errors, and SSL warnings.
• Review Core Web Vitals-related settings. Cache configuration, compression, image handling, and server response behavior all matter. See Core Web Vitals Hosting Checklist: Server Settings That Improve Site Speed.

What to double-check

These are the items most likely to be missed during a website host migration, even when the main site appears to load normally.

• DNS records beyond the website root. Email, subdomains, verification records, and third-party services can break if only the main A record is copied.
• SSL renewal method. Make sure the new host can renew certificates reliably or that your manual process is documented.
• Email routing. If the old shared host handled mailbox services, a website move alone may not preserve email delivery.
• Scheduled jobs and automation. Backups, imports, cleanup tasks, and publishing jobs must be recreated and tested.
• File ownership and writable directories. A CMS can appear healthy until it tries to upload media, write cache files, or install an update.
• CDN and caching settings. Purge or reconfigure caches after launch so visitors do not see stale pages or broken assets.
• Hard-coded URLs. Some sites still contain old domain paths, protocol references, or asset URLs tied to the previous environment.
• Firewall, WAF, or rate-limiting rules. Security controls can unintentionally block legitimate forms, APIs, admin access, or webhook traffic after the move.
• Monitoring coverage. Add uptime checks, backup checks, and alerting after cutover rather than waiting for a user report.

Small business teams should also review routine operational tasks after migration. A good follow-up resource is Website Maintenance Checklist for Small Business Owners.

Common mistakes

A careful migration usually fails for ordinary reasons, not rare ones. These are the mistakes worth avoiding first.

• Moving without an inventory. If you do not know what the old environment was doing, you will miss hidden dependencies.
• Testing only the home page. A site can look fine while login, search, forms, checkout, uploads, or admin tools are broken.
• Cancelling the old host too early. Keep the previous account available until you are fully confident in the new environment.
• Ignoring DNS lead time. Last-minute TTL changes may not help if they are made too late.
• Combining migration with redesign. It is usually easier to separate infrastructure change from design or content change so troubleshooting stays simple.
• Not accounting for email. Many shared hosting accounts bundle website and mailbox services together. Moving one does not automatically move the other.
• Forgetting backups on the new host. A completed migration is not a protected migration unless the new backup routine has been tested.
• Assuming cloud hosting fixes everything by itself. Better infrastructure helps, but performance, security, and reliability still depend on configuration and maintenance.

If your broader decision is still between a hosted site builder and a more flexible CMS or cloud stack, these comparisons may help narrow the right long-term path: Website Builder vs WordPress: Long-Term Costs, Control, and Maintenance and Best Website Builders for Small Business: Pricing, Limits, and Scalability.

When to revisit

This checklist should not be used only once. Revisit it whenever your hosting inputs change, especially before a seasonal traffic cycle, after a platform upgrade, or when your team changes deployment workflows.

Use this short refresh list before your next review:

• Re-check your traffic pattern. Has the site outgrown the original cloud instance, cache strategy, or storage setup?
• Re-check your dependencies. New plugins, integrations, APIs, or payment tools may introduce migration-sensitive components.
• Re-check backups and recovery. Run a restore test, not just a backup job check.
• Re-check DNS documentation. Make sure records are still documented and ownership of registrar and DNS access is clear.
• Re-check security controls. Review SSL renewal, firewall rules, admin access, and least-privilege credentials.
• Re-check staging and deployment process. If your workflow has changed, update the migration runbook to match current practice.
• Re-check performance baselines. Capture current load times and server response behavior so a future migration can be measured properly.

A useful final step is to convert this article into your own internal runbook. Add your provider-specific commands, rollback contacts, DNS screenshots, and application test cases. That turns a general hosting migration checklist into a repeatable operating procedure.

If you are planning the move now, the most practical next actions are simple: document the old environment, create a restorable backup, build a staging copy on the target cloud hosting platform, and test every important user path before you update DNS. That sequence prevents most avoidable migration problems and gives you a cleaner path to scalable web hosting later.