How to Migrate Your Server with (Near) Zero Downtime

Server migration doesn’t have to be stressful. Whether you’re upgrading hardware, switching providers, or changing location, the process should be strategic, not risky.

Server migrations are necessary for any growing application to move to more powerful hardware, a better network, or a more strategic geographic location. However, this migration often requires some downtime to move things over successfully.

At RunCloud, we believe migrating your entire infrastructure shouldn’t be a gamble. It should be a strategic, controlled, and predictable process.

In this guide, we’ll provide you with step-by-step instructions for moving your servers with minimal, and in many cases, virtually zero, user-facing downtime.

Let’s get started!

Phase 1: Preparing For Server Migration

You might already know this, but the key to a successful migration is 90% preparation. Rushing this phase is the single most common cause of failure. Follow the steps below to start the migration process:

Configure DNS TTL

Your Domain Name System (DNS) records are the internet’s address book. When users type your-app.com, DNS tells their browser which server IP to connect to. Most computers store this information for an extended period to avoid making the same requests repeatedly. This isn’t a problem as these records are seldom updated. However, you will need to update these records when migration starts.

Therefore, at least one week before your planned migration, you must lower the Time-To-Live (TTL) value on your relevant DNS records (typically the ‘A’ record for your domain and subdomains). The TTL tells resolvers how long to remember the IP address before asking for it again. A standard TTL might be 24 hours; you want it as low as possible for a migration.

Set your TTL to the lowest value your provider allows. On platforms like Cloudflare, the minimum is 2 minutes (120 seconds). This ensures that when you finally “flip the switch,” the global change will propagate with incredible speed, minimizing the window where some users might still be directed to the old server.

For more information, we recommend reading our blog post, “How to Speed Up DNS Propagation”.        

Create New Server Environment

Before you can move your data, you must build an identical environment on the new server. This can sometimes take significant effort as manually installing nginx/Apache, multiple PHP versions, Redis, Supervisor, and editing configurations can be challenging.

This is precisely where RunCloud transforms a multi-day headache into a few clicks.

1. Provision Your New Server: Get a fresh server from your favorite provider (DigitalOcean, AWS, Vultr, etc.).
2. Connect to RunCloud: Instead of SSH’ing in and running complex setup scripts, you simply connect your new server to your RunCloud account. RunCloud automatically installs and configures a highly optimized server stack (your choice of nginx or OpenLiteSpeed, MariaDB, multiple PHP versions, Redis, Memcached, and more).

If you want step-by-step instructions for this process, refer to our help documentation article that outlines the getting-started process. Once the core server is ready, you will need to recreate the application-specific environments on the server.

If you have several web applications, manually creating each one, along with their specific PHP versions, system users, databases, and cron jobs, is tedious and prone to human error.

Using RunCloud, you can compile a complete list of your web applications, database names, and cron jobs. You can then loop through that list and execute API calls to replicate the entire structure on your new server.

If you want to learn more, refer to our official documentation, where we explore how to automate and build web applications with the RunCloud API.

Phase 2: Copying Files and Databases to the New Server

After creating a replica of your environment on the new server, it’s time to move the actual data.

Syncing Web Application Files with rsync

We have already written an in-depth article that explains 3 Free Ways To Migrate WordPress From Shared Hosting To Cloud Server, but if you are in a hurry, then you can use rsync, which is a powerful and versatile command-line utility designed for efficiently synchronizing files and directories between two locations.

Initial Sync: You will perform an initial, comprehensive sync of your web application files from the old server (Server A) to the new one (Server B). A typical command looks like this:

rsync -avz /old/path/ user@new-server-ip:/home/runcloud/webapps/my-app/

Let’s understand the different options in the above command:

• -a (archive mode): This option creates an archive of the source.
• -v (verbose): This flag tells rsync to give you detailed output. As it runs, it will list every file being transferred, which is extremely helpful for monitoring progress and diagnosing issues. You might remove this flag for a cron job to keep logs clean.
• -z (compress): This instructs rsync to compress the file data before sending it across the network. The destination server then uncompresses it. This significantly reduces network bandwidth usage and can dramatically speed up the transfer, especially for text-based files like code (PHP, HTML, CSS, JS).
• --delete (optional): This option is useful for creating a perfect mirror. It tells rsync to delete any file from the destination directory if that file does not exist in the source directory. This is essential for a clean migration, as it removes old temporary files, logs, or user-uploaded content that has since been deleted from the live site.

• The destination path: user@new-server-ip:/home/runcloud/webapps/my-app/ specifies where the files should be sent. It’s composed of these parts:
  • user: The username on the new server that has permission to write to the destination directory.
  • new-server-ip: The IP address (or a resolvable hostname) of the new server you are migrating to.
  • The colon (:) is the separator that divides the remote user/host information from the file path on that remote machine.
  • /home/runcloud/webapps/my-app/: This is the absolute path on the destination server where the files will be placed.

If your web application has frequent file uploads or changes, it is possible that its data will change by the time the migration is finished. In this case, you can set up a cron job on your old server to run this rsync command incrementally (e.g., every 5 or 10 minutes). rsync is incredibly efficient and will only transfer the files that have changed, keeping the new server’s content almost perfectly in sync with the old one.

Database Migration

This is the most sensitive part of the migration. A mistake here can lead to data loss. The goal is to get a live, real-time copy of the database running on the new server before the final cutover. The strategy you choose will depend entirely on the size of your database and how frequently it is updated.

Method 1: The Classic Dump and Import (For Simple Sites)

The simplest way is often the best for websites with minimal data or where content and user activity are infrequent. You can use the built-in mysqldump command to export your entire database into a single .sql file. You can then run the provided command on the new server to import this data.

This method is very useful if you have minimal data. To transfer the exported file, you can even use rsync to make a fast and reliable copy. This approach is perfectly acceptable when the risk of new data being written between the time you export and import the database on the new server is very low.

Method 2: Live Replication for Active, High-Traffic Sites

If you are running a busy e-commerce store or an active community forum, then the classic dump-and-import method might not be suitable. The database might get updated several times in the window it takes to move the SQL dump to the new server and restore it. This gap will inevitably lead to lost transactions and customer data.

A word of extreme caution: while you might be tempted to rsync your raw MySQL/MariaDB data directory, this is extremely dangerous for a live database and will almost certainly lead to corruption. Copying the core database files while the service is running will result in an inconsistent, broken state on the destination server.

The recommended method to migrate the database is by establishing Master-Slave (or Primary-Replica) Replication. This process creates a live, continuously updating mirror of your database on the new server. Here’s how it works conceptually:

1. Setup: Configure your old database server (Server A) as the “Master” and your new database server (Server B) as the “Slave”.
2. Initial Data Dump: You’ll take a consistent snapshot of the master database that captures the precise replication position from the server’s binary log.
3. Start Replicating: After importing this initial dump onto the slave server, you instruct it to connect to the master and begin replicating from the captured position. From this point forward, any change made to the database on Server A (new users, blog posts, sales orders) is automatically and instantly copied to the database on Server B.

This leaves you with a live, read-only, up-to-the-second copy of your production data on the new server.

The complete, step-by-step process of setting up database replication is a detailed technical procedure and is out of scope for this article. However, we strongly recommend you read:

• DigitalOcean’s documentation which explains how to set up replication in MySQL.
• The official Microsoft documentation if you are migrating from MySQL to SQL Server.

Database Migration for AWS Users

If your servers are within the AWS ecosystem, you can consider using the AWS Database Migration Service (DMS). It acts as an intermediary that connects to your source and destination databases. DMS handles the initial load and then captures ongoing changes (Change Data Capture – CDC) to keep the two in continuous sync.

Migrating Custom Configurations

After migrating the files, you need to check:

• If you have added a custom nginx include file to handle special redirects.
• If you modified your php.ini file to increase memory limits or execution times for a demanding script

These small, often-overlooked configuration files are the unique DNA of your server’s behavior; they are vital and must be moved to the new server to ensure your applications function correctly after the migration.

This is where the benefit of a standardized environment provided by RunCloud becomes incredibly clear.

On a manually configured server, these critical files can be scattered across numerous directories, making finding and backing them up a tedious and error-prone scavenger hunt.

RunCloud eliminates this chaos by providing a user-friendly GUI-based dashboard for all your custom configurations. This standardization makes your custom files easy to locate, backup, and copy to the identical path on your new server, guaranteeing a consistent environment and ensuring that the nuanced rules that make your application work perfectly are never left behind.

You can refer to the following documentation articles to quickly configure your new server environment and set custom configurations:

1. Changing PHP Memory Limit  
2. Enable or Disable PHP Functions
3. Set nginx Reverse Proxy
4. Configure CORS on NGINX
5. How to Configure nginx Log Rotation

RunCloud empowers you with the flexibility to manage your server through either our intuitive graphical dashboard for individual tasks or our powerful API for mass automation.

For example, changing a single site’s PHP version is a simple click in the dashboard, while using the API allows you to programmatically update the PHP version for all your applications at once, ensuring you always have the most efficient tool for the job.

Phase 3: Flipping the Migration Switch for a Seamless Cutover

If you have followed all the steps, the final switch should be simple and controlled if everything has been set up properly. Once you are ready to migrate, follow the steps below:

1. Initiate Maintenance Mode (Optional, But Recommended): Briefly put your application on the old server in “maintenance mode”. This prevents new data from being written in the final minutes before the switch, ensuring 100% data integrity. Read our article on How to Temporarily Disable Your Web App or Show a Maintenance Page to learn more. 
2. Perform a Final Sync: Run your rsync command one last time to catch any last-second file changes.
3. Promote the New Database: If replication is used, this is the most important step. You will stop the replication process and promote your “Slave” database on Server B to be the new “Master”. It is now the primary, writable database.
4. Update Application Configurations: Point your application’s configuration file to the new server to use the local database (localhost). At this point, you will ensure that the applications on the new server can use the new database to make requests.
5. The DNS Switch: Finally, you will need to go to your DNS provider (e.g., Cloudflare) and change the IP address in your ‘A’ record from the old server’s IP to the new server’s IP. After the DNS records are updated, your new website should be automatically visible to your visitors, as the new site’s maintenance mode was never enabled.
6. Verify: Thanks to your low TTL, the change should occur within minutes. Start testing your domain. Check that it resolves to the new IP and that the application is fully functional.
7. Decommission: Do not shut down the old server immediately! Leave it running for 24-48 hours as a safety net. Once you are confident that the new server is stable and handling all traffic, you can safely power down and delete the old server.

After Action Report

This article explains why server migration is a complex dance of DNS, environment replication, data synchronization, and precise timing. While the process requires careful planning, the right tools can eliminate most of the manual labor and risk.

RunCloud is designed to make this process easier.

We automate the most complex and error-prone aspects of server setup and configuration so that you can focus on your code. Here’s how:

• We provide a powerful API that allows you to script the recreation of your entire application infrastructure.
• We offer a stable, secure, and predictable environment in which you can confidently perform the sensitive data synchronization steps.
• We make it easy to test changes by creating a WordPress staging environment with a single click.

Want to make migrations less painful? Try RunCloud for easier, automated server management.

Frequently Asked Questions (FAQ) for Server Migration