How Project Managers Can Reduce Downtime During Hosting Changes

Learn How Project Managers Can Reduce Downtime During Hosting Changes

Migration downtime is a scheduling failure dressed up as a technical one. The file copy takes an hour. The database export takes ten minutes. What takes the site offline for a day is a name server record that was changed at 4 pm on a Friday with a 24 hour cache lifetime attached to it, by someone who had not been told that the marketing team was publishing a campaign that evening. The project manager owns that sequence, and the sequence is where the outage lives.

The Two Kinds of Downtime

Hard downtime is the site returning an error. Soft downtime is worse and harder to see, because the site answers normally while half the traffic reaches the old server and half reaches the new one. Orders placed on the old server never appear in the new database. Nobody notices for three days. A migration plan that only accounts for the first kind will produce the second. The measure that matters is the length of the window during which two versions of the truth exist, and a plan should state that number explicitly.

Environment Parity Before the Move

The target must match the source before anything is copied. PHP version, database engine version, memory limit, and installed extensions all belong on a comparison sheet, filled in for both environments, signed off before the migration date is booked.

Most migration incidents trace back to a difference somebody assumed away. A plugin that works on PHP 8.1 and fails on 8.3 will fail during the cutover, at the exact moment when nobody has time to debug it, and the rollback will happen under pressure instead of under a plan.

Capacity in the Target Environment

Capacity is part of parity. A site being moved because it outgrew its old plan needs a target with room to spare, and picking vps web hosting with a defined processor and memory allocation gives the team a number to test against instead of a promise to hope against.

Schedule the load test as a gate on the cutover date. If the new environment cannot serve the current traffic on a Tuesday afternoon, the migration should be postponed, and that decision is far cheaper on a spreadsheet than at 2 am with customers watching.

DNS Cutover and Propagation

The record change is the moment of truth, and it is governed by a number most teams forget to lower. Every DNS record has a time to live, and resolvers around the world will keep serving the old address until that timer expires. At a default of 86,400 seconds, some visitors will reach the old server a full day after the switch.

Lower the time to live to 300 seconds at least 48 hours before the migration, so that caches worldwide have already picked up the short value by the time the address changes. Caching behaviour of this kind is written into the DNS protocol, and the shorter value converts a 24 hour tail into a 5 minute one. Restore the original value a week later.

Content Freeze and the Sync Gap

Between the database export and the DNS switch, the old site is still accepting orders, comments, and form submissions, and every one of those records is written to a database that is about to be abandoned. The gap is where data goes missing.

Two mechanisms close it. A content freeze, announced in advance and enforced by turning off publishing and checkout on the old site, or a final delta sync performed immediately before the switch. Either one belongs in the change management record with a named owner, because a freeze nobody was told about is not a freeze.

Rollback Criteria Written in Advance

The rollback criteria belong in the plan, written down and agreed before anyone touches a name server. A failed checkout, an error rate above 2%, or a page load beyond 4 seconds at the 75th percentile should each trigger a reversal without further discussion. The point of writing them down in advance is that a team standing in front of a broken site at 2 am will otherwise negotiate with itself.

Keeping the old environment running and untouched for a week is what makes the rollback real. This is the reasoning behind blue-green deployment, where the previous version stays live and idle so a bad release can be reversed by pointing traffic back at it. The old plan costs one month of fees. An unrecoverable migration costs considerably more than that.

Verification After the Cutover

The migration is not finished when the site loads, because the failures that survive a cutover are the quiet ones. Contact forms send mail from an address the new server is not authorized to use, scheduled tasks stop firing because the cron entry was never copied, certificates are missing for a subdomain nobody tested, and payment webhooks keep posting to the old address.

Certificates deserve their own line on the checklist, since a missing one for a subdomain produces a browser warning instead of an error page, and browser warnings do not show up in uptime monitoring.

Search traffic deserves its own pass. Broken redirects and redirect chains are among the technical SEO mistakes that quietly drain revenue after a move, and the loss appears two weeks later, long after the migration was declared a success and the team moved on. Crawl the old URL list against the new site and confirm every one of them resolves.

The Maintenance Window and the People in It

A migration needs a window when traffic is low, and the analytics tell you when that is. It also needs the people who can fix things awake and available inside it, and that part is pure scheduling.

Publish the window to everyone who touches the site. Support needs to know why the checkout is disabled. Marketing needs to know why publishing is frozen. The client needs to know the site will be read-only for four hours on Sunday morning. Most of the anger generated by a migration comes from the absence of that message, and a four hour outage that everyone expected produces almost no complaints at all.

The Question Worth Asking First

Every plan should be able to answer one question in a sentence. If this migration goes wrong at 3 am, what exactly do we do, who does it, and how long does it take? A team that can answer cleanly has a rollback path, a monitored window, an owner, and a frozen dataset. A team that cannot answer is not ready to move, whatever the calendar says. Ask it in the planning meeting, before the date is set, and treat a vague answer as the schedule risk it actually is.