How to Migrate a Website With Zero Downtime: A Step-by-Step Guide

A website migration does not have to mean taking your site offline. With the right preparation, you can build the new hosting environment while the current site remains live, test the replacement before sending visitors to it, synchronize the latest data, switch traffic carefully and retain the old environment as a rollback option. The key is to treat migration as a controlled infrastructure change rather than a simple file transfer.

The biggest challenge is not copying website files. It is keeping the new environment consistent with the live site while visitors continue creating data. A brochure website may need only a carefully timed DNS change, while an ecommerce store, membership platform or busy publishing site may require database replication, incremental file synchronization or a short write-freeze. Understanding that difference is what makes a migration genuinely low-risk.

What Does Zero-Downtime Migration Mean?

A zero-downtime website migration aims to move a site from one hosting environment to another without a planned period when visitors cannot access it.

There are two separate goals:

1. Availability: Visitors can continue accessing the website.
2. Data consistency: The new environment contains the latest website data.

A migration can succeed on the first point while failing on the second.

For example, suppose you copy an ecommerce database at 10:00. A customer places an order at 10:05. If the new database does not receive that order before traffic moves to the new server, the website may remain online while important data has effectively disappeared from the new environment.

That is why zero-downtime migration requires more than changing DNS.

How Website Migration Works Without Downtime

A typical migration follows this pattern:

Existing live website → build new environment → copy data → test destination → synchronize changes → switch traffic → monitor → retire old environment

The old website remains operational while the new one is prepared.

For more sophisticated applications, traffic can also be moved gradually:

100% old → 90/10 → 50/50 → 10/90 → 100% new

This allows the new environment to receive real traffic before the old infrastructure is completely removed.

1. Map Everything Before You Move

Start by documenting the current website infrastructure.

Identify:

• Web server
• CMS or application
• Database
• Uploaded files
• DNS provider
• Domain registrar
• CDN
• Email provider
• Payment systems
• External APIs
• Scheduled tasks
• Background workers
• Security services
• Monitoring
• Backups

Do not assume that everything associated with the website lives on the current hosting account.

For example, your domain may be registered with one company, DNS managed by another, email handled by Microsoft 365 or Google Workspace, and the website hosted somewhere else.

Moving the website does not necessarily mean moving all of those services.

2. Define Your Downtime and Data-Loss Tolerance

Before selecting a migration method, establish what the business can tolerate.

Two useful concepts are:

RTO — Recovery Time Objective: how long the service can be unavailable.

RPO — Recovery Point Objective: how much recent data could potentially be lost.

A personal blog might tolerate a few minutes of downtime.

An ecommerce store processing orders continuously may require a much tighter tolerance.

This distinction helps determine whether a conventional migration is sufficient or whether you need database replication and more advanced traffic management.

3. Create a Verified Backup

Never begin a migration without a recoverable backup.

Back up:

• Website files
• Database
• Configuration files
• Uploaded media
• Important application data
• Email, if hosted on the server

For a database-driven CMS, backing up only the files is not enough.

Verify the backup

A backup is not useful if it cannot be restored.

Check that:

• The backup completed successfully
• The archive can be opened
• The database export is readable
• Important files are present
• The backup is stored independently of the original server
• You know how to restore it

For a critical website, consider maintaining more than one recovery copy.

4. Lower DNS TTL Before Migration

DNS records include a TTL (Time to Live) value that determines how long DNS information can be cached.

Reducing the TTL before migration can help shorten the period during which some DNS resolvers continue using the previous destination.

A common approach is to reduce relevant records to around 300 seconds approximately 24–48 hours before the planned migration. SiteGround’s current migration guidance recommends this preparation for a planned DNS switch.

However, DNS propagation is not an exact countdown. Reducing TTL does not guarantee that every visitor will immediately use the new server after five minutes.

The purpose is to reduce caching time, not eliminate DNS propagation entirely.

5. Build the New Hosting Environment Before Switching Traffic

Do not take the current website offline to build its replacement.

Instead, provision the new server while the existing website continues serving visitors.

Configure:

• Operating system
• Web server
• Runtime
• Database
• Application
• SSL/TLS
• Firewall
• File permissions
• Environment variables
• Caching
• Scheduled jobs
• CDN
• Monitoring

The destination should be as close as possible to production before traffic is redirected.

6. Match the Required Software Environment

Check the compatibility between the existing website and the new server.

Depending on the application, this can include:

• PHP version
• MySQL or MariaDB version
• Node.js version
• Python version
• Required extensions
• Web-server configuration
• Database settings
• File permissions
• Operating-system dependencies

Do not assume that two hosting environments are interchangeable simply because both support the same CMS.

A plugin or application that works under one runtime version may behave differently under another.

7. Transfer the Website Files

Copy the website’s files to the new server.

Depending on the application, these can include:

• Core application files
• Themes
• Plugins
• Images
• Documents
• User uploads
• Configuration
• Custom scripts

For large websites, use a transfer method that can resume interrupted transfers and preserve file permissions where required.

Do not assume the first file copy will be the final one.

Files may continue changing while the old website remains live.

8. Transfer the Database

Export the existing database and import it into the new environment.

Then configure the application to connect to the new database.

Check:

• Database hostname
• Database name
• Username
• Password
• Port
• Character set
• Connection settings

Test real database operations rather than simply opening the homepage.

A successful database connection does not necessarily mean that every application query will work correctly.

9. Find Hardcoded References to the Old Server

Search for references to:

• Old IP addresses
• Old server paths
• Temporary hostnames
• Previous database names
• Old API endpoints
• Development URLs

A website can appear functional while quietly loading resources from the old server.

Check HTML, configuration files, application code, JavaScript, CSS and database content where appropriate.

10. Test the New Website Privately

Do not send public traffic to the destination until it has been tested.

Depending on your infrastructure, you can use:

• Temporary hostname
• Staging domain
• Hosts-file override
• Preview URL
• Private load balancer

Test the real application.

Test the important user journeys

• Homepage
• Navigation
• Internal links
• Search
• Contact forms
• Login
• Registration
• Password reset
• User accounts
• File uploads
• Downloads
• Shopping cart
• Checkout
• Payment processing
• Email notifications
• API integrations
• Administration

For an ecommerce site, complete a realistic test transaction rather than simply checking whether the checkout page loads.

11. Verify HTTPS Before Cutover

The new server should have working HTTPS before it receives production traffic.

Check:

• Certificate validity
• Correct domain name
• HTTPS access
• HTTP-to-HTTPS redirect
• Mixed-content errors
• Secure cookies
• Login pages
• Payment pages

Do not wait until the DNS change to discover that the SSL certificate has not been configured correctly.

12. Synchronize Files More Than Once

The first file transfer is usually only the initial copy.

If the live website continues receiving uploads, new files can appear after the first transfer.

A safer process is:

Initial transfer → website remains live → incremental synchronization → final synchronization → traffic cutover

This is particularly important for:

• Ecommerce websites
• Membership sites
• User-generated-content platforms
• Publishing sites
• Websites receiving file uploads

For high-volume systems, shared object storage can make the transition easier because both environments can access the same underlying files.

13. Solve the Database Synchronization Problem

This is where zero-downtime migrations become more technically demanding.

Suppose the production database is copied at 9:00.

At 9:15:

• A customer creates an account.
• Another customer places an order.
• An administrator publishes an article.

Those changes exist on the old database but not necessarily on the new one.

You therefore need a strategy for changes that occur after the initial database copy.

There are three common approaches.

Option 1: Briefly Freeze Writes

Put the application into maintenance or read-only mode during the final synchronization.

The sequence becomes:

1. Keep the website live.
2. Prepare the new environment.
3. Temporarily stop database writes.
4. Perform the final synchronization.
5. Switch traffic.
6. Re-enable writes.

This may cause a very short interruption to certain functions.

For many small and medium websites, it can be substantially safer than introducing complicated replication.

Option 2: Use Database Replication

Database replication keeps the destination database synchronized with the production database.

The general architecture is:

Production database → replication → new database

Once replication catches up, traffic can move to the destination.

This approach is more appropriate for applications where writes cannot reasonably be paused, but it requires expertise with the particular database system.

You need to monitor:

• Replication lag
• Failed transactions
• Data consistency
• Replication errors
• Failover behavior

Option 3: Use Dual Writes

Some architectures temporarily write data to both systems.

This can reduce the final cutover window but introduces significant complexity.

Potential problems include:

• Duplicate records
• Partial failures
• Conflicting updates
• Transaction inconsistencies
• Retry problems
• Ordering issues

Dual writes should be used only when the application architecture is designed to handle them safely.

14. Pay Attention to Uploaded Files

Database replication does not synchronize files.

A customer could upload an image or document to the old server after the initial file transfer.

If the new server does not receive that file, switching traffic can make it appear to have disappeared.

Use incremental synchronization or shared storage to ensure that newly created files reach the destination.

15. Control Cron Jobs and Background Workers

Running both environments simultaneously can create another problem: duplicate background tasks.

For example, if both servers execute a scheduled process that sends invoices, processes payments or sends emails, the same task could run twice.

Identify:

• Cron jobs
• Queues
• Workers
• Scheduled emails
• Payment processors
• Automated reports
• Data-processing tasks

Determine which environment is responsible for each process during migration.

In some architectures, it is safer to move background processing separately from the web servers.

16. Keep the Application Version Stable

A hosting migration is already a major change.

Avoid combining it with unrelated changes such as:

• Major CMS upgrades
• Website redesign
• URL restructuring
• Plugin replacements
• Database architecture changes
• Major application releases

If possible:

Migrate → stabilize → upgrade

If a new server requires a different software version, test that difference before the production cutover.

The fewer variables you change simultaneously, the easier it is to identify a problem.

17. Protect Email

Email is frequently overlooked during hosting migrations.

First determine where email is hosted.

If it is separate from the website, you may not need to move it at all.

If DNS is changing, carefully preserve:

• MX records
• SPF
• DKIM
• DMARC
• Mailbox records
• Forwarders
• Aliases

Test:

• Incoming email
• Outgoing email
• Website-generated messages
• Password-reset emails
• Contact-form notifications

A successful website migration that breaks business email is not a successful migration.

18. Review All DNS Records

Before changing DNS, export or document the current DNS zone.

Review:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF
• DKIM
• DMARC
• Subdomains
• Verification records

If you are moving only the website while retaining the current DNS provider, you may only need to change the web-related records.

If you are also moving DNS management, every required record must be recreated.

SiteGround’s migration guidance distinguishes between changing the A record when DNS remains with the existing provider and changing nameservers when DNS management itself is being moved.

19. Choose Between DNS and Traffic-Based Cutover

For many small websites, changing the relevant DNS record is sufficient.

For larger applications, you may have better control through:

• Load balancers
• Reverse proxies
• CDN routing
• Weighted traffic distribution
• Canary deployments

A gradual traffic migration might look like:

100% old → 90% old / 10% new → 50% / 50% → 10% old / 90% new → 100% new

This lets you monitor the destination with real users before fully committing.

It also gives you an opportunity to reverse traffic without changing the entire architecture again.

20. Perform the Final Synchronization

When the destination is ready, prepare for the cutover.

A typical sequence is:

1. Stop nonessential deployments.
2. Confirm backups.
3. Confirm monitoring.
4. Synchronize recently changed files.
5. Synchronize database changes.
6. Verify database consistency.
7. Confirm background-job behavior.
8. Confirm the destination is healthy.
9. Switch traffic.
10. Monitor immediately.

The exact process depends on whether you are using a write freeze, replication or another synchronization method.

21. Switch Traffic Carefully

For a DNS-based migration, make the planned DNS change after the final synchronization.

For a load-balanced architecture, gradually direct traffic toward the new environment.

Do not make unrelated changes at the same time.

If the website suddenly develops an error, a controlled migration makes it much easier to identify what caused the problem.

22. Monitor the New Server Immediately

The migration is not finished when DNS changes.

Watch:

• HTTP errors
• Application errors
• Database errors
• CPU
• Memory
• Disk space
• Response times
• Traffic
• Login failures
• Checkout failures
• Email delivery
• API failures
• Background jobs

Compare the new server with the old environment where possible.

A homepage that loads successfully is not enough evidence that the migration is complete.

23. Keep the Old Hosting Environment Running

Do not immediately cancel the old hosting account.

DNS propagation means some visitors may continue reaching the previous server for a period after the change.

Keeping the old environment available gives you:

• A rollback option
• Access to the original data
• A comparison point
• Protection against unexpected DNS behavior

SiteGround currently recommends keeping the old environment available for at least 48–72 hours during migration.

For a high-traffic or business-critical application, retaining it longer may be appropriate.

24. Define Your Rollback Conditions

Decide before migration what would cause you to reverse the cutover.

Examples include:

• Widespread HTTP 500 errors
• Broken checkout
• Failed authentication
• Missing customer data
• Database corruption
• Critical payment failures
• Major email problems
• Broken third-party integrations

Your rollback procedure should be documented and tested where practical.

Do not invent a recovery strategy while the website is already experiencing an outage.

25. Check SEO After Migration

If the domain and URL structure remain unchanged, a hosting migration generally does not require a URL migration.

Still verify:

• HTTPS
• Canonical URLs
• Robots.txt
• XML sitemap
• Internal links
• Redirects
• Analytics
• Search-console configuration
• Crawlability

Avoid changing URLs during a hosting migration unless there is a strong reason.

If URLs must change, treat that as a separate SEO migration and map the old URLs to the appropriate new destinations using permanent redirects.

26. Verify the Live Website

After traffic moves, test the public website rather than relying on the staging environment.

Check:

• Homepage
• Representative pages
• Forms
• Login
• User accounts
• Search
• Media
• Downloads
• Checkout
• Payments
• Email
• API integrations
• Administrative functions

Test from different networks where practical because DNS resolution can vary between providers and locations.

27. Confirm Data Integrity

For database-driven websites, confirm that the destination contains the latest information.

Check appropriate indicators such as:

• Recent orders
• Recent registrations
• Recent articles
• Recent comments
• Recent uploads
• Inventory
• User profiles

For transactional applications, data integrity should receive as much attention as uptime.

28. Confirm Backups on the New Host

Once the new environment is live, verify that its backup system is working.

Do not assume that backups transferred automatically with the website.

Confirm:

• Backup frequency
• Retention
• Storage location
• Database coverage
• File coverage
• Restoration procedure

A successful migration should leave you with a recoverable new environment, not just a working website.

Zero-Downtime Website Migration Checklist

Before migration

• [ ] Map the complete architecture
• [ ] Identify all databases and file stores
• [ ] Identify all write operations
• [ ] Identify cron jobs and background workers
• [ ] Document DNS
• [ ] Document email
• [ ] Document third-party services
• [ ] Create verified backups
• [ ] Define rollback conditions
• [ ] Lower DNS TTL in advance
• [ ] Confirm the destination supports the application

Build the new environment

• [ ] Provision the new server
• [ ] Install compatible software
• [ ] Transfer website files
• [ ] Transfer the database
• [ ] Configure application credentials
• [ ] Configure SSL/TLS
• [ ] Configure security controls
• [ ] Configure monitoring
• [ ] Test the application privately

Synchronize data

• [ ] Perform an initial file synchronization
• [ ] Perform an initial database migration
• [ ] Identify changes occurring after the initial copy
• [ ] Configure replication or incremental synchronization if necessary
• [ ] Synchronize newly uploaded files
• [ ] Control background jobs
• [ ] Confirm database consistency

Cut over

• [ ] Confirm backups
• [ ] Stop nonessential deployments
• [ ] Perform final synchronization
• [ ] Confirm destination health
• [ ] Switch DNS or traffic routing
• [ ] Monitor immediately
• [ ] Test critical user journeys
• [ ] Keep the old environment online

After migration

• [ ] Monitor errors
• [ ] Monitor performance
• [ ] Verify email
• [ ] Verify payments
• [ ] Verify scheduled jobs
• [ ] Verify analytics
• [ ] Verify SEO settings
• [ ] Confirm backups
• [ ] Confirm data integrity
• [ ] Wait for sufficient DNS propagation
• [ ] Retire the old server only after verification

When You Shouldn’t Overcomplicate the Migration

True zero-downtime architecture is not necessary for every website.

A small informational website with no user accounts, transactions or frequently changing data may be safely migrated with a short maintenance window.

For example:

Backup → copy files → copy database → test → brief maintenance mode → final synchronization → DNS change → verify

That may be safer than implementing database replication solely to eliminate a few seconds of interruption.

The appropriate migration strategy depends on the consequences of downtime, the frequency of data changes and the technical complexity of the website.

Choosing the Right Migration Method

There is no universal migration method that is appropriate for every website.

Using a Managed Hosting Migration Service

Managed hosting providers can simplify some of the mechanical work involved in moving a website.

For example, SiteGround provides a WordPress Migrator for eligible WordPress transfers and also documents manual migration procedures for sites requiring greater control.

Migration tools can help transfer files and databases, but they do not eliminate the need to test DNS, email, payment systems, third-party integrations, scheduled jobs and application-specific functionality.

If you are choosing a destination host, you can also review the current SiteGround hosting offers and compare the migration, backup and hosting features included with the plans available to you.

The Key to a Successful Zero-Downtime Migration

A zero-downtime migration is fundamentally a controlled transition between two environments.

The new server should be built before production traffic is moved. The application should be tested while the old website remains live. Files and databases need a strategy for handling changes that occur during the migration. DNS and email must be treated as separate dependencies, and background jobs must be prevented from running twice.

For a simple website, that may mean a carefully planned short maintenance window. For a transactional application, it may require database replication, shared storage and gradual traffic routing.

The most important principle remains the same: build first, test thoroughly, synchronize the latest changes, switch traffic deliberately, monitor continuously and keep the old environment available until the new one has proved reliable under real-world traffic.