A NetSuite Go Live Checklist with Clear Stop and Go Criteria
A NetSuite go-live decision should be based on evidence that the business can operate, reconcile its opening position and respond to problems. The cutover runbook should make that evidence available before irreversible business actions begin. A checklist reduces omissions, but it cannot remove every risk or replace a sponsor's judgment.
Build the runbook from rehearsed steps rather than assembling it during launch weekend. Give each step an operator, reviewer, dependency, expected duration and stop condition. Record the final authority for proceeding, postponing or switching to an approved contingency process.
Agree the cutover boundary
Define the last transaction accepted into the source system and the first transaction intended for NetSuite. State the cutoff date, time and timezone for each relevant operation. A business trading across timezones may need different operational cutoffs that still reconcile to a common accounting position.
List activity that will continue during the window: incoming customer orders, warehouse movements, bank activity or supplier messages. Define how it will be captured, protected from duplication and introduced after the opening position is accepted. A source-system freeze is incomplete if connected systems continue writing unnoticed.
Confirm who can authorize changes to the runbook. Keep one controlled version and an issue channel with decision-makers available. Record actual start and completion times during execution so the team can see whether the remaining window is realistic.
Complete prerequisites before the final load
Require approved process design, accepted critical UAT scenarios, reviewed user access, trained operational owners and a rehearsed migration method. Obtain the final data mappings and identify the source extracts expected at cutoff.
Verify that support contacts, incident severity rules and escalation routes are available. Ensure business staff know how to report an issue with a record reference and clear consequence. A launch team cannot triage effectively if every report arrives as “urgent” without context.
Do not assume a sandbox rehearsal is a production backup or a one-click recovery mechanism. Oracle's Sandbox FAQ documents account-copy and testing limitations. Identify the recovery options that actually exist for NetSuite and each connected system, and have responsible owners validate them before launch.
Extract and preserve the final source position
Retain unchanged extracts and control reports with their filters, cutoff and source company. Record counts and totals by meaningful population. Preserve evidence of late adjustments and the approval that included or excluded them.
Run the approved transformations using the final mapping version. Validate file formats, dependencies and identifiers. If an unexpected source condition appears, pause the affected load for a decision instead of silently applying a new rule during the cutover window.
Keep source data and credentials protected. The runbook should identify approved storage and access without placing secrets inside a broadly shared checklist. Restrict production changes to the people assigned to execute them.
Load and reconcile in controlled stages
Follow the rehearsed dependency order. Confirm master records before dependent transactions, and record success and failure populations for each batch. Do not mark a stage complete solely because its import job stopped running.
Reconcile the opening trial balance, receivables, payables and inventory where applicable. Include entity, currency, account and document-level checks appropriate to the risk. Oracle explains that opening balances generate journals; the migration design must account for balances created by other imported transactions to avoid duplication.
Give finance time to review differences. Agree thresholds beforehand, distinguishing acceptable explained rounding from unexplained accounting differences. Small totals can hide material offsetting errors, so inspect the relevant underlying populations.
Verify access and connected systems
Run a short production smoke test under approved business roles. Confirm the critical user can create or process the intended record, find the required report and see only the appropriate data. Test a representative restriction as well as a permitted action.
Check interface endpoints, schedules, source identifiers and exception queues. Confirm that the integration owner knows where messages begin and end, which messages are pending and which have already succeeded. Activate flows in the agreed order and reconcile initial populations before increasing volume.
Treat external side effects carefully. Sending an invoice, releasing a shipment or processing a payment can change the recovery options. Use authorized test arrangements and define the point at which the team moves from pre-launch checks to live business activity.
Make the go or no-go decision explicit
Present the sponsor with a concise evidence pack: accepted reconciliations, critical test results, open issues, operational readiness and remaining time. State which mandatory criteria passed and which did not. Do not bury a blocker inside a long status report.
Typical stop conditions include unexplained material balances, missing critical master data, a failed essential flow, uncontrolled duplication or unavailable production access for a required role. The exact criteria belong to the business and should be approved before the launch window.
For an accepted residual issue, name the business owner, temporary control, monitoring method and resolution plan. “The team will watch it” is not an adequate control when nobody owns the observation or decision.
Hypothetical go-live decision
A company completes its financial reconciliation, but the first warehouse smoke test shows shipment confirmations have no stable source reference. The team cannot demonstrate how it will prevent duplicate fulfillment after a retry.
The sponsor postpones activation of that flow and evaluates the previously approved manual contingency. If the contingency cannot handle the expected volume safely, the overall launch is postponed. If it can, the sponsor approves its limited use with a named reconciliation owner. Either decision is grounded in the same operational evidence.
Run stabilization with an exit criterion
During hypercare, review transaction backlogs, reconciliations, interface exceptions and user issues at an agreed cadence. Separate new defects from requests for enhancement. Keep decisions and workarounds documented so support can take over.
Close hypercare when the agreed business cycles are stable, critical issues are resolved, remaining items have accepted ownership and the permanent support team has the necessary documentation. Do not declare the implementation complete solely because the first day passed without a major incident.
A useful go-live checklist lets people stop safely as well as proceed confidently. Rehearse the runbook, agree the decision criteria and protect time for the evidence that makes the final choice defensible.