Go-live without chaos – how to plan a system change
Go-live for a system change is its own sub-project, not the push of a button. The decisive choices are the strategy – big bang or parallel run – a rollback plan with clear decision criteria for backing out in time, and reinforced support during the first weeks. A well-planned rollout with a dress rehearsal reduces the risk of the chaos many fear.
Switching a business system is often compared to changing an airplane’s engine mid-flight – the business can’t pause while the switch happens. The rollout itself, what’s called go-live, is a project of its own and the phase where the most can go wrong. Many put all their effort into building the new system and almost none into how the switch will actually happen. Here’s how to plan the rollout so it becomes a controlled transition instead of a weekend of chaos.
Big bang or parallel run?
The first and most important choice is the strategy. Two basic models exist, and they carry a different balance of risk and cost.
- Big bang. Everyone switches at the same time at a set point, and the old system is shut down. It’s the fastest and cheapest, but also the riskiest – if something goes wrong, the whole business is on the new system with no way back.
- Parallel run. Both systems run simultaneously for a period while users gradually move over. Safer, since the old system remains as a safety net, but more expensive and demanding – someone has to keep both systems running and handle data in two places.
The choice is driven by how business-critical the system is. An internal tool can often tolerate a big bang. A system handling orders and payments at the heart of the business justifies the more cautious path, despite the cost.
Dress rehearsal before the real thing
Whatever the strategy, the dress rehearsal is the cheapest way to buy peace of mind. Before the real rollout, you run through the whole process in a test environment, with real data and real steps. The point is to find the errors while they’re still free to find.
A rehearsal reveals what would otherwise surface in the middle of go-live: that a migration step takes three hours instead of thirty minutes, that some data doesn’t migrate cleanly, that a permission is missing for a key role. Catching this in a planned exercise is infinitely cheaper than discovering it at three in the morning during the real go-live, with the whole business waiting.
Rollback plan with clear decision criteria
Hope is not a strategy. Before the rollout begins, you need to know exactly what would make you abort and roll back to the old system – and who makes that call.
| Decision point | What should be decided in advance |
|---|---|
| Rollback criteria | Which concrete errors or delays trigger a rollback decision |
| Decision maker | A named person with the mandate to abort – no committee in the moment |
| Time limit | The latest point a rollback is still possible without data loss |
| Rollback steps | How you actually get back to the old system, tested in advance |
The point of deciding all this in advance is that rollback decisions otherwise get made in panic or too late. When the criteria are set, someone dares to pull the emergency brake in time, before a half-completed switch has done real damage.
The first weeks in production
Go-live isn’t the end, it’s the start of the most sensitive period. This is when real usage patterns meet the system and problems no test caught come to light. Plan for it instead of breathing out too soon.
- Reinforced support. Have developers available for quick fixes during the first days, when pressure is highest.
- A clear channel for users. Questions and errors need an obvious way in, or frustration spreads in the hallway instead of getting resolved.
- Daily check-ins. Follow up on status every day during the early period and prioritize what’s bothering the most people.
Plan for heightened readiness for at least a couple of weeks. That’s when small issues decide whether users gain confidence in the new system or start longing for the old one.
A scenario: the switch that held together
A company switched its central business system and chose parallel run since even a moment of downtime would stop the whole supply chain. They ran a full dress rehearsal the weekend before, set a clear limit for when they’d roll back, and staffed up support for the first week.
During the real go-live, a data error appeared – but since it was well below the rollback threshold and support was on hand, it was fixed within an hour without anyone needing to roll back. The switch felt undramatic, precisely because the drama had been planned away in advance.
A well-planned rollout is cheap insurance against an expensive weekend. Switching a business-critical system? At Weapp we’re happy to help plan the go-live as part of our services – get in touch with a description of what you’re switching.
Frequently asked questions
What's the difference between big bang and parallel run?
Big bang means everyone switches to the new system at a set point in time and the old one is shut down. Parallel run means both systems run simultaneously for a period while users gradually move over. Big bang is faster and cheaper but riskier, parallel run is safer but more expensive and demanding to keep going. The choice depends on how business-critical the system is.
Do we really need a dress rehearsal?
Yes, for a business-critical system it's hard to justify skipping one. Rehearsing the entire rollout in a test environment reveals the errors that would otherwise surface in the middle of go-live – a step taking longer than expected, data not migrating cleanly, a missing permission. It's cheaper to find that in a rehearsal than at three in the morning during the real go-live.
When should we decide to roll back to the old system?
Decide it before the rollout, not during. Set concrete criteria in advance – which errors or delays trigger a rollback – and appoint who makes that call. Without predetermined limits, rollback decisions get made in panic or too late, once damage is already done. A clear limit means someone dares to pull the emergency brake in time.
How long do we need reinforced support after go-live?
The first few days are the most intense, but plan for heightened readiness for at least a couple of weeks. That's when real usage patterns meet the system and problems no test caught show up. Have developers available for quick fixes and a clear channel for user questions, so small issues don't have time to become trust crises.