How to Migrate Website Server Without Downtime

Published on July 15, 2026

Start the migration with a full, restorable backup and a written cutover plan. That is the safest answer to how to migrate website server infrastructure without turning a routine move into an outage. Your new server should be built, secured, and tested before DNS points any visitors toward it. The old server stays online until the new environment has passed real checks.

A server migration is more than copying website files. The website, database, scheduled tasks, mail routing, SSL certificates, application runtime, cache behavior, DNS records, and firewall rules may all be part of the service. Missing one small dependency is how a site can look fine on the homepage while checkout emails, forms, or background jobs quietly fail. Not a very glamorous failure, but still a costly one.

Map the current server before you move it

Begin with an inventory of what is actually running. Do not rely only on what the hosting control panel shows. Check the document root, application version, database engine and version, PHP or Node.js settings, cron jobs, queue workers, storage paths, redirects, environment variables, and outbound email configuration.

For a business website, also identify anything outside the main domain. This can include subdomains, staging sites, API endpoints, payment callbacks, object storage, third-party email providers, analytics scripts, and DNS records used for verification. If the server sends mail directly, record its sending IP, reverse DNS setup, SPF, DKIM, and DMARC records. Email is often the last item noticed and the first item customers complain about.

Document the current server's resource use as well. Review CPU load, memory consumption, disk space, database size, traffic patterns, and error logs. This tells you whether the new VPS or dedicated server is correctly sized. A migration is a useful moment to leave behind an undersized disk, an outdated PHP version, or a server that has been surviving mainly through optimism.

Prepare the new environment first

Provision the destination server before copying production data. Apply operating system updates, create restricted administrative access, configure the firewall, and install only the services the site needs. Use SSH keys rather than password-only access where possible. Disable unnecessary services and ensure automatic security updates match your operational policy.

Match the application requirements carefully. A site moving from PHP 7.4 to PHP 8.3, or from MySQL to a newer MariaDB release, may need code changes before it will behave correctly. The same applies to web server configuration. Apache rewrite rules, Nginx locations, file permissions, and PHP extensions do not always translate one-to-one.

Set up monitoring before the cutover, not after an incident. Watch availability, response time, CPU, memory, disk utilization, SSL expiration, and key service ports. For applications with background processing, monitor queue depth and failed jobs too. With managed infrastructure and monitoring in place, the logs are telling the same story now, rather than leaving you to guess after visitors report a problem.

Back up for recovery, not just for comfort

Create a fresh backup immediately before the migration window. It should include website files, databases, configuration files, user-generated uploads, and any application secrets stored outside the web root. Verify that the backup can be restored to a separate location. A backup that has never been tested is a hopeful archive, not a recovery plan.

For databases, use a consistent export. Large or active databases may require special handling to avoid copying data while it is changing. Depending on the database and application, you may use a maintenance window, a read-only mode, replication, or a final incremental synchronization. E-commerce stores, booking systems, SaaS products, and membership sites need particular care because orders and account changes can arrive every minute.

Keep the original server unchanged during the move. Do not cancel it or wipe data as soon as files appear on the destination. Retaining the old environment gives you a clean rollback path if a hidden dependency appears after the switch.

Transfer files and databases in stages

Copy the initial data set while the existing site remains live. Secure file transfer tools such as rsync over SSH are useful because they can synchronize only changed files during a later final pass. For databases, import the initial dump into the new server, then test the application against it using a temporary hostname or a local hosts-file override.

Avoid testing only the front page. Log in as an administrator and as a regular user. Submit a contact form, reset a password, upload a file, make a test purchase if appropriate, review transaction emails, and confirm scheduled tasks are operating. Check application logs and web server error logs while testing. A successful HTTP 200 response is not proof that the service is healthy.

If you are changing server architecture at the same time, isolate the changes where possible. For example, moving to a new VPS is enough work without also redesigning the database, replacing the caching layer, and upgrading the application framework in one evening. Separate projects make failures easier to diagnose and rollback.

Lower DNS TTL before the cutover

DNS is where a technically successful migration can become confusing for visitors. Reduce the TTL for the relevant A, AAAA, CNAME, and mail-related records 24 to 48 hours before the planned switch. A lower TTL encourages resolvers to refresh records faster once you point the domain to the new server.

This does not guarantee that every resolver will update instantly. Some networks cache longer than requested, and users may have local DNS caching. Plan for a transition period where a small portion of traffic can still reach the old server. If the site accepts changing data, you need a strategy for that overlap. A maintenance mode during the final sync is often safer than accepting new orders on two separate servers.

Do not alter nameservers unless there is a reason to move DNS hosting too. Changing authoritative nameservers adds another layer of propagation and more records to validate. Keep the migration boring where you can. Boring infrastructure is usually healthy infrastructure.

Execute the final sync and switch traffic

At the agreed cutover time, place the application in maintenance mode if it writes customer data. Stop queue workers and scheduled tasks on the old server so they cannot process the same task twice. Run the final file synchronization and database export/import, then update the destination configuration with the production database credentials, application keys, and correct URLs.

Enable the application on the new server and update DNS to its IP address. Confirm the SSL certificate is installed and that HTTP redirects to HTTPS correctly. If a load balancer, CDN, or proxy sits in front of the site, update its origin configuration and verify that it recognizes the new server's health checks.

Watch both servers during propagation. The new server should show incoming requests, while the old server should receive steadily less traffic. Review 404, 500, and permission errors, as well as application-specific alerts. Keep an eye on resource use because a new server can behave differently under real traffic than it did in testing.

Validate the service after migration

Once traffic is arriving at the new environment, perform a focused production check. Confirm the main pages load, users can authenticate, forms deliver, payment or booking flows work, dashboards display current data, and uploaded files are accessible. Test from more than one network if possible, since your own computer may still have cached DNS.

Check scheduled activity over the next several hours. Cron jobs, backups, renewals, reports, queue workers, and webhook receivers frequently expose migration issues after the initial validation has passed. Review mail logs and delivery reports as well. If the site uses a remote SMTP service, confirm the new server's IP or hostname is authorized.

Leave the old server available for at least 48 to 72 hours, longer for complex applications or slow DNS environments. During that period, preserve backups from both sides and do not make unrelated configuration changes. Once monitoring is clean, traffic is stable, and the rollback window has passed, decommission the old server securely.

Know when to use managed help

A simple brochure site can usually move with careful preparation and a short maintenance window. A high-traffic store, agency portfolio with many client sites, SaaS platform, or server with custom services deserves a more controlled plan. Database replication, staged releases, traffic draining, and active monitoring reduce risk, but they also need experienced hands.

kodu.cloud can assist with the operational side of a migration, from destination server preparation and backups to monitoring and validation. The goal is not to make the process mysterious. It is to ensure someone is watching the infrastructure while you keep the business moving.

A good migration ends quietly: visitors use the site, scheduled jobs run, backups complete, and nobody has to send a nervous all-hands message. Keep the plan, the backup, and the old server until the evidence says the service is calm again.

Andres Saar Customer Care Engineer