A business that has been running for years does not stop while its systems are replaced. Customers still arrive, stock still moves, bills still have to be raised, and the day the new system goes live is a normal trading day for everyone except the people deploying it.
That is the actual constraint, and it is the part of a software project most likely to go wrong. The build happens in a controlled environment where mistakes are cheap. The cutover happens once, on a specific day, in a live operation, in front of customers.
Almost all of the risk in that day is removed before it, by decisions that look procedural at the time.
Why the switch is where projects fail
Three things converge at cutover that were separate until then.
The data becomes real. Years of records move from a spreadsheet, an older system, or a register into the new one — and whatever was inconsistent about them becomes visible immediately. The considerations are in moving years of records without losing them.
The users are new. Everyone using the system on day one is using it for the first time under real pressure, which is a different exercise from training.
There is no fallback unless one was built. If the old system has been switched off, every problem is now urgent.
The projects that go badly are the ones where all three arrive on the same morning.
Choosing how to switch
There are three shapes, and the choice should be made deliberately rather than by default.
Parallel running. Both systems operate for a period, and the outputs are compared. It is the safest option and it doubles the work for the staff doing it, which means it can only be sustained for weeks rather than months. Best where the cost of an undetected error is high — billing, stock valuation, anything financial.
Phased. One location, one department or one function moves first. The rest follow once it is proven. This is usually the right answer for multi-site operations, because the second site benefits from the first site's problems, and support can be concentrated where it is actually needed.
Direct cutover. Everything switches on a date. Fastest, cheapest, and it concentrates all risk into a single day. Defensible for small operations, for a system with no predecessor, or where parallel running is genuinely impossible.
The wrong choice is usually direct cutover selected because it was never discussed — chosen by the calendar rather than by the risk.
What has to exist before the date
A rollback that has been tested. Not a plan describing rollback — an actual rehearsal. An untested rollback plan is an assumption, and it will be discovered to be wrong at the worst moment.
A defined moment for the go/no-go decision. Named person, stated criteria, decided in advance. Without it, the decision gets made under pressure by whoever is in the room, and the answer is always to proceed.
The data migrated and verified, before the day rather than on it. Verification means checking specific known records, not confirming that row counts match.
People trained and available. Not a session weeks earlier — the people who will use it, present, with someone alongside them, as described in training staff on a system they didn't ask for.
A manual fallback for the critical path. If billing cannot happen, the business stops. A written procedure for taking orders on paper for two hours is unglamorous and it is what keeps the doors open.
Choosing the day
The date is a real decision and it is frequently made badly.
Avoid peak. Avoid month end and financial period boundaries. Avoid the day before a holiday, when a problem sits unresolved for a week. Avoid a day when the people who know the system are travelling.
The best cutover days are boring ones — low volume, full staffing, a clear week afterwards. A retailer switching the week before a festival has chosen the single worst available date, and it happens regularly because the project ran late and the date was inherited rather than chosen.
The first two weeks
Go-live is the start of the risky period, not the end of it.
What matters through it: someone present where the work happens rather than reachable by email; small irritations fixed within days, because that is what establishes the system as responsive; the old system available but not actively used, so a genuine failure has somewhere to fall back to; and a daily check on the numbers that matter, to catch a silent divergence before it becomes a month of bad data.
That last one is the failure nobody plans for. Systems rarely fail loudly at cutover; they fail by producing plausible numbers that are subtly wrong, and the sooner someone compares them to reality the cheaper the correction.
Why we treat this as part of the build
Truffaire has delivered ten systems across ten clients — retail, clinical, inventory, warehouse, delivery, logistics, production monitoring, factory operations and billing — into businesses that were already trading.
Every one of those was a replacement of something, and the position that follows is that deployment is a phase of the engineering work rather than a handover event. A system designed without regard for how it will be introduced tends to require a hard switch, because nothing in it was built to coexist with what it replaces.
That is the reasoning in how Truffaire builds software, and the reason the configuration layer matters here too: a system that can be adapted after go-live can absorb the first fortnight's discoveries, which is the subject of configuring software to the business.
Frequently asked questions
How long should parallel running last?
Long enough to cover a full cycle — usually a month, so that period-end processes are exercised. Longer than that and staff sustaining double entry begin to abandon one side.
Can we go live over a weekend?
For the technical switch, yes. For the first day of real use, no — going live on a Monday with full staffing beats going live on a Saturday when the people who can help are unavailable.
What if the old system cannot run in parallel?
Then phasing or a tested rollback carries the risk instead. The requirement is that some fallback exists, not that it is specifically parallel running.
Who decides whether to proceed?
One named person, against criteria written down before the week of the cutover. Committees under time pressure approve.
What does a failed cutover actually look like?
Rarely a crash. Usually a business trading normally on numbers that are quietly wrong for three weeks — which is why the daily reconciliation in the first fortnight matters more than the switch itself.
Where to start
Before any go-live date is agreed, ask one question: if this does not work by eleven in the morning, what happens.
If the answer is a plan nobody has rehearsed, that rehearsal is the next piece of work — and it is considerably cheaper than discovering the gap on the day.
If you are replacing a system in a business that cannot stop, get in touch.