Move the website without unnecessary downtime: A practical plan for changing hosting environments

Category: Hosting & operations

Moving a website to a new hosting environment is not just a matter of copying files and changing DNS. The website may have forms, an online store, integrations, scheduled tasks, caching, email delivery and security rules that must work in the same way after the move. If one dependency is overlooked, the website may appear correct while important functionality has stopped working.

That is why a hosting change should be treated as a controlled production change. The goal is not merely to achieve the shortest possible downtime. The goal is a move where you know what is going to happen, how the result will be checked and when to revert to the old environment.

Start by mapping what actually needs to be moved

Before choosing a method and timing, you need to understand the solution. A simple business website can often be moved in one coordinated process. An online store or membership service will typically require a plan for data that changes while the move is underway.

The mapping should cover at least:

• website files, database and uploaded media
• domains, subdomains and DNS records
• SSL certificates and redirects
• caching layers, CDN and any firewall rules
• forms, email delivery and external integrations
• scheduled tasks and automatic imports or exports
• access to databases, the file system and administration
• requirements for PHP, database, server modules and storage capacity

The mapping also identifies who needs to be involved. This may include a web agency, internal IT, the DNS administrator, the hosting provider and integration vendors. Named individuals and clear timings are better than discovering during the move that only one employee can approve a necessary change.

Build the new environment before switching traffic

The new hosting environment should be set up and tested while the old one is still in production. This allows you to investigate errors without affecting visitors.

The environment should match the production setup you actually need, not merely be capable of displaying the homepage. Check software requirements, database settings, file permissions, storage capacity, time settings, email configuration and scheduled tasks, among other things. If the solution uses server-specific caching or image processing, this must also be verified.

The website can be tested in the new environment by directing traffic locally from a test machine. This allows the tester to open the usual domain against the new server without changing public DNS. This is often more reliable than testing on a temporary address, because some solutions behave differently when the domain changes.

Test more than the visual appearance

A quick review of the pages is necessary, but not sufficient. Test specific user tasks:

• submit all important forms and verify receipt
• log in using relevant user roles
• complete a test purchase if the website has an online store
• check search, filtering and file downloads
• trigger relevant emails and notifications
• test integrations with accounting, CRM or specialist systems
• check that redirects and error pages work

Also check the logs for errors that are not visible in the browser. A page may be displayed even when background jobs, API calls or email delivery fail.

Decide how to handle fresh data

The most difficult part of a move is often the data generated after the first copy has been made. New orders, forms, comments, user registrations and editorial changes may end up in the old environment while the new one is being prepared.

For a website with few changes, you can agree on a short content freeze. Editors refrain from publishing, and the final database is copied just before traffic is switched. For solutions with ongoing transactions, you must consider a short maintenance period or a controlled final synchronization.

Do not rely on manually merging two databases afterwards. Conflicts may arise between identifiers, relationships and timestamps. Decide in advance which environment is authoritative at each stage, and agree on a clear time when writing to the old environment will stop.

Prepare DNS, CDN and certificates

The DNS change determines where traffic is sent, but it does not move the website itself. Before the switch, relevant DNS records and their caching times should be reviewed. A shorter TTL can help the change propagate faster, but it must be adjusted well in advance of the move to have the desired effect.

At the same time, check how the CDN is configured. If the CDN continues to retrieve content from the old server, users may receive a mixture of old and new content. The origin server, cache rules and cache purging must therefore be included in the runbook.

SSL must be ready in the new environment before traffic arrives. Test both the main domain and any other hostnames that should be available. Redirects from unencrypted to encrypted traffic should also be checked, along with any security rules that restrict which services can access the server.

Create a runbook with checkpoints

On moving day, the team should follow a written, time-based runbook. It does not need to be extensive, but each step should have a person responsible, an expected result and a way to verify that result.

A typical sequence might be:

1. Confirm that the backup is complete and that the necessary access works.
2. Stop publishing and other write operations in the old environment.
3. Take a final copy of the database and new files.
4. Import the data and perform the necessary technical adjustments.
5. Carry out a brief functional test directly against the new environment.
6. Change the DNS and update the CDN if necessary.
7. Clear relevant caches in the correct order.
8. Check the website from multiple networks and devices.
9. Activate monitoring and track logs, response times and errors.
10. Reopen for editing and transactions.

Add checkpoints before irreversible or high-risk steps. If the final synchronization fails, do not change the DNS simply because the scheduled time has passed.

Define the rollback plan before the migration begins

A rollback plan must describe more than the ability to point the DNS back. If new orders or enquiries have already been registered in the new environment, returning to the old one could result in data loss.

Therefore, agree on which errors trigger a rollback, who makes the decision, and for how long it is practical to revert. Critical errors may include unavailable payment processing, failed logins, extensive server errors or loss of new data. Minor visual discrepancies can often be fixed after the migration is complete.

The old environment should be kept unchanged for an agreed period, but protected against new write operations once it is no longer the production environment. This gives you a basis for comparison without creating two active versions of the same solution.

Monitor the entire user journey after the switch

A simple uptime check can confirm that the server responds, but not that the website works. After the migration, monitoring should cover key pages and actions. Monitor response times, server errors, database errors, failed background jobs and deviations in traffic or conversions.

The first few hours require closer monitoring. After that, checks should be repeated on the next working day and after scheduled daily or weekly jobs have run. It is common for errors to become visible only when an import starts, a certificate is due for renewal or an email queue is processed.

Also check backup jobs in the new environment. A message stating that backup is configured is not the same as confirmation that the correct files and databases are actually being stored. Look for completed runs, the expected data volume and the correct storage destination.

Finish with cleanup and a new operational baseline

Once the migration has been confirmed as stable, remove old access credentials, temporary test addresses and unnecessary DNS records. Update the operational documentation with server information, points of contact, backup configuration, monitoring, maintenance procedures and responsibilities.

At the same time, use the migration to establish a new baseline. Record normal response times, resource usage, cache hits, storage consumption and expected traffic. This makes it easier to detect deviations later and assess whether the operating environment has the right capacity.

A successful hosting migration is characterized by more than the homepage loading. Forms are delivered, transactions are stored, integrations run, the cache and CDN display the correct content, monitoring sends alerts as planned, and operational responsibility is clear after the project has been completed.