Migrating Your Website or Server to the Cloud: Step by Step

You've decided to migrate. The strategy is set, the provider chosen. Now it's time to execute. Because the difference between a migration that goes smoothly and one that ends in a weekend of panic isn't about technology. It's about preparation.

This article is a practical guide. No abstract frameworks, just concrete steps. What to do first, what to do next, and where things go wrong when you skip steps.

Step 1: Take inventory of what you have

Before you move anything, create a complete inventory. Sounds obvious, yet it's the step most often skipped. The result: halfway through the migration you discover a database you forgot about, a cronjob nobody remembers, or an integration with an external system that was never documented.

What to map out:

Applications and services. Which websites, applications, APIs and background processes are running? On which servers? With which versions of which software? Also document the web server (Apache, Nginx, IIS), the programming language and framework, the database server and version, and any caching layers (Redis, Memcached, Varnish).

Data. How much data do you have? Where is it stored? Databases, files, media, backups, logs. What's the total size, and what's the daily growth? This determines how long a data migration takes and which method you'll use.

Dependencies. Which systems communicate with which other systems? External APIs, payment providers, email servers, DNS, CDN, monitoring. Draw it out. You don't want surprises the moment you switch DNS.

Configuration. Server settings, environment variables, SSL certificates, firewall rules, scheduled tasks. Everything that's not in your code or database but is needed to make your application work.

Step 2: Prepare the target environment

Set up your new environment before you start moving data. Install the correct software versions. Configure the web server. Set up firewall rules. Create database servers. Configure SSL certificates.

Test the target environment with a minimal version of your application. Does the software run? Are permissions correct? Can the application connect to the database? Does email functionality work? Fix problems before you start the data migration. Every minute you spend now on properly setting up the target environment saves you three times that during the migration itself.

A point often forgotten: time settings. Check that your new server's timezone matches what your application expects. A one-hour difference can cause cronjobs to start at the wrong time and timestamps in your database to display incorrectly.

Step 3: Back up everything

Create a complete backup of your current environment. Not just the database, not just the files, but everything. Database dumps, application files, media uploads, configuration files, SSL certificates, cronjob definitions, firewall rules.

Store this backup in a location that's independent of both your old and new environment. An external storage service, a local drive, a second server. If both the migration and the rollback fail, this backup is your last resort.

Verify your backup. A backup you haven't tested isn't a backup, it's an assumption. Restore the database dump to a test environment. Check that files are complete. Verify integrity with checksums.

Step 4: Lower your DNS TTL

This is a step you need to take at least 24 to 48 hours before the actual migration. DNS records have a TTL (time to live): the time DNS resolvers cache the record before querying it again. A standard TTL is often 3600 seconds (one hour) or longer. Some domains are set to 86400 seconds (24 hours).

Lower the TTL to the minimum your provider allows. At Cloudflare that's 120 seconds. At most registrars 300 seconds (5 minutes) is achievable. Do this well in advance, because the old TTL needs to expire before the new value takes effect.

Why this matters: at the moment you change DNS to your new server, you want all visitors to reach the new server as quickly as possible. With a 24-hour TTL, visitors can still end up on your old server up to a day after the switch. With a 5-minute TTL, that window is five minutes.

Step 5: Migrate your data

Now the actual move begins. The method depends on the amount of data and the type of application.

Files. For websites and applications with file storage (media uploads, documents, configuration), rsync is the standard. It only copies changed files, making repeated synchronization fast. You can run rsync before the actual migration starts: a first sync copies everything, and just before the DNS switch you run a final sync to capture recent changes.

Databases. For MySQL and MariaDB, mysqldump is the most common method. For large databases (tens of gigabytes), mysqldump is slow. Consider mydumper for parallel dump and restore, or use physical backup methods if the database version on source and destination is identical. PostgreSQL users have pg_dump and pg_restore.

For applications with active users, the synchronization timing is critical. Between your last database export and the DNS switch, no write operations should occur on the old database. The cleanest approach: put the old application in maintenance mode temporarily, export the database, import on the new server, test, and only then switch DNS.

Step 6: Test on the new environment

Your data is on the new server. The application is running. But DNS still points to the old server. That's exactly what you want: you can now test without visitors seeing the new environment.

The easiest way to test is via your local hosts file. Add a line that points your domain name to the IP address of the new server. On macOS and Linux that file is at /etc/hosts, on Windows at C:\Windows\System32\drivers\etc\hosts. Now you reach the new server via your browser while the rest of the world still goes to the old one.

What to test:

• Does the website load correctly?
• Do all pages work?
• Are images and files available?
• Does the contact form work?
• Are emails being sent?
• Does the payment module work?
• Is the database data correct?
• Are scheduled tasks set up?
• Does the SSL certificate work?
• Is HTTP correctly redirected to HTTPS?

Also test performance. Compare load times with the old environment. If the new server is in a different data center, latency to external services changes. Database queries that were fast locally may become slower if the distance is greater.

Step 7: Switch DNS

Everything has been tested. The new environment works. Now the moment of truth: the DNS switch.

Change the A record (or AAAA record for IPv6) of your domain to the IP address of the new server. If you lowered the TTL in step 4, most visitors should reach the new server within five to ten minutes.

Don't shut down the old server immediately. Keep it running for at least 48 to 72 hours. DNS propagation isn't instant and isn't uniform. Some ISPs ignore TTL values and cache longer. As long as there's a chance visitors reach the old server, that server should still show a usable version of your site. If needed, put up a maintenance page with a link to the new address.

For websites with active write operations (webshops, forums, CMS with multiple editors), it's wise to put the old application in read-only mode after the DNS switch. This prevents data being written to the old database that's no longer being synchronized.

Step 8: Monitor and clean up

The first 72 hours after migration are the most important. Actively monitor for errors: 500 errors in your server log, slow queries in your database, failed cronjobs, bouncing emails. Set up alerts for downtime.

Check your search engine traffic. A migration can temporarily affect your SEO if URL structures have changed or if the server responds more slowly. Monitor Google Search Console for crawl errors.

If everything runs stable after 72 hours:

Restore your DNS TTL to the normal value (usually 3600 seconds). Shut down the old server. Keep your pre-migration backup for at least 30 more days. Document the migration: what did you do, what problems did you encounter, what would you do differently next time.

Specific scenarios

Migrating WordPress

WordPress is by far the most migrated platform. The basics: export the database (wp_options contains your site URL, which you need to adjust), copy wp-content (your themes, plugins and uploads), and make sure PHP version and extensions match. Plugins like Duplicator or All-in-One WP Migration can simplify the process, but for large sites (more than a few gigabytes of media) you'll hit upload limits and manual migration is more reliable.

Pay specific attention to: wp-config.php (database connection and salts), .htaccess (rewrite rules), and any server-level caching configuration. After migration: re-save permalinks (fixes most 404 errors) and clear all caches.

Migrating a webshop

Webshops have an extra complication: ongoing orders and payments. Plan the migration outside peak hours (Tuesday night or Wednesday night are typically the quietest). Put the shop in maintenance mode before doing the final database sync. After migration, verify that the payment provider is correctly configured on the new environment: webhook URLs need to point to the new IP, and some payment providers (Mollie, Stripe, Adyen) validate the SSL certificate of the webhook URL.

Multiple sites on one server

If you have multiple websites on a server, don't migrate everything at once. Move the least critical site first. Learn from the experience. Adjust your process. Then move the next one. It's tempting to do everything in one go, but risk multiplies with every site you add to the migration window.

The core message

A migration isn't a technical stunt. It's a structured process of eight steps, half of which is preparation. Those who take preparation seriously end up with a migration that has minimal downtime, no data loss, and no surprises on Monday morning.

The technical steps are documented and proven. What makes them succeed isn't technical brilliance but discipline: inventorying what you have, testing before you switch, monitoring after you switch, and always having a rollback plan.