Orpington's ERP Go Live Readiness Checklist
50 points across governance, data, testing, integrations, training and cutover planning — organized around the six variables that most strongly predict ERP go-live outcomes.
ORPINGTON TECHNOLOGIES
CHECKLIST
The ERP Go-Live
Readiness Checklist
Readiness Checklist
50 points across governance, data, testing, integrations, training and cutover
planning — organized around the six variables that most strongly predict ERP go-
live outcomes.
Orpington Advisory Team
planning — organized around the six variables that most strongly predict ERP go-
live outcomes.
Applies to: SAP, Oracle, Microsoft Dynamics 365, NetSuite, Odoo
9 minute read
The ERP Go-Live Readiness Checklist | Page
1
of
5
9 minute read
ORPINGTON TECHNOLOGIES
How to use this checklist
Use this checklist four to six weeks before your planned go-live date — early enough to
remediate a serious gap without moving the date. Each item should be verified with
documented evidence: a signed-off report, a test log, a reconciliation file — not a verbal "yes,
that's done" in a status meeting.
1. EXECUTIVE SPONSORSHIP AND GOVERNANCE
8 points
☐
A single, named executive sponsor is accountable for the go-live decision — not a rotating
steering committee chair.
☐
The sponsor has personally reviewed and approved the cutover plan, not just the project
timeline.
☐
Go/no-go decision criteria are documented in writing and agreed before the decision
meeting, not debated during it.
☐
Business process owners for every affected function have formally signed off on their
area's readiness.
☐
An escalation path exists for issues discovered during cutover, with named decision-
makers reachable that weekend.
☐
Budget and contingency reserve remain available for post-go-live stabilization support, not
fully exhausted at cutover.
☐
Legal, compliance and audit stakeholders have reviewed control changes introduced by
the new system.
☐
A post-go-live governance cadence (daily standups tapering to weekly) is scheduled, not
left to be improvised.
2. CHANGE MANAGEMENT AND TRAINING
9 points
☐
Role-based training has been delivered — not generic system training — using each
department's real transactions.
☐
Training completion is tracked by name and role, with a documented plan for anyone who
has not completed it.
☐
A super-user network is identified, trained and has real authority — established weeks
before cutover, not assembled during it.
☐
Quick-reference job aids exist for the highest-volume transactions in each affected role.
☐
Communication has been segmented by role ("what changes for you"), not delivered as
generic project updates only.
☐
A help-desk or support channel specific to the new system is staffed and communicated to
all users.
☐
Adoption metrics (login rates, workaround usage, ticket themes) are defined and
dashboarded before go-live.
☐
Known process changes that will be unpopular have been explicitly acknowledged by
leadership, not glossed over.
The ERP Go-Live Readiness Checklist | Page
2
of
5
remediate a serious gap without moving the date. Each item should be verified with
documented evidence: a signed-off report, a test log, a reconciliation file — not a verbal "yes,
that's done" in a status meeting.
ORPINGTON TECHNOLOGIES
☐
A plan exists to sunset shadow spreadsheets and legacy workarounds, with a named
owner and deadline.
3. TESTING DISCIPLINE
9 points
☐
User acceptance testing has covered edge cases and exception scenarios, not only the
happy path.
☐
Testing was performed by actual business users, not solely by the implementation team.
☐
Test scripts reflect the organization's real processes, not the vendor's generic demo
scenarios.
☐
Defects found in testing are logged, triaged by severity, and tracked to closure with sign-
off, not just "fixed" verbally.
☐
Performance and load testing has been run at production-representative transaction
volumes.
☐
Security and access-control testing confirms role-based permissions match the approved
access model.
☐
Regression testing has been repeated after the final round of configuration changes, not
only after the first build.
☐
Report and analytics outputs have been validated against known-correct legacy figures.
☐
A formal test sign-off document exists, naming who tested what and confirming
acceptance.
4. DATA MIGRATION INTEGRITY
8 points
☐
Migrated master data (customers, vendors, items, chart of accounts) has been reconciled
record-by-record against source systems.
☐
Migrated transactional and balance data (open orders, inventory, AR/AP balances) has
been reconciled, not just row-counted.
☐
Complex structures (bills of materials, multi-level assemblies, pricing hierarchies) have
been validated at the full-structure level.
☐
A named business owner has signed off on data quality for each migrated domain.
☐
A data freeze and delta-load plan is documented for the period between final extract and
go-live.
☐
Historical data retention and archival approach for legacy systems is documented and
approved.
☐
Data cleansing was performed at the source where possible, not patched only during
transformation.
☐
A reconciliation report is scheduled to run immediately after the production data load,
before users are given access.
5. INTEGRATION TESTING
8 points
The ERP Go-Live Readiness Checklist | Page
3
of
5
ORPINGTON TECHNOLOGIES
☐
Every interface to and from the ERP has been tested end-to-end, not only tested in
isolation.
☐
Integrations have been tested at realistic production data volumes, not sample-sized test
data.
☐
Error-handling and retry behavior for failed integration calls has been tested, not just the
success path.
☐
Middleware, API gateways or EDI connections have documented, tested failover
procedures.
☐
Timing and sequencing dependencies between integrations are documented and tested,
not assumed.
☐
Third-party vendors or partners connected via integration have been included in test
cycles.
☐
Monitoring and alerting for integration failures is live before go-live, not added afterward.
☐
A named technical owner exists for each integration, reachable during cutover weekend.
6. CUTOVER AND ROLLBACK PLANNING
8 points
☐
A detailed, hour-by-hour cutover runbook exists and has been walked through by the full
team.
☐
Specific go/no-go checkpoints are defined during cutover, not just at the start.
☐
A documented rollback plan exists, including the criteria that trigger it and who is
authorized to call it.
☐
A defined post-go-live stabilization period exists before legacy systems are
decommissioned.
☐
Communication to end users and external partners about the cutover schedule has gone
out with adequate notice.
☐
Hypercare support staffing (extended hours, on-site presence) is arranged for the first
weeks after go-live.
☐
Backup and disaster-recovery procedures for the new production environment have been
tested, not just documented.
☐
A lessons-learned review is scheduled for after stabilization, with a mechanism to act on
the findings.
The ERP Go-Live Readiness Checklist | Page
4
of
5
ORPINGTON TECHNOLOGIES
How this checklist maps to the free diagnostic
These six sections mirror the six variables scored by Orpington's free Implementation
Confidence Diagnostic — executive sponsorship, change management, testing discipline,
data migration integrity, integration testing and cutover strategy. Testing and data migration
carry the heaviest weight in that model, because gaps in those two areas surface latest and
are hardest to recover from once found.
FREQUENTLY ASKED QUESTIONS
What should be on an ERP go-live readiness checklist?
Confidence Diagnostic — executive sponsorship, change management, testing discipline,
data migration integrity, integration testing and cutover strategy. Testing and data migration
carry the heaviest weight in that model, because gaps in those two areas surface latest and
are hardest to recover from once found.
A thorough ERP go-live readiness checklist covers six areas: executive sponsorship and
governance, change management and training, testing discipline, data migration integrity,
integration testing, and cutover and rollback planning. Each area should be verified with
documented evidence, not a self-reported status update.
How far before go-live should the readiness checklist be reviewed?
governance, change management and training, testing discipline, data migration integrity,
integration testing, and cutover and rollback planning. Each area should be verified with
documented evidence, not a self-reported status update.
A full readiness review should happen at least four to six weeks before the planned go-live date,
with a lighter final verification in the week before cutover. Reviewing readiness only in the final
days leaves no time to remediate a serious gap without delaying the go-live.
Who should sign off on ERP go-live readiness?
with a lighter final verification in the week before cutover. Reviewing readiness only in the final
days leaves no time to remediate a serious gap without delaying the go-live.
Sign-off should involve the executive sponsor, the business process owners for each affected
function, and technical leads for data, integrations and infrastructure — not the project
management office alone. A go-live decision made without business-side sign-off is a common
precursor to post-go-live adoption problems.
Orpington Advisory Team
ERP implementation risk advisory — SAP, Oracle, Dynamics 365, NetSuite & Odoo
The ERP Go-Live Readiness Checklist | Page
5
of
5
function, and technical leads for data, integrations and infrastructure — not the project
management office alone. A go-live decision made without business-side sign-off is a common
precursor to post-go-live adoption problems.