Business Central go-live: how do I know whether we are ready?

Readiness is more than a green test report. You are ready when three things are proven rather than assumed, and all three are demonstrable rather than a matter of judgement. First, at least two complete migration test runs: the first uncovers the coarse problems, the second shows whether you actually solved them. Test the migration only once and you are migrating for real for the first time on go-live day. Second, a cutover dress rehearsal, meaning you play the switch through once in full, with a schedule, roles and a fallback point. Only then do you know whether the window is realistic and who does what if things go wrong. Third, measurable go/no-go criteria instead of gut feeling in the steering committee: data reconciles, critical processes run end to end, key users are trained, the fallback plan exists. A green report without a real rehearsal is an assumption, not readiness.

What makes real go-live readiness?

A green test report is an assumption, not readiness. You are ready only once three things are evidenced rather than merely assumed. And all three are demonstrable rather than a matter of judgement:

1. Two or more migration test runs: the first run uncovers the coarse problems, the second shows whether you have really solved them. Whoever tests the migration only once migrates for real for the first time on go-live day.
2. Cutover dress rehearsal: play through the switch once completely, with schedule, roles and a fallback point. Only then do you know whether the cutover window is realistic and who does what in an emergency.
3. Measurable go/no-go criteria: clearly defined conditions instead of gut feeling in the steering committee. The data reconciliation adds up, critical processes run end to end, key users are trained, and the fallback plan is in place.

Source: Microsoft Learn: Set up company configuration packages

The schedule: what to check in the last eight weeks before go-live

Readiness is not created in the week before the date. It is built over the two months leading up to it, in this order, because each step rests on the one before:

1. Eight weeks out: first full migration run. On a copy of the real production data, not on the tidied-up test set. Anything that has never run through at this point is an open risk.
2. Six weeks: the business departments work on the migrated data. For a full week, with their own documents and their own edge cases. That week produces the defect list you then split into showstoppers and follow-up work.
3. Four weeks: second migration run with the corrections applied. This is also where you take the time. How long the migration actually runs determines the length of your cutover window later on.
4. Three weeks: full cutover rehearsal. The entire switch played through once, with clock times, named roles and the point up to which falling back is still possible.
5. Two weeks: fix the go/no-go criteria in writing, finish training. The criteria belong in writing before the pressure rises. Anyone who formulates them during the decision meeting will formulate them to fit the desired answer.
6. One week: the decision in the steering committee. Against the fixed criteria, with the numbers from the runs before. That takes half an hour instead of half a day.

If your plan does not contain these steps, the go-live date is a hope rather than a date. That is fixable, as long as there is still time to move it.

Source: Microsoft Learn: Test your Dynamics 365 solution before deployment

Four sentences that typically precede a failed go-live

These four sentences are said before almost every go-live. Each one sounds reassuring and is in fact an open question:

• „Die offenen Punkte klären wir nach dem Go-Live.“ Without a split into showstoppers and follow-up work, the entire remaining list lands in the first live week, which is exactly when nobody has capacity for it. Split the list beforehand and in writing.
• „Die Schnittstelle lief im Test.“ In testing it ran with a handful of documents. What counts is the run with your daily volume and your peak load, and what happens when the target system does not respond.
• „Die Schlüsselnutzer sind geschult.“ Trained does not mean able to work. The honest test question is: has each of them worked through one full day of their own job in the new system, without anyone sitting next to them?
• „Wir haben einen Rückfallplan.“ A plan that has never been rehearsed is a statement of intent. When it matters, the only thing that counts is whether everyone knows who triggers the fallback and by what time it is still possible at all.

None of these points is expensive to check. It only gets expensive when they stay unchecked and the answer arrives in live operation.

Why do you need business sign-off and the courage for a no-go?

A technical test alone is not enough. The critical processes belong walked through by the business departments on real data, not merely ticked off by the project team. Only the business sign-off shows whether operations actually run on day one.

The difference is greater than it sounds. The project team checks whether the system does what was once specified. The business checks whether it does what the working day demands, and those two questions regularly diverge, because by no means every requirement was documented.

An honest no-go is a senior decision, not a failure. A postponed go-live costs less than a go-live that collapses in day-to-day operations. Control stays on your side. If you are facing go-live and are unsure whether green really means ready here, we examine your criteria together in a conversation.