The most useful go-live checklist tells the business when to stop. A list of completed activities can look reassuring even when the opening balances are unexplained, an interface cannot recover safely or nobody has authority to make the final decision.
Set the stop and go criteria before cutover pressure builds. Define the evidence, owner and consequence for each critical gate. Then use the readiness meeting to evaluate that evidence rather than negotiate standards for the first time.
A good launch decision does not require pretending all risk has disappeared. It requires knowing which risks remain, whether they are acceptable and how the business will operate if the expected path fails.
The pack should summarize scope, completed tests, reconciliation results, unresolved defects, cutover timing, support coverage and fallback limits. Every critical statement needs an evidence owner and a location where the underlying result can be inspected.
Identify the decision authority. The controller should own financial reconciliation conclusions, operations should own process readiness and IT should own technical readiness within their responsibilities. The sponsor needs an integrated recommendation and a clear record of dissent or conditions.
Separate pass, conditional pass, fail and missing evidence. “No issues reported” is not the same as a completed check. A gate with missing evidence should remain unresolved until the authorized decision-maker addresses it explicitly.
Define the populations that must reconcile: opening trial balance, receivables, payables, cash-related records, inventory where relevant and other material balances. State the source snapshot, cutoff, mapping and treatment of late changes.
Tolerances should be approved by the appropriate finance owner and linked to the nature of the balance. Do not apply an arbitrary percentage across every population. A small amount can still indicate a systematic duplication or incorrect customer assignment.
Require both aggregate and detailed checks. A receivables total can agree while invoices sit against the wrong customers. Sign-off should confirm the level of detail needed for the business to collect, pay, fulfill and report correctly.
Review the end-to-end scenarios that matter on the first day. Confirm that actual roles can complete them and that important exceptions have been tested. Include document outputs, approvals and the associated financial consequences.
For each integration, establish the last successful test, expected processing window, monitoring owner, reconciliation method and recovery procedure. A successful normal-path message does not prove that the team can detect missing transactions or replay a failed batch without duplication.
If a temporary manual process is proposed, test it too. Record its staffing, volume capacity, control checks and retirement condition. “We can do it manually” is a hypothesis until the business shows how.
Create a runbook with ordered tasks, owners, expected duration, verification steps and dependencies. Identify the last point at which the team can stop without creating conflicting transaction populations across systems.
Fallback is not always a simple restoration. Once users or external systems have created new transactions, returning to the previous state may require careful reconciliation and approved recovery work. The plan should explain the practical limits rather than promising an effortless rollback.
Record stop triggers at key checkpoints. Examples include a failed final reconciliation, a material interface defect or insufficient time to complete remaining validation before business opens. Name the person who can invoke the stop and the people who must be informed.
Consider a hypothetical distributor preparing for a Monday launch. Its agreed decision pack requires the final open-receivables population to reconcile by customer and currency, and the order interface to pass a duplicate-replay test. These are illustrative conditions, not universal launch rules.
During rehearsal, the receivables total agrees with the source, but three invoices are assigned to an incorrect customer. The interface processes an ordinary order correctly but creates a second order when the same message is replayed. The team's first-day volume is too high for the proposed manual workaround, which has not been rehearsed.
The financial and integration gates fail. The sponsor does not convert them to “amber” because the overall project is nearly complete. The team assigns correction owners, confirms the required retests and evaluates a revised cutover window.
The example shows why gate design matters. An aggregate-only reconciliation and a normal-path interface test would have concealed both problems. A delay is inconvenient, but the decision now rests on observed operating risk rather than an arbitrary desire to hold the date.
Agree the first-day control totals and review times. Finance and operations should know how they will compare transactions received, processed, rejected and posted. Include the treatment of activity that straddles the cutoff between old and new systems.
Assign owners for unexplained differences and a route for urgent decisions. A first-day review should be able to distinguish a timing difference from missing or duplicate activity. Preserve the relevant source records and processing logs according to the organization's policies.
Plan the first close or other major operating milestone as well. Some issues appear only when the business performs a full reporting cycle, stock review or settlement process. Stabilization should cover the evidence needed for those milestones where they fall within the agreed support scope.
Define how users report incidents, who triages them, which severity categories apply and when business leaders are informed. Publish the support hours and escalation contacts. Confirm what happens outside those hours if the business operates continuously.
Separate a defect from a training question and from a new enhancement request. Each needs ownership, but their urgency and approval routes differ. Track recurring questions because they can reveal a process or training issue affecting many users.
Set exit criteria for hypercare. Examples include agreed transaction reconciliations, resolution or approved disposition of critical defects, a completed handover and support owners able to operate the procedures. An elapsed number of days alone does not prove stability.
Sometimes, if the impact is understood and an authorized owner accepts a tested control or workaround. The decision should follow agreed gates, with a resolution plan and clear responsibility.
Name the accountable sponsor in advance, supported by finance, operations and technical recommendations. Define any specialist approvals that cannot be overridden informally.
Use an approved, representative population in an appropriate environment with required privacy and access controls. The rehearsal should establish that the planned steps, timings and reconciliations are realistic.
Record the scope, evidence reviewed, gate results, exceptions, decision-maker, decision time and conditions. Include the next checkpoint and any stop trigger that remains active during cutover.
Use this checklist to agree your evidence and stop conditions while there is still time to act. Bring unresolved NetSuite cutover risks to CuriousRubik for a focused discussion before the launch decision becomes urgent.