It is 2am on the go-live weekend, and the old system is already dark. There is no going back to it now. Someone is on the phone to a supplier integration that will not answer. The data load that was supposed to take two hours is at hour five. And a project manager is doing the quiet arithmetic of how little time is left before Monday, when three thousand people log in expecting to do their jobs.
Everybody treats go-live as a date. A finish line with a party after it. That is exactly why it hurts so often, because a date is something you simply arrive at, and you cannot fail at arriving.
A go-live is not a date. It is a load test: the first time your config, your data, your integrations and your people all run at once, with nothing to fall back on.
Load tests have a pass condition and a fail condition. The teams whose weekends are calm are the ones who had already sat this exam twice, in rehearsal. The teams whose weekends turn into a three-month clean-up treated the exam as a deadline they were sprinting toward. The difference is almost never talent. It is what they did in the weeks before.
The dress rehearsalA cutover you have never timed is a guess
The single best predictor of a calm go-live is a boring one: a full mock cutover, run end to end on a copy that looks like production, before the real thing. Not the data load on its own. The whole runbook. Extract, transform, load, reconcile, open the balances, flip the integrations, smoke-test the journeys that matter. Timed. In order. By the people who will do it for real.
The first rehearsal always overruns, and it always surfaces the step nobody wrote down. That is the point of it. You want to meet the six-hour load and the reconciliation that will not tie in a rehearsal you can stop, not at 2am with the old system already gone. Do it at least twice: the first proves the runbook is incomplete, the second proves it is repeatable and hands you a real duration to plan the weekend around.
The quiet failureMigrated data is guilty until it reconciles
Data does not have to be missing to sink you. It only has to be a little wrong, and a little wrong is invisible right up until finance tries to close the month.
A load with no errors is not a load that is right. You have verified the loader, not the data.
So reconcile against numbers the business already trusts, both ways, before you commit: trial balance to trial balance, inventory quantity and value by site, open receivables and payables, open orders by count and value. The dangerous load is not the one that throws errors. It is the one that runs perfectly and lands the wrong costing method on a single site, or drops the orders that were mid-shipment when you took the extract. Those do not announce themselves. They surface three weeks later as a variance, when it is a forensic investigation instead of a validation step.
Decided in daylightWrite the go / no-go before the night, not during it
The worst possible time to decide whether you are fit to go live is inside the go-live: at midnight, exhausted, invested, everyone aching for it to be a yes. Decide it in cold blood, weeks ahead. The exact reconciliations that must tie. The transactions that must complete in a smoke test. The count of open defects you will tolerate, by severity. The integrations that must be confirmed live. And, with equal care, the line at which you stop and roll back.
A rollback plan invented on the night is not a plan; it is a panic with a name. Written in daylight, go / no-go becomes a checklist anyone can read against reality. Written on the night, it becomes whatever the highest-ranking tired person in the room wants it to be.
The Monday everyone leftThe exam is the first month-end, not the weekend
Here is the pattern, and it is almost universal. The cutover succeeds. The team celebrates. And on Monday people quietly drift back to their day jobs, because “we’re live now,” at the precise moment users are hitting the system hardest and finding everything the test scripts never thought to try.
Go-live weekend is not the finish line. It is the start of the sharpest stretch of the whole load test: the first two or three weeks, and above all the first month-end close, where every quiet assumption from the project finally meets real volume and real people. Staff hypercare like it matters: named people, real coverage, a fast path from “a user is stuck” to “someone who can fix it,” and a daily stand-up that burns the list down. Treat that first close as a second go-live, because operationally that is what it is. And where the business allows it, phase the whole thing (a lead site first, then roll the pattern out with the lessons already paid for) rather than betting everything on one heroic weekend.
Rehearse the failure before you cannot afford it
Every rule here does the same thing: it drags a discovery earlier, into a mock cutover, a reconciliation, a written criterion, a staffed first month, where it costs a rehearsal instead of a crisis. A calm go-live is not bravery on the night. It is an exam you have already passed twice, so the real one is just paperwork.
2am, the other version
Picture the same weekend on the other team. It is still 2am. The old system is still dark. But nobody is doing panicked arithmetic, because they have run this exact sequence twice and know it finishes at four. The reconciliations tie, the way they tied in rehearsal. The integration that failed last time was found and fixed a fortnight ago. Monday will be busy, and hypercare is already rostered for it. The weekend is not a leap of faith. It is the calmest part of the project, because all the hard moments happened earlier, on copies, where they were allowed to.
Rehearse the go-live, don’t brave it
We plan and run IFS Cloud cutovers as rehearsed load tests, with fixed-price guarantees, and we rescue the ones that went live on hope. If your date is close and any of this feels soft, let’s talk while there is still time to rehearse.
Plan a rehearsed cutover