How to Migrate Your Server with (Near) Zero Downtime

For more information, we recommend reading our blog post, “How to Speed Up DNS Propagation”.        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.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.⚠️ Word of Caution: Use the –delete flag with care. Always double-check that your source and destination paths are correct. If you accidentally reverse them, this flag would wipe out your source directory!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:

Phase 1: Preparing For Server Migration

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.

Configure DNS TTL

Lowering your DNS Time-To-Live (TTL) value a week before migration is an important preparatory step. A low TTL, such as 2 minutes, tells web browsers and resolvers to check for your server’s IP address more frequently, ensuring that when you finally point your domain to the new server, the change spreads across the internet rapidly.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: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. 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.

Create New Server Environment

Let’s get started!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.

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).

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.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.Exception for Cloudflare Proxy Users: It is important to note that if you are using Cloudflare’s orange-cloud proxy service (not the “DNS Only” grey-cloud mode), this step is unnecessary. Because all traffic is already routed through Cloudflare’s network, they control the IP change internally. When you update the IP in your Cloudflare dashboard, the change is virtually instantaneous for your users.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.

Phase 2: Copying Files and Databases to the New Server

While achieving zero downtime is technically challenging, a “near-zero” downtime migration is achievable with proper planning. By synchronizing files and databases in real-time before the final DNS switch and using a very low DNS TTL, the cutover period can be reduced to just a few minutes.

Syncing Web Application Files with rsync

This leaves you with a live, read-only, up-to-the-second copy of your production data on the new server.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.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.

• -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.

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.

Database Migration

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

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

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.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:

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.You can refer to the following documentation articles to quickly configure your new server environment and set custom configurations: rsync -avz /old/path/ user@new-server-ip:/home/runcloud/webapps/my-app/

No, you do not need to manually lower your DNS TTL if you use Cloudflare’s proxy service (the “orange cloud”). Because all your traffic is routed through Cloudflare’s network, they handle the IP address switch internally. When you update the IP in your Cloudflare dashboard, their system propagates the change to your users almost instantaneously.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:

Database Migration for AWS Users

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.

Migrating Custom Configurations

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.

• 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

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.RunCloud is designed to make this process easier.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.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: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.

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

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:Want to make migrations less painful? Try RunCloud for easier, automated server management.

Phase 3: Flipping the Migration Switch for a Seamless Cutover

RunCloud dramatically simplifies server migrations by automating the most tedious and error-prone step: setting up the new server. Instead of manually installing and configuring nginx, PHP, and databases, RunCloud provides an optimized, secure server that can be installed in minutes. Furthermore, its powerful API allows you to programmatically recreate all your web applications and cron jobs, saving dozens of hours of manual work.

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

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.This is precisely where RunCloud transforms a multi-day headache into a few clicks.After migrating the files, you need to check:

• 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.

The industry-standard tool for safely copying website files is rsync, a command-line utility that efficiently synchronizes directories. For a minimal downtime migration, you should perform an initial full sync and then set up a cron job to run rsync incrementally. This ensures that any last-minute file changes on the old server are automatically copied to the new server right up until the final cutover.

Frequently Asked Questions (FAQ) for Server Migration