Cutover without downtime: switching while the business keeps running

Why a single switchover date rarely works

A big-bang cutover requires master data, open transactions, interfaces and people to be ready at the same moment. If one of them is not, the whole date falls, and the next one is often weeks away.

Switching in stages means: one clearly bounded area goes live, runs two weeks in production, and only then does the next one follow. Every stage can be checked on its own, and a rollback never touches the whole business.

Which area goes first

The first area should have two properties: it hurts today, and it depends on as few others as possible. Purchasing is often a good start, accounting rarely, because everything else hangs off it.

What goes first is decided by your processes, not by a general recommendation. That is exactly what the setup check is for.

What running two systems really costs

Maintaining two systems at once is expensive and error-prone, so the phase should be short and clearly bounded. It makes sense where an area still needs figures from the old system, open items across a month-end for instance.

The important part is deciding in advance which system leads during that time. Without that decision you get two versions of the truth, and cleaning that up costs more than the switch itself.

The rollback plan nobody needs

Before every stage comes the question of how yesterday's state would be restored: which data, who decides, how long it takes. In most projects the plan is never used. It still changes how calm the switchover is.