Most website and application migrations are not hard because of the technology. They are hard because the old environment has accumulated years of undocumented decisions: a cron job someone added in a hurry, a mail forwarder that a sales team depends on, a hardcoded IP address in a payment callback.
This guide describes a migration method that keeps downtime in the range of minutes, not hours, for typical web stacks: content sites, ecommerce stores, customer portals and line-of-business applications running on shared hosting, a single VPS or an aging physical server.
What minimal downtime actually means
Zero downtime is possible, but it usually requires an application that can run in two places at once against a shared or replicated database. Most legacy stacks cannot. A more honest target is a short, scheduled write freeze: the period between stopping writes on the old system and accepting writes on the new one. For a site with a few gigabytes of data and a well rehearsed plan, that window is commonly 5 to 30 minutes.
Define the target in writing before any work starts. State the maximum acceptable write freeze, the maximum acceptable data loss (ideally none), and the time of day with the lowest traffic.
Build a complete inventory first
The inventory is the single best predictor of a clean migration. Collect it from the running system, not from memory or old documentation, and assign an owner to each item.
- Domains and DNS. Every domain and subdomain, the registrar, the authoritative DNS provider, and a full export of current records, including TXT records used for verification.
- Applications and runtimes. Language versions (for example PHP 8.1 versus 8.3), web server and modules, extensions, Composer or npm dependencies, and any compiled binaries.
- Data stores. Database engines and versions, database sizes, file storage paths and sizes, object counts, and session or cache stores.
- Scheduled and background work. Cron entries, queue workers, backup scripts and any job that runs under a specific user account.
- Integrations. Payment gateways, webhooks, SMTP relays, APIs that allowlist your outbound IP address, and SSO or LDAP connections.
- Certificates and secrets. TLS certificates and their renewal method, API keys, environment files and credentials stored in configuration.
- Email. Mailboxes, aliases, forwarders, distribution lists, mailbox sizes and the clients people use to connect.
First, search the codebase and configuration for hardcoded IP addresses and absolute file paths. Second, review outbound connections over a normal business day (with a tool such as ss or netstat, or firewall logs) to find integrations no one remembered.
Prepare DNS and timing
DNS caching is the main reason users keep reaching the old server after cutover. If your A record has a TTL of 86,400 seconds (24 hours), some visitors may hit the old IP address for a full day after you change it.
Lower the TTL on every record you plan to change to 300 seconds, and do it at least one full old TTL before cutover, preferably 48 hours ahead. Some resolvers and corporate proxies do not honor short TTLs, so plan for a tail of traffic to the old server for several hours regardless.
Also confirm who controls the registrar and DNS accounts, that two factor authentication works, and that the people executing the cutover can log in.
Synchronize data without freezing the business
The goal is to move almost all data while the old system is still live, so the final sync during the write freeze is small. A 1 Gbps link moves roughly 10 TB per day at full load, but real migrations rarely reach line rate because the source server, shared hosting limits or many small files slow things down.
- Files. Run an initial full copy with a tool such as rsync, then repeat incremental runs daily. Each run only transfers changes, so the final pass during cutover often takes seconds to a few minutes.
- Databases under a few gigabytes. A dump and restore during the freeze is usually acceptable. Time a test restore so you know the real duration.
- Larger or busier databases. Set up replication from the old server to the new one, let it catch up, and promote the replica at cutover. This reduces the freeze to the time needed to stop writes and confirm the replica is current.
- Uploads and user content. If users upload files continuously, either include upload directories in the final sync or temporarily point uploads to shared object storage both sides can reach.
Verify data, do not assume it. Compare row counts for key tables, checksums or file counts for storage, and the most recent order, post or record ID on both sides.
Move email as its own project
Email often lives on the same shared hosting account as the website, and it fails differently. Treat it as a separate workstream with its own cutover time, even if the destination is the same provider.
Create mailboxes on the new platform first, then copy existing mail with an IMAP synchronization tool, running a final incremental pass after MX records change. Publish SPF, DKIM and DMARC records for the new sending servers before switching, and keep the old server accepting mail for at least a week so messages from senders with stale DNS are not bounced.
Write the cutover plan and the rollback plan
A cutover plan is a numbered runbook with times, owners and a go or no go decision at each critical step. Rehearse it at least once against a staging copy, timing each step, so the real window holds no surprises.
A typical sequence looks like this: announce the window, enable a maintenance page or set the application to read only, run the final file and database sync, run the verification checks, update DNS records, test the new environment through its new address, and then reopen writes.
Decide in advance what conditions trigger it (for example checkout errors above an agreed rate, or a failed data check) and who has authority to call it. Keep the old environment intact and running for 7 to 14 days.
Validate, then tune
Validation starts the moment DNS changes and continues for several days. Test from outside your network, and from more than one country if your users are international.
- Functional checks. Home page, login, search, forms, checkout and any business critical transaction, run end to end with test accounts.
- Technical checks. Valid TLS on every hostname, correct redirects, no mixed content warnings, HTTP status codes on a crawl of key URLs and clean error logs.
- Background work. Confirm that cron jobs ran on schedule, queues drain, backups completed and outbound email delivers.
- Integrations. Ask partners to update IP allowlists, then confirm payment callbacks and webhooks arrive at the new environment.
Migrations usually start with conservative sizing, so review CPU, memory and disk metrics after one to two weeks of real traffic and resize up or down. Enable object caching (for example Redis) and a CDN for static assets, adjust database memory settings to the new hardware, and set alert thresholds based on observed baselines rather than defaults. Finally, run a test restore from the new backup system.
Step-by-step migration checklist
- Two to four weeks before. Complete the inventory, assign owners, define the write freeze and data loss targets, and choose the cutover window.
- Two weeks before. Provision the new environment, match runtime versions, deploy the application to staging and run an initial full data copy.
- One week before. Rehearse the cutover on staging, time each step, finalize the runbook and rollback triggers, and confirm registrar and DNS access.
- Forty eight hours before. Lower TTLs to 300 seconds, start daily incremental syncs or database replication, and notify users and partners.
- Cutover day. Enable the maintenance page, run the final sync, run data checks, switch DNS and MX records, validate through the new address and reopen writes.
- First 72 hours. Monitor errors and performance, run functional checks daily, sync remaining email and keep the rollback path ready.
- After two weeks. Right-size resources, enable caching and CDN, test a full restore, raise TTLs back to normal values and decommission the old environment.
How Vonahost can help
Vonahost managed cloud runs on Vonahost's own platform, on AWS or on Google Cloud, with CDN, backups, SSL, monitoring, staging environments, Redis and Elasticsearch included. You choose the country where each server runs, and data is not moved without your approval.
If you are planning a move from shared hosting or an older server, Vonahost can review your inventory and propose a target environment. Every proposal states the configuration, location, responsibilities on each side and the monthly price in US dollars, so the scope of the migration is clear before work begins.