Migrating from Shared Hosting to Cloud Without Breaking Anything

Moving from shared hosting to a cloud server is usually straightforward technically and surprising operationally. The files copy across in an afternoon.

What takes longer is replacing everything the hosting control panel was doing quietly in the background.

What you gain and what you take on

The move is worth it when you need specific software versions, more consistent performance, root access, or the ability to grow. It is not worth it for a small brochure site that works fine as it is.

The things people forget

Before touching anything, inventory what the hosting account is actually doing:

• Email. Shared hosting usually includes mailboxes. A cloud server does not. Plan for a dedicated mail service before the cutover, or you will move a site and break the business's email. This is the single most common migration failure.
• Cron jobs. Scheduled tasks configured in the panel, easily overlooked.
• DNS. Often managed by the same provider. Establish where DNS will live.
• Subdomains and add-on domains. Each needs its own configuration.
• TLS certificates. Automate issuance and renewal on the new server.
• Redirects and rewrite rules in .htaccess that the new web server must reproduce.
• PHP or runtime version and extensions. Match them, then upgrade deliberately afterwards — not during the migration.
• File permissions and ownership, which differ between environments.
• Database users and grants, not just the data.

A staged plan

Stage 1 — Prepare the destination. Provision the server, size it from the current load rather than guessing. For a typical site moving off shared hosting, a modest instance is usually ample — the sizing guide covers measuring it. A DigitalOcean account or Linode account suits this well, with predictable flat pricing and managed database and object storage options nearby.

Stage 2 — Build the stack. Web server, runtime, database, certificate automation, firewall. Configure it as you intend to keep it rather than mirroring the shared host's quirks.

Stage 3 — Copy the data. Files by rsync or archive; database by dump and import. Do this once as a rehearsal, not as the cutover.

Stage 4 — Test properly. Point your own machine at the new server using a hosts-file entry and exercise the site fully: forms, logins, payments, uploads, scheduled tasks, email sending. Fix what is broken while the old site is still serving users.

Stage 5 — Reduce DNS TTL. Drop it to 300 seconds at least 24 hours before the cutover, so the change propagates quickly.

Stage 6 — Cut over. Put the old site into read-only or maintenance mode, take a final database dump, import it, switch DNS, and watch.

Stage 7 — Verify and keep the old host. Confirm everything works under real traffic. Keep the old hosting for a couple of weeks as a fallback and for anything you forgot.

After the migration

The responsibilities that were previously invisible are now yours:

1. Automatic security updates — enable unattended upgrades at minimum.
2. A firewall allowing only what is needed, with SSH restricted rather than open to the world.
3. Backups off the server, to object storage, tested by restoring. The backup guide covers this.
4. Monitoring — uptime, disk space, certificate expiry. The monitoring guide covers the minimum useful set.
5. A documented rebuild path, ideally as code, so the server is reproducible rather than a artefact nobody dares touch.

Point five matters more than it sounds. A hand-configured server that nobody can rebuild becomes an obstacle within a year. Infrastructure as code addresses it.

Email is the part that breaks

Shared hosting bundles outbound mail so quietly that most people only discover the dependency when contact forms, password resets and order confirmations stop arriving after a migration.

A cloud server does not come with a working mail reputation. Providers commonly restrict outbound SMTP on port 25 by default to limit abuse, and even where the port is open, mail sent from a fresh address with no sending history is frequently filtered. The practical options are to use an authenticated relay or transactional mail service for application mail, or to request that the provider open outbound mail for an account with a legitimate sending case.

Whichever route you take, authentication records decide delivery. SPF, DKIM and DMARC need to be published for the sending domain before cutover, not after complaints start. Send a test message to accounts at two or three major mail providers and read the received headers to confirm the records pass.

The guide to SMTP port 25 and deliverability covers the restrictions and the configuration in detail.

Frequently asked questions

How much downtime is involved? With a rehearsed migration and a low DNS TTL, typically minutes. The final database sync is the only genuinely blocking step.

Should I move email to the new server? No. Use a dedicated email provider. Running a mail server well is a specialist ongoing job, as the deliverability guide explains.

Managed database or on the same server? On the same server is fine initially and simpler. Separate it when the two start competing for memory.

What if something breaks after cutover? Switch DNS back, which is why the old hosting stays active and why the TTL was lowered. Plan the rollback before you need it.