Migrating from shared hosting to a cloud server

Shared hosting eventually stops fitting: the site outgrows the resource limits, you need software the host does not offer, or you want control the control panel does not give.

The migration itself is not difficult. What causes problems is doing the steps in the wrong order, particularly anything involving DNS.

Before you touch anything

Inventory what you actually have. Shared hosting accumulates things quietly. Beyond the obvious website and database, look for: scheduled tasks, mailboxes and forwarding rules, additional domains and subdomains, custom rewrite or redirect rules, TLS certificates, FTP accounts, and any secondary applications installed years ago and forgotten.

The commonest migration failure is discovering a week later that something nobody remembered was running on the old host.

Note your runtime versions. The exact language version, the installed extensions, the database version. Building the new server on different versions is a legitimate choice but should be deliberate, not a surprise found during cutover.

Check where mail is handled. If the shared host also handles your email, that is a separate migration with its own risks, and the MX records must be considered independently from the website. Many people move the site, point DNS at the new server, and stop receiving mail because the MX records went with it.

Lower the DNS TTL first

Before anything else, reduce the TTL on the records you will change to five minutes, and wait for the previous TTL to expire.

This is the step that determines how quickly you can complete the cutover, and how quickly you could reverse it. Doing it at the moment of migration is useless, because the old long-lived values are already cached across the internet.

If the current TTL is a day, do this a day in advance. It costs nothing and it is the difference between a five-minute cutover and one that trails for a day.

Build the new server

Provision it, harden it, and install the stack. Match or deliberately update the runtime versions you noted.

Configure the web server with your domain, and get the application running against a copy of the data. Test it thoroughly using a hosts file entry on your own machine, which lets you browse the real domain against the new server without changing anything publicly.

That hosts file trick is the single most useful technique in this whole process. It gives you a genuine test of the production configuration, with the real domain name, before any user is affected.

Move the data in two passes

First pass, well ahead of cutover. Copy the files and import a database dump. Test everything against this copy. Fix what is broken. This pass is not time-sensitive, and doing it early surfaces the problems while you have time.

Second pass, at cutover. Put the old site into a read-only or maintenance state if you can, take a fresh database dump, sync the files that have changed since the first pass, and import.

The two-pass approach means the cutover window contains only a small delta rather than the whole migration, which usually reduces it from hours to minutes.

Certificates before the switch

Obtain a certificate for the new server before pointing DNS at it. Automated certificate issuance validates over the domain, which normally requires the domain to point at the server, creating a chicken-and-egg problem.

The way around it is DNS-based validation, which proves control of the domain by publishing a record rather than by serving a file. This lets you have a valid certificate ready before any traffic moves, so there is no window where visitors see a warning.

Cut over, then watch

Change the DNS record. With a five-minute TTL, most traffic moves within minutes.

For a period both servers may receive requests as caches expire. This matters if the site accepts writes, because writes landing on the old server will be lost. Keeping the old site read-only during the transition avoids the problem entirely.

Then watch: error logs on the new server, the application’s own error tracking, and a check that the important pages actually work. Test the paths that are easy to forget: form submissions, file uploads, scheduled tasks, and anything that sends mail.

Keep the old host for a fortnight

Do not cancel immediately. Keep it long enough to be confident, which usually means a couple of weeks, and long enough that any monthly scheduled task has run at least once on the new server.

Before cancelling, take a full copy of everything, including the things you did not migrate. It is remarkable how often something turns out to have been needed after all.

The things that most often break

• Mail, because the MX records were changed along with the website records.
• File permissions, because the shared host ran everything as one user and the new server does not.
• Hardcoded absolute paths in configuration, pointing at the old host’s directory structure.
• Scheduled tasks that nobody migrated, discovered when a report does not arrive.
• A different runtime version changing behaviour subtly.
• Missing extensions that the shared host had enabled by default.
• Certificate renewal never being configured on the new server, failing silently after ninety days.

Every one of these is found by testing thoroughly before cutover, which is the argument for the hosts file approach and the two-pass data move.

Where you run this matters less than how, but if the provider is still open, the cloud account catalogue compares the options side by side.

For the vendor’s own reference on the services involved here, see the Kamatera support library.

Independent sizing is easier to understand once you have set it yourself. Our Kamatera accounts come in two configurations, and the cloud account catalogue compares the other nine providers.

Questions people ask