Go-Live Readiness

The go-live date is four weeks away and the steering committee is debating whether to push it. The implementation partner says you're 85% ready. The finance team lead says critical reports aren't working yet. The CFO has to decide without a clear picture of what '85%' means, or which missing items can be fixed in four weeks and which put operations at real risk. Go-live readiness is the structured assessment of whether an ERP deployment is complete enough to run the business safely on the planned cutover date. It separates critical-path items, the things that will stop the business from operating if they don't work on day one, from nice-to-have items that can be fixed in the weeks after cutover without disrupting operations. The problem is that 'ready' often gets confused with 'on schedule.' A project can be on schedule and not ready, or behind schedule on non-critical items and functionally ready to go live. Without a formal readiness framework that separates critical from non-critical criteria, the go-live decision turns into a negotiation between the implementation partner, who has a contractual incentive to hit the planned date, and the finance team, who will live with the consequences if the system isn't ready.

How go-live readiness is assessed

A go-live readiness assessment checks the deployment against a defined list of criteria in four categories: data migration completeness, functional readiness, technical readiness, and operational readiness. Data migration completeness asks whether the data needed to run operations on day one (open purchase orders, outstanding invoices, vendor master records, open customer accounts, beginning balances) has been migrated, validated against source systems, and approved by named data owners. A migration that is 95% complete sounds close, but if the missing 5% includes open AP invoices, the business can't pay vendors on day one. Functional readiness asks whether each business process the finance team runs has been tested end to end by the people who will actually perform it, not by the implementation partner. User acceptance testing (UAT) done by consultants instead of end users is common readiness theater: it produces sign-off documents that don't reflect how the system will be used. Technical readiness covers infrastructure, integrations, security, and access controls. The systems have to work, the connections have to be live, and users need the right permissions. Operational readiness covers training, support coverage, and whether the cutover runbook has been tested. The cutover runbook, the step-by-step plan for switching from the old system to the new one, should be rehearsed, not written and filed.

Data migration timing, UAT quality

Two go-live readiness issues cause more post-cutover crises than any others. The first is data migration validated on counts instead of content. You can migrate the right number of records and still have the data wrong: truncated text fields, mismatched GL account codes, incorrect currency designations, or wrong transaction dates. Migration validation should include sampling of actual record content, reconciliation of beginning balances to source system reports, and sign-off from finance staff who know what the data should look like. The implementation partner confirming that the ETL process finished is not enough. The second recurring issue is going live before financial reports work. When management reporting, AR aging, AP aging, and cash flow reports don't work correctly in the new system, the business is running blind: people make decisions from the old system or from spreadsheets while officially running on the new one. That creates a parallel-run dependency that can last for months and erodes the business case for the ERP investment. The go-live readiness checklist should require that all Tier 1 reports (the reports finance runs at least weekly) produce output validated against source system data before the go-live date is confirmed.

How implementation partners present readiness

Implementation partners usually measure readiness as a project plan completion percentage: the share of planned tasks marked complete. The number is easy to produce and easy to present, but it says nothing about whether the completed tasks were done correctly. A UAT session where testers signed off without running the critical-path scenarios shows as 100% complete on the project plan. A data migration that ran without errors but produced wrong beginning balances also shows as complete. The useful readiness conversation moves from 'what percent of tasks are done?' to 'which specific items are incomplete, which of those are on the critical path for day-one operations, and what is the realistic resolution date for each?' Ask for a two-column view: items complete, and items not complete with an expected completion date and owner. Then ask the finance team lead, not the project manager, to confirm whether that list matches what's still broken. Implementation partners sometimes underreport open issues to protect the go-live date; the finance staff who will use the system every day rarely do.

Readiness evaluation questions for the go-live decision

• Has data migration been validated against source system records at the content level, beyond record counts, and signed off by named finance team members?
• Have all Tier 1 financial reports been tested and validated against source system output by finance team members, not implementation consultants?
• Has user acceptance testing been conducted by the employees who will use the system daily, covering every critical-path process they need to perform on day one?
• Is the cutover runbook written, reviewed, and rehearsed, and does it include clear decision triggers for pausing or rolling back if critical issues emerge?
• Do all users have correct system access and have they confirmed they can log in and perform their day-one tasks?
• Is there a written list of items not yet complete, with classification of each as critical-path or non-critical, and a realistic resolution date for each?

Common mistakes

The first mistake is using the go-live date as the readiness benchmark. When the date is set months in advance and the project plan is built to hit it, the team works toward the date regardless of actual system readiness. Steering committees then face a binary choice on the planned date: go live as scheduled or delay by weeks. An honest readiness assessment sometimes shows that two or three specific items are incomplete, all of them non-critical, and the system is functionally ready. Treating the date as a pass/fail benchmark hides that. Readiness criteria set before the build phase, with clear definitions of critical and non-critical, let the decision rest on evidence instead of negotiation. The second mistake is having no clear process for deciding between cutover and a parallel run. Many go-live plans assume a clean cutover: old system off, new system on, all operations moved on day one. When critical issues surface after cutover, teams end up improvising a parallel run nobody planned for. They run the old and new systems side by side, reconcile between them, and hope to finish the move before the parallel run gets too expensive to sustain.

Comparing ERP platforms

Most of an ERP decision is settled by data model and entity structure, not by the feature list a demo walks through. Once go-live readiness is settled as a requirement, read the ERP Software category guide for how the market splits, then weigh the NetSuite profile against the Sage Intacct profile on that requirement rather than on the feature list. Our OneStream pricing breakdown records what the vendor publishes and what is quote-based. The OneStream against Planful comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the ERP ROI calculator so the business case is written down before a vendor writes it for you.

Go-Live Readiness questions

Related terms

Chart of Accounts Mapping, Cloud ERP vs On-Premise ERP, and Enterprise Resource Planning (ERP) come up in the same workflow as go-live readiness, and the rest of the ERP platforms cluster is indexed in the finance operations glossary.