Migrating from shared hosting to a cloud VPS: a practical checklist to avoid downtime

If you are moving a production website from shared hosting to a cloud VPS, the goal is not just “move files and hope for the best.” The goal is to preserve uptime, prevent data loss, and create a repeatable migration process you can use again. This guide is a checklist-style runbook for developers, sysadmins, and small technical teams, with practical steps for planning, transferring data, switching DNS, validating SSL, testing thoroughly, and rolling back if needed. If you are also documenting an internal process library, this pairs well with migration planning patterns and cutover continuity playbooks.

The most common cause of downtime during a hosting migration is not the server itself. It is an uncoordinated sequence: DNS changes before data sync, missing SSL, forgotten cron jobs, or application settings that still point at the old host. Treat the move like an operations change window, not a copy-and-paste task. For broader infrastructure planning, especially if your app depends on geography, provider choices, or future scaling, see geo and data-center investment planning and vendor evaluation checklists.

1) Pre-migration planning: define scope, risk, and success criteria

Inventory what is actually on shared hosting

Before you move anything, inventory the whole stack. Many shared hosting accounts contain more than a single website: subdomains, email mailboxes, redirects, scheduled jobs, database instances, object storage integrations, and staging sites may all live under one cPanel account. Write down every domain and subdomain, every app, database name, PHP version, and any external dependencies such as SMTP providers, payment gateways, CDN rules, and DNS records. This is the same discipline used in device and account connection audits: if you do not enumerate dependencies, you will miss one.

Choose the migration method based on risk, not convenience

A small static site can often be migrated with a single sync and DNS update. A WordPress site with frequent content updates needs a more careful delta sync and a content freeze window. An ecommerce site may need maintenance mode, database replication, or a short write lock. The point is to choose the least disruptive path for your workload. For complex service transitions, the logic is similar to a helpdesk migration: the more stateful the system, the more important phased cutover becomes.

Define success metrics and rollback triggers

Decide up front what “successful migration” means. Typical criteria include page loads returning 200 status over HTTPS, forms submitting correctly, media files loading, admin login working, and email still flowing. Also define rollback triggers, such as failed checkout tests, SSL handshake errors, unexpected 5xx spikes, or data that does not match the source. A strong rollback rule is simple: if a critical path fails and cannot be fixed within the agreed window, revert DNS and keep investigating on the new VPS offline. For teams that want to document decision thresholds more formally, borrow patterns from workflow selection frameworks.

Pro Tip: Freeze content changes before the final sync. Even a small article edit or order update can create confusing data drift if the app is still accepting writes during cutover.

2) Build the cloud VPS correctly before moving data

Match the server to the workload

Your VPS should be provisioned before migration day with the correct CPU, RAM, disk type, and region. For a WordPress site, a 1–2 vCPU VPS with SSD storage may be enough at low traffic, but heavier plugins, WooCommerce, or large image libraries need more memory and possibly caching. Pick the operating system you are comfortable administering, then install only what you need: web server, PHP runtime, database server if self-hosted, firewall, and monitoring. If you are comparing environments, it helps to think like a procurement decision: build a baseline, then expand. That approach is similar to the selection discipline in value-focused purchasing guides, just applied to infrastructure.

Harden access and basic security first

Set up SSH keys, disable password logins if possible, configure a non-root sudo user, and open only the ports you truly need. Install a firewall profile and verify that HTTP, HTTPS, and SSH are reachable from the right sources. If you are using a control panel, secure its login immediately. Do not wait until after the app is live, because the migration process itself often exposes temporary credentials and test endpoints. For teams managing multiple connected systems, the security mindset aligns with vulnerability-aware device operations.

Prepare monitoring, backups, and logs

Turn on server-level monitoring before the migration, not after. You want CPU, RAM, disk, web server errors, database health, and uptime alerts available during the cutover. Take a full backup of the shared-hosting site and a second backup of the VPS baseline after provisioning. Log retention matters too: if something breaks, your error logs and access logs are the only reliable witness. Teams that already document operational safeguards often benefit from patterns like preventive maintenance checklists.

3) Data transfer checklist: files, databases, and application state

Move site files with integrity checks

Download the entire web root, including hidden files such as .htaccess, .user.ini, and any environment configuration files the app requires. Use rsync where possible because it preserves permissions and lets you rerun the transfer efficiently. Example:

rsync -avz --progress user@oldhost:/home/user/public_html/ /var/www/site/

After copying, compare file counts and spot-check critical directories like uploads, theme assets, and plugin folders. If you host a large WordPress media library, consider separating future uploads to object storage or a CDN to reduce dependency on the VPS disk. The same principle appears in performance-focused hosting guidance: reduce bottlenecks before they become outage points.

Export and import databases safely

For dynamic sites, the database is usually the most important piece. Use mysqldump or an equivalent export with structure and data, then import into the VPS database. Example:

mysqldump -u olduser -p olddb > backup.sql
mysql -u newuser -p newdb < backup.sql

Verify character sets, table prefixes, and collation settings. For WordPress, confirm the site URL and home URL if the domain or temporary test domain changes. If you are migrating WooCommerce or membership data, test the database import in a staging copy first, because serialized data and plugin metadata can break when the environment differs. A practical cross-check comes from step-by-step transition runbooks, which emphasize validating state, not just copying it.

Handle application state, uploads, and cron jobs

Do not forget scheduled tasks and background workers. A site may appear functional but silently stop sending emails, generating reports, or clearing caches after migration. Copy crontab entries, queue workers, and systemd timers if the application uses them. If your app depends on email delivery, set up SMTP configuration before testing contact forms. For teams that run integrations, this is similar to a workflow integration pattern: the handoff logic matters as much as the main app.

4) DNS cutover: plan the switch before you flip it

Lower TTL well in advance

At least 24 to 48 hours before migration, lower the TTL on the relevant DNS records, especially A, AAAA, and CNAME records. Lowering TTL allows resolvers to refresh sooner when you change the destination IP. Do not wait until the night of the migration if you want fast propagation. The practical approach to routing and fallback is similar to alternate routing during disruptions: the time to plan the alternate path is before you need it.

Decide which records move and which stay put

Not every DNS record should point to the VPS. Email records such as MX, SPF, DKIM, and DMARC may remain with your current provider or third-party email service. Keep a full DNS record export before the change, and document every record you intend to preserve. If you use a CDN or WAF, the DNS target may be the CDN rather than the VPS directly. This is where careful record-by-record verification prevents surprise outages.

Use a temporary test hostname if possible

Before changing production DNS, test the VPS on a temporary hostname or hosts-file override. This lets you verify the new server without exposing customers to unfinished changes. Load the site over HTTPS, submit forms, test login flows, and inspect image paths. A controlled preview environment makes the final cutover much safer and is often the best place to catch configuration bugs. In the same spirit, prototyping workflows often reveal issues before final release.

5) SSL, redirects, and domain configuration

Issue certificates on the new server before launch

Provision SSL before you point production traffic at the VPS. If you use Let’s Encrypt, verify that the domain resolves to the new server or that you can complete HTTP-01 or DNS-01 validation. A common mistake is cutting over DNS first and then finding that the certificate is still missing or misconfigured. That causes browser warnings at the worst possible time. If you are working with multiple subdomains, consider using a wildcard certificate or automate issuance via DNS validation.

Preserve canonical URLs and redirects

Check that HTTP to HTTPS redirects still work, and that non-www to www behavior matches the old site if necessary. Broken redirect chains can damage SEO and confuse users. Make sure your CMS or framework does not generate mixed-content warnings by still referencing old asset URLs. If you run WordPress, inspect the settings and any hard-coded URLs in themes or page builders. Teams maintaining structured documentation often treat this like a controlled configuration change, similar to transparent hardware review and trust-building.

Test certificate chains and browser behavior

Do not stop at “the padlock appears.” Check the full chain with browser dev tools or a command like curl -I https://example.com. Confirm that the certificate covers every host your users will hit and that expiration is tracked in monitoring. If you use a CDN in front of the VPS, validate origin SSL settings separately from edge SSL. That distinction is often missed in migrations and can cause confusing handshake failures.

6) Testing before, during, and after cutover

Build a test matrix for critical user journeys

At minimum, create a short list of flows that must work: homepage load, internal navigation, search, login, password reset, contact forms, purchases, file downloads, admin login, and automated emails. Test them on the temporary hostname first, then again after DNS points live. Document results in a simple matrix so the team can see what passed and what still needs attention. If your business depends on content velocity, this is not unlike content-preview templates: structure makes validation faster.

Check backend services, not just the front end

Sites often look fine in a browser while background services fail silently. Verify database writes, queue processing, scheduled tasks, webhook callbacks, and file permissions. Confirm that logs are being written where you expect and that disk space remains healthy after uploads or cache warmups. If your application integrates with external APIs, run a transaction test in a sandbox or low-risk mode first. This is where a disciplined operational approach matters, much like maintaining continuity across a platform change.

Use smoke tests and synthetic checks

A smoke test is a short, high-value checklist that proves the migration is basically sound. Synthetic checks can keep watching the site every minute after launch, giving you early warning if the VPS is overloaded or a configuration error appears under real traffic. Ideally, you run the same tests before and after cutover so you can compare behavior. If you manage technical operations across multiple services, this mirrors the governance used in privacy-conscious systems testing and other risk-managed deployments.

7) Rollback planning: your safety net against bad cutovers

Keep the old shared host alive long enough

Do not cancel shared hosting immediately after migration. Keep the old environment online until the new VPS has survived a full validation window and you are confident DNS has propagated. In many cases, 24 to 72 hours is enough, but some teams keep it longer for safety. The old host serves as both rollback target and forensic reference if you need to compare files or database content. This is basic operational insurance, similar in spirit to a phased transition in service migration playbooks.

Write a rollback checklist before go-live

A rollback checklist should be short and executable under stress. It should say exactly who changes DNS, what the old IP is, how to revert the database if needed, and where backups are stored. Include a trigger condition and a communications note so users or stakeholders know what happened. A rollback plan is not a sign of weakness; it is a sign that you understand production systems can fail in unexpected ways. Good ops teams treat rollback as part of the migration, not an afterthought.

Time-box troubleshooting during cutover

Set a troubleshooting window. If critical failures persist beyond that window, stop trying to “fix live” and execute rollback. This prevents a noisy, drawn-out incident from becoming a full outage. Keep change logs, terminal output, and screenshots of the failure states because they will help if you return to the issue later. A disciplined decision window is one of the simplest ways to keep risk controlled.

8) Post-migration validation and stabilization

Validate the site like a new production release

Once traffic is on the VPS, treat the first 24 hours like a release observation period. Watch server load, error rates, response time, and any spikes in 404s or 500s. Confirm search engines and cache layers are seeing the right canonical URLs. Verify that analytics, tag managers, and conversion tracking are firing exactly once, not duplicating events. This post-launch discipline is part of what makes operational content trustworthy, similar to performance monitoring guidance.

Audit SEO, mail, and application integrations

After the switch, review sitemap generation, robots directives, redirects, and SSL status in search tools. Test outbound email from contact forms, password resets, and transactional notifications. Check integrations with payment processors, CRMs, and webhooks. Many migration incidents are not visible to end users until a downstream system fails to receive an event. If you are running a content-heavy site, a migration can also affect publishing workflows, so validate admin roles and media uploads carefully.

Schedule cleanup and decommissioning

Once the new VPS is stable, document what was changed, what needs follow-up, and what the final architecture looks like. Rotate any credentials used during migration, update internal docs, and archive the old host only after the retention window expires. This is a good time to improve the setup: automate backups, add uptime checks, or move deploys into a simple CI pipeline. Teams that standardize the process often improve future migrations as much as the current one.

Pro Tip: The best migration is the one you can repeat. If you write down every command, every DNS change, and every validation step, the next move becomes a routine instead of a fire drill.

9) WordPress-specific migration checklist

Update site URLs and serialized data carefully

WordPress often needs URL updates when moving from a temporary domain or changing site paths. Use a search-replace tool that understands serialized data rather than editing the database by hand. Confirm the home and site URL values in the database and settings. Broken internal links, image paths, and page builder metadata are common after migration if this step is skipped. If WordPress is your primary workload, add a dedicated preflight step to your runbook.

Check plugins, themes, and PHP compatibility

Shared hosting and VPS environments often differ in PHP version and extensions. A plugin that worked previously may fail on the new server if a module is missing or PHP is too new or too old. Test the theme, caching plugin, security plugin, and backup plugin after the move. Disable anything that causes fatal errors, then re-enable one by one. This mirrors the careful validation approach used in tool-selection guides: isolate variables and confirm fit.

Protect uploads, media, and permalinks

Make sure the uploads directory exists and is writable, then flush permalinks if needed. If thumbnails, webp files, or responsive image variants are missing, regenerate them with a safe tool after confirming disk space is sufficient. Verify file ownership and permissions because WordPress can behave unpredictably when the web server user cannot write to the expected paths. A simple permission mistake can look like a broken site even though the content is present.

10) A practical migration checklist you can copy into your runbook

Before migration day

Reduce DNS TTL, inventory all services, create full backups, provision the VPS, harden access, and prepare monitoring. Set the maintenance window, notify stakeholders if necessary, and create a rollback plan. Verify that you can access the new server via SSH or panel login. In a broader operations context, this is the same diligence that makes vendor evaluation and capacity planning work in practice.

During migration

Copy files, export and import the database, restore config files, configure SSL, and test on a temporary hostname. Confirm scheduled jobs, email, and integrations. Flip DNS only after the new server passes smoke tests. Keep the old host online until you confirm traffic and functionality are stable.

After migration

Monitor logs, validate user journeys, check SEO and analytics, and compare key metrics to baseline. Fix any lingering issues, update documentation, and schedule a cleanup of temporary credentials and old infrastructure. Once you have confidence in the new VPS, you can optimize performance, automate deployments, and standardize the process for future moves.

11) Common migration problems and how to troubleshoot them

Site loads on old host after DNS change

This usually means DNS propagation is incomplete or a local resolver cached the old record. Verify the authoritative DNS record and check the site from multiple networks. If some users still hit the old site, keep the old host alive until the TTL window closes. This is normal, not necessarily a failure.

SSL error after cutover

Most SSL errors are caused by a missing certificate, wrong host mapping, or a certificate issued for the wrong domain. Confirm that the certificate matches the production hostname and that the web server is using the expected config file. If you are behind a CDN, check origin and edge SSL separately. Test with browser dev tools and curl before assuming the certificate authority is the problem.

Database or admin login fails

Check database credentials, hostnames, and any environment variables in the application config. WordPress users should verify table prefixes and database names. If login is broken but the front end works, inspect session storage and plugin conflicts. When in doubt, compare against the old server’s configuration line by line.

12) Final checklist summary

Shared hosting to cloud VPS migrations fail when teams treat them like file transfers instead of controlled infrastructure changes. The safest path is simple: inventory everything, provision and harden the VPS, back up first, copy files and databases carefully, lower TTL, validate on a temporary hostname, issue SSL, cut DNS only after smoke testing, and keep a rollback ready. If you follow that order, you reduce surprises and create a migration process you can reuse. Over time, your runbook becomes one of your most valuable operational assets, alongside your backup strategy and incident notes.

For further reading on the surrounding operational patterns, see our guides on minimizing downtime during system migrations, maintaining continuity during platform replacement, and performance optimization under production load. Those playbooks reinforce the same principle: measure twice, cut once, and always keep a way back.

Related Reading

• Using Off‑the‑Shelf Market Research to Prioritize Geo-Domain and Data-Center Investments - Useful when deciding where your VPS should live for latency and resilience.
• Migrating to a New Helpdesk: Step-by-Step Plan to Minimize Downtime - A close operational cousin for managing platform cutovers cleanly.
• Performance Optimization for Healthcare Websites Handling Sensitive Data and Heavy Workflows - Practical tuning ideas that apply to post-migration VPS hardening.
• Securing Smart Offices: Best Practices for Connecting Devices to Workspace Accounts - Helpful for thinking about access control and configuration hygiene.
• Choosing a UK Big Data Partner: A CTO’s Vendor Evaluation Checklist - A strong model for evaluating infrastructure vendors before you commit.