ERP go-live checklist: readiness, cutover, hypercare and records preservation

Why this go-live checklist adds a records step

Most go-live checklists end when the new system posts its first invoice. This one also protects what the project and the old system produced. A legacy ERP often holds a decade or more of orders, invoices, credits, returns, purchasing decisions and approvals, and the project itself generates UAT scripts, defect logs, decision logs and configuration workbooks. After cutover, the legacy license is frequently cancelled, the server decommissioned and the project workspace archived, and nobody owns those records anymore.

The extra step is a metadata-only inventory before anything is retired. It takes hours, not weeks, and it keeps the client's options open, including licensing that history if the company qualifies.

The ERP go-live checklist

Work through each group in order. A box left unchecked is either a no-go item or a documented, accepted risk.

Readiness: four to six weeks before go-live

• Go/no-go criteria written and signed by the executive project sponsor
• Open defects triaged, with severity 1 and 2 items closed or covered by accepted workarounds
• Integrations tested end to end: EDI, banking, payroll, e-commerce, warehouse and tax engines
• Security roles and segregation-of-duties conflicts reviewed
• End-user training complete and a super user named in each department
• Cutover date chosen to avoid month-end and quarter-end close
• Hypercare rota, escalation path and ticket queue agreed

UAT sign-off

• Every business process scenario executed with evidence attached
• Failed scenarios retested, with defects closed or formally deferred
• Sign-off collected from each process owner, not one blanket approval
• UAT scripts, results and defect history saved in a location that will outlive the project team

Data migration and cutover plan

• At least two mock cutovers completed, with timings recorded
• Open receivables, payables, inventory, open orders and trial balance reconciled to the legacy system
• Transaction freeze windows communicated to customers, vendors and carriers
• Rollback plan and point-of-no-return decision documented
• Cutover runbook with named owners and timestamps for every task

Records preservation: the added step

• Legacy system described: modules in use, years of transactions, legal entities, custom tables and where attachments are stored (metadata only)
• Legacy access decision made and dated: read-only instance, archive database, full export or decommission
• Legacy license, hosting and support end dates written into the plan
• Project records listed: test logs, issue and defect logs, decision log, RAID log, design documents, configuration workbooks and data mapping files
• A named owner for each record set after the project team disbands
• Check of where the project workspace lives, in the client's tenant or the implementation partner's
• CEO or CFO told what these records are before anything is deleted

Go-live day

• Final balances loaded and signed off by the controller
• First transaction processed in each critical flow: order, ship, invoice, receive and pay
• Command center staffed and the issue log open

Hypercare and post go-live support

• Daily ticket triage with severity and owner
• First month-end close completed in the new system
• Hypercare exit criteria met and support handed to the steady-state team
• Legacy retirement date confirmed against the records-preservation decisions

How to use the results

Which ERP records are worth keeping readable

The value is in records that show work with outcomes: a request, the steps and approvals, and how it ended.

In CPG and distribution, the legacy system's customer deductions records are a strong example of resolved disputes. Asset-heavy clients often keep work orders in the ERP or a linked maintenance system, as described in fleet maintenance records. And in specialty contractor roll-ups, each add-on arrives with its own legacy system to consolidate, which multiplies both the risk and the opportunity.

When to introduce the client to SourceX

The right moment is after the records step shows depth and before the decommission date. Raise it with the owner, CEO or CFO, not the project team. Many clients will not fit. SourceX looks for US companies that reached 50+ full-time employees at peak (contractors excluded), have operated for several years with documented records, own the rights to what they would license, and have an executive willing to sponsor it. The who qualifies page has the full baseline, and the data inventory builder helps the client list systems and years without exporting anything.

You make the introduction; SourceX and the client handle qualification, inventory, rights review and contracting. You never export, upload or describe client records. Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, paid only after the buyer pays and SourceX receives its fee; no reward is guaranteed. The page for ERP consultants covers how implementation partners handle client consent and their own firm's fee policies.

Red flags at go-live

• The legacy decommission date falls before hypercare exit, leaving no time to inventory.
• The project workspace sits in the implementation partner's tenant and is scheduled for deletion when the engagement closes.
• Archived legacy data exists only in a proprietary backup format nobody on staff can read.
• Attachments are being purged to save storage during migration.
• The legacy records mainly belong to the client's customers or were produced under client contracts.

Next step

Add the records-preservation group to your next cutover plan. If a client's legacy system and project logs look substantial, register as a partner before the decommission date and send the CFO your referral link.