How to avoid downtime during a migration
The migration starts at ten in the evening. By half past eight the next morning, the first employee is staring at a screen that keeps loading, and the first customer finds out that checkout is broken. That costs more than an awkward day. Orders stall, the support inbox fills up, and trust you spent years building takes a hit.
Avoiding downtime during a migration does not start with copying data. It starts with a simple question: which processes have to keep running no matter what, and what does it take to make that happen?
Whether you are moving to new hosting, modernising an application, relocating a database or merging two systems, a change like that almost always touches more than the environment itself. DNS, email, API connections, your payment provider, stock levels, the way people actually do their jobs. Finding that out during go-live is a risk you did not need to take.
One point of nuance first, because it shapes everything else. In practice, avoiding downtime rarely means zero seconds of unavailability. It means you prevent the unplanned kind, and that any interruption you do schedule is short, announced and reversible. Getting that distinction straight up front saves a lot of arguing later.
Why migrations go wrong more often than they should
Most problems do not come from a server that refuses to be copied. They come from assumptions. An integration turns out to still point at an old IP address. A background job keeps happily writing to the old database. A certificate never made the trip. Then there is timing: migrating during a quiet week sounds sensible, right up until you realise that nobody who knows the daily process from the inside is around that week.
So asking whether the new environment works technically is too narrow. The better question is whether every critical action still goes through. Can a customer pay? Does an order land in the right system? Does the team get its alerts? Is the stock figure on screen the real one? Technology is the means. Continuity is the point.
Environments with a lot of custom work need extra care. Standard checklists are useful, but they say very little about your accounting integration, your customer portal, or the import script that runs at three in the morning. Those exceptions usually decide whether a switch is uneventful or turns into a week of cleanup.
Start with the dependencies
Map out what is running and what depends on it before you touch anything. Basic advice, true. And it is the first step to get dropped when the schedule tightens. Inventory more than websites, applications and databases: include domains and mail routing, cron jobs, external APIs, firewall rules, SSL certificates, caching and monitoring.
Then tie each item to a business function. An API is not just a technical connection; it may be the route your orders take to your fulfilment partner. A mail server is not just infrastructure; it is where order confirmations and support questions arrive. Once you have made that translation, it is obvious which parts cannot wait a minute and which can wait an hour.
Decide what genuinely cannot go down
Not every system has the same requirements. For a B2B portal, a maintenance window on Sunday morning is usually fine. For a web shop with campaigns running or customers in other time zones it is not, and a SaaS application with active users needs a different approach again than an internal tool used between nine and five.
Write down two numbers per process: how much downtime is acceptable, and how much data loss is. Those two get lumped together a lot, even though they measure different things. Availability is about how long a system is unreachable. Data loss is about the changes that did not make it across after the last sync. You can be back online in five minutes and still be missing the last hour of orders. Both limits belong on paper before you start.
Pick a strategy that matches the risk
A simple site that rarely changes usually moves in a single planned switch: copy it, check it, point the traffic at it. For a busy transactional platform that is too blunt. A phased approach fits better there, with data synchronised several times and the final cutover happening after a short freeze on changes.
Sometimes running both environments in parallel for a while is the smartest option. The old and the new stay up side by side while you move traffic across in steps, or let a small group of users land on the new one first. It takes more preparation and more management. For systems where an outage hits revenue or productivity straight away, that is worth paying for.
Complexity has a price, and that price is a risk in itself. A setup that promises zero downtime but that nobody on the team fully understands is more dangerous than an honest ten minute maintenance window with a clear way back. Choose the simplest approach that meets your availability requirement, not the most impressive one.
Test the new environment as if it were already live
A test page that loads only proves that a test page loads. Work through realistic scenarios and, where you are allowed to, use a carefully handled copy of production data. Log in as different roles. Place an order from start to finish. Create a record, run an export, check that the system on the other end of the integration receives exactly what you expect.
Do not skip the invisible work: queues, scheduled jobs, outgoing mail, logging, backups, search indexes and reports. Look at performance under load as well. An application that feels quick in a quiet test environment can still grind to a halt in production because of different caching settings, network rules or a database configuration that is slightly off.
And do not leave the testing to developers and administrators alone. Put someone on it who runs the process every day. They will spot within a minute that an order is created but gets the wrong status, or that the export the planning team uses every Monday has quietly moved. Technically correct and actually workable are two separate checks.
Go-live: small team, clear roles
At the moment of the switch, everyone needs to know who decides, who executes and who communicates. A large chat group with instructions scrolling past rarely works. Keep the migration team small and name one person who tracks progress and makes the call when something deviates from the plan.
Use explicit go/no-go moments. Before: is there a recent backup, has the new environment been tested, is everyone reachable? During: is the data sync correct, has DNS been updated, are the certificates active, are the integrations responding, are the core processes going through? Only once those are ticked off do you call the migration a success. Not earlier, however good it looks.
DNS deserves its own attention. Making the change takes seconds, but when everyone sees it depends on caching at providers and on users' devices. Lower the TTL well in advance if your situation allows it, and do not assume every party will respect that TTL. A temporary redirect, monitoring on the old environment and a plan for traffic still arriving there take the edge off.
Tell your colleagues in advance what to do and what to leave alone. If someone edits a record in the old system during the final sync, the two environments drift apart. A short change freeze is then unavoidable. Make it as specific as you can: which actions are paused, from what time, until when, and who can answer questions.
A rollback plan is not a sign of doubt
Migrating without a rollback plan is gambling with production. If a critical check fails, it should already be clear when you go back, how that works and who is allowed to make that call. You do not want to be drawing that line while a customer is on the phone.
A usable plan says more than 'turn the old server back on'. What happens to the data that changed in the meantime? Which DNS settings need reverting? What does it mean for users who are logged in? Who tells the team, and who tells the customers? And how long does the old environment stay available? Anyone who tears it down immediately has closed their own escape route.
Backups are part of this, but only if you have practised the restore. A backup nobody can confirm is complete and current offers false comfort. So test more than whether the backup runs: test whether it actually comes back on a separate environment, and how long that takes.
The hours afterwards decide whether it really went well
The first hours after a migration matter as much as the switch itself, because plenty of things do not fail loudly. An external integration trips on the next batch. A mail problem surfaces when the first customer submits a form. Performance issues appear at the first peak, and that peak might be days away.
So monitor availability, errors, response times and server load, but follow the business flows above all. Are orders coming in, are payments confirmed, do notifications go out, do the nightly jobs finish? Agree who reviews the alerts and how quickly action follows. Monitoring without an owner is a set of graphs nobody is watching.
At LJPc, development, infrastructure and support sit close together. During a migration that saves time: an alert is picked up straight away by someone who knows both the code and the environment, instead of suppliers pointing at each other first. For organisations with custom software and business critical processes, that short line is often the difference between a small delay and a long outage.
A successful migration feels almost boring afterwards. Not because little happened, but because the preparation, the checks and the ownership did their job. So treat the move as an operational project with an owner and a schedule, not as a technical chore you squeeze in between two other things. That way your organisation stays reachable while the technology moves forward.