Technology ready, operations not: what evidence should support a go-live decision?

The dangerous gap between system and operation

Near go-live, a long programme compresses into an apparently binary question: launch or delay. Technology reports completed testing, the vendor declares readiness, while operations, finance, security or business teams still see open issues. Those differences are not necessarily resistance. They may reveal that each function is measuring a different part of reality.

Microsoft's go-live guidance connects technical approval with business acceptance, migration, dependencies, change management, operational support, cutover roles and verification. The underlying management question is broader: a system can be ready while its operating environment is not. Technical status should therefore never carry the go-live decision on its own.

Six evidence fields for the management decision

First, the minimum business scope must be unambiguous. Which end-to-end processes must work on day one? Which manual workarounds are tolerable, for how long and under whose ownership? A high percentage of completed requirements says little if the missing portion blocks a critical process.

Second, leaders need test evidence, not merely test status. Coverage, representativeness, open defects, retesting and the quality of acceptance matter. A closed ticket does not prove that the underlying cause has been removed or that an end-to-end process is stable.

Third, data migration must be operationally and technically defensible. Reconciliation, completeness, quality, access rights and residual data belong in the same decision. Rehearsals under realistic time and volume constraints must support both cutover and fallback.

Fourth, the operating model itself must be tested: trained roles, support, monitoring, incident and problem processes, continuity, capacity and escalation. A signed readiness checklist is evidence only when its criteria, supporting records and owners can be traced.

Fifth, controls, security and compliance require an explicit position. Open control gaps do not disappear inside general risk appetite. Management must understand the exposure, who is authorised to accept it and which compensating controls are genuinely ready.

Sixth, cutover must be treated as an integrated operation. Sequence, decision windows, communication paths, abort criteria and fallback point must be consistent across business, technology, suppliers and operations. A schedule without decision rights is a description, not a control mechanism.

Go, conditional go, delay or reset

The choice needs more than two states. Go is defensible when critical outcomes, controls and recovery conditions are evidenced. Conditional go may be appropriate where residual gaps are bounded, observable and assigned to named owners with short deadlines. Delay is responsible when evidence can realistically be closed by a defined date. Reset becomes necessary when the problem is structural rather than temporal — for example unclear accountability, unstable design or an unmanageable migration approach.

These options should be defined before the final meeting. Otherwise, criteria tend to be reinterpreted under pressure to preserve a date already communicated. Agreed thresholds cannot remove every surprise, but they protect the decision from improvised optimism.

How an independent review resolves the conflict

When business and technology produce different readiness pictures, the answer is not to negotiate the most convenient colour. A shared decision model is required: which claims are critical, what evidence supports them, where do sources conflict, and which dependency changes the consequence? An independent review connects these fragments without becoming the implementer or formal approval authority.

The output should be concise enough for the decision forum and precise enough for accountability: recommendation, conditions, open evidence, immediate priorities and named owners. That converts an emotional deadline debate into a defensible choice among Continue, Reset and Stop — or, in release terms, Go, Delay and fundamental redesign.

Questions for the go-live forum

Before the meeting, the forum should know which criteria are non-negotiable, which residual gaps may be consciously accepted, and who has formal authority to do so. Every critical field needs a reference to evidence, not another presentation. Where proof is missing, the gap should remain visible as a gap. Repeating an assumption across several slides does not make it stronger.

The first period after launch matters equally. Which signals will show early that operations, controls or customer impact differ from expectations? Who may constrain service, trigger fallback or commit additional resources? The go-live decision does not end when the technical switch is made. It includes the organisation's ability to observe the new state and intervene in time.