Migrating from Shared Hosting to a Cloud Server

What you gain and what you take on

Shared hosting hides the machine. You get a control panel, a quota and somebody else's decisions about PHP versions, mail routing and security patches. A cloud server hands all of that back to you, along with the freedom that made you consider moving.

The gains are real: your own resources rather than a slice of a contended box, any software stack you like, and the ability to grow the server instead of changing plans. So is the new work. Patching, backups, firewall rules, certificate renewal and mail deliverability all become yours.

Before committing, be honest about who will do that work. If nobody on the team wants it, a managed cloud platform or a virtual private server with a managed panel is a better answer than an unmanaged instance nobody maintains.

Audit the shared account first

Shared hosting accounts accumulate things nobody remembers creating. Enumerate everything before you size a server, because the forgotten items are what break after cutover.

• Every site and subdomain in the panel, including the staging copy from two years ago.
• Databases and their users, with sizes noted rather than estimated.
• Cron jobs, including the ones calling a URL rather than a script.
• Email accounts, forwarders, autoresponders and any mailbox with years of stored mail.
• DNS zone records, exported in full, including MX, SPF, DKIM and any verification records.
• SSL certificates and their expiry dates, plus whether they renew automatically.
• PHP version and enabled extensions, since a version mismatch is the most common post-move failure.
• Any panel feature doing real work: hotlink protection, redirects, IP blocks, password-protected directories.

Download the panel's own backup as well. It is the fastest way to obtain files, databases and mail in one archive, and it costs nothing to keep.

Deal with email before anything else

Email is the single biggest trap in this migration, and it deserves its own decision made early. On shared hosting, mail usually comes bundled with the web account, so moving the website moves the mailboxes by accident.

The right move in almost every case is to separate them permanently. Put mailboxes on a dedicated mail service, point the MX records there, and let the website live wherever it likes from then on. You will never have to think about this again.

Running your own mail server on a cloud instance is possible but rarely wise. Providers restrict outbound connections on the standard mail port by default, fresh addresses carry no sending reputation, and deliverability becomes a permanent chore. The reasons are set out in port 25 and outbound email.

Whatever you decide, migrate mailbox contents before touching the MX records, and keep the old mailboxes reachable for a while afterwards so nothing arrives at an empty box.

Sizing the destination

Shared hosting gives you no useful metrics, so sizing is inference rather than measurement. Use three inputs: total disk used by files and databases, peak concurrent visitors from your analytics, and the heaviness of the application itself.

For a handful of content sites, a small instance with two virtual cores and a few gigabytes of memory is a realistic starting point. For a busy store or a forum, start larger and measure. Cloud servers resize, which is the entire point, so the first choice is a hypothesis rather than a commitment.

Attach separate block storage for site data if you expect growth, since a volume can be expanded independently of the instance. Choose a region close to your visitors, not close to you.

Developer clouds are the natural destination for this kind of move: flat pricing, straightforward consoles and included bandwidth allowances. The two most common options are set against each other in DigitalOcean versus Hetzner, with account details in the DigitalOcean and Hetzner listings.

Build the server, then copy into it

Build and test the new environment completely before any DNS changes. There is no reason to rush this stage, because the old site is still serving visitors.

1. Provision the instance, create a non-root user, configure the firewall to allow only what you need, and disable password authentication for SSH. The full checklist is in securing a new cloud server.
2. Install the stack: a web server such as Nginx or Apache, the matching PHP or runtime version, and MariaDB or PostgreSQL.
3. Copy files with rsync over SSH, or from the panel backup if SSH is unavailable on the old host. Preserve ownership and permissions.
4. Import databases from a dump, then confirm collation and character set match the original, because mismatches surface later as mangled characters.
5. Recreate cron jobs on the new host, and leave them disabled until cutover so nothing runs twice.
6. Test using a hosts file entry that points your domain at the new server from your own machine only. This exercises the real domain without affecting anyone else.

The cutover

Lower the time-to-live on the relevant DNS records a few days ahead, so that resolvers hold the old answer only briefly when you change it. Two to five minutes is a common working value during a migration window; restore a normal value afterwards.

On the day, put the old site into maintenance mode or make it read-only, run a final rsync to catch files changed since the last pass, export and import the database one more time, then update the A and AAAA records to the new address.

Expect a period where both servers receive traffic, because resolvers and intermediate caches do not all expire at once. This is why the old site should be read-only rather than simply switched off, and why the record mechanics in DNS setup for cloud servers are worth understanding before the day.

Keep the shared hosting account active for at least a full billing cycle afterwards. It is your rollback, your archive and your reference for anything you forgot to write down.

The first week on the new server

Three categories of problem surface after a move of this kind, and all three are easier to fix if you are watching for them.

The first is the missing piece: a cron job that was not recreated, a redirect rule that lived in the panel, or a file permission that differed. Check the web server error log daily for the first week.

The second is the version mismatch. A newer PHP release deprecating a function your theme relies on is the classic case, and it often shows up on one rarely visited page rather than on the homepage.

The third is the absence of the safety net the host used to provide. Set up automated backups on day one, with at least one copy outside the server, and enable unattended security updates. If the site is WordPress, the specific steps are covered in migrating WordPress to a cloud server.

Questions before you move

For provider references, see the DigitalOcean Droplet guides and the Hetzner server creation documentation.