Master Data Go-Live Cutover Checklist

0%

0 of 38 items complete

18 critical items still open - these are the highest-risk gaps.

Download checklist:

Scope and ownership

Every master data object in scope is listed with a named business ownerCRITICALCut-off rules define which records migrate (active, open, or transacted in the last N months)CRITICALA data steward is assigned to each object for the cutover windowDecisions on obsolete and inactive records are signed off by the ownerLegal and retention needs for archived data are agreedThe cutover calendar shows freeze dates for master data changesCRITICAL

Cleansing and standards

Duplicate vendors, customers and items are identified and resolvedCRITICALMandatory fields are populated in the source for all in-scope recordsCRITICALCountry, currency and unit of measure values are mapped to controlled listsPart numbering and naming conventions are applied or crosswalkedAddresses, tax IDs and bank details are validatedPlaceholder values (TBD, N/A) are removed or justifiedItem classification and product group assignments are reviewed

Mapping and transformation

Field-level mapping document exists for every object and is approvedCRITICALValue mapping tables (status, type, group codes) are signed off by ownersCRITICALKey mapping from old to new IDs is stored and preserved after go-liveCRITICALDefault values for new mandatory target fields are agreedUnit of measure conversions are tested for every item with more than one unitTransformation rules are documented and version controlled

Load rehearsals and reconciliation

At least two full mock loads completed with production-scale volumesCRITICALLoad duration measured and fits inside the cutover windowCRITICALRecord counts reconcile between source, staging and target for every objectCRITICALError logs reviewed and each error type has a fix or an accepted exceptionSample records are compared field by field against the sourceBOMs and routings validated, including component and work center referencesCRITICALOpen balances such as inventory, open POs and open sales orders tie to the ledgerCRITICALLoad order respects dependencies (organisation, items, then BOMs, then transactions)

Business validation

Key users test real scenarios against migrated data in a test clientCRITICALProcure to pay and order to cash run end to end with migrated mastersCRITICALPlanning run produces plausible results with migrated item and BOM dataReports used for month end return expected figuresData owners sign the data readiness certificateCRITICAL

Cutover and after go-live

Master data freeze is communicated and enforced in the source systemCRITICALDelta load procedure is defined for changes made after the last mock loadRollback plan exists and has been walked throughHypercare team covers master data defects for the first weeksGovernance process and request forms are live in the new ERPCRITICALLegacy key cross-reference is available to support and finance

Do not go live with any open critical item. Non-critical items may carry a documented risk acceptance signed by the data owner, but each one needs an owner and a date.

Get a second pair of eyes on your cutover data

Optional: send us your mock load results and we will review reconciliation gaps.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Work through the groups in order and tick items as they are completed with evidence, such as a signed mapping document or a reconciliation report. Critical items are the ones that, if missed, stop the business on day one, so treat any open critical item as a go-live blocker. Share the list with the data owners, because many items need their signature. Review it at each mock load and again 72 hours before cutover, and export the final status as the readiness record for the steering committee.

Why rehearsals matter

A mock load is a full dress rehearsal of extraction, transformation and loading with production volumes. Two rehearsals is a practical minimum: the first finds mapping and data errors, the second proves that fixes work and that the load fits the window. Reconciliation after each load should compare record counts, control totals such as inventory value, and a sample of records field by field. Document every exception and its resolution, since the same pattern will recur in the final load.

Load in dependency order, from organisational data to items to BOMs
Reconcile counts and values, not counts alone
Time every load step against the cutover window
Keep the old-to-new key map permanently

Reading your score

Count completed items against the total, then check critical items separately. A project at 90 percent complete with three open critical items is not ready, while one at 85 percent with all critical items done and risks accepted may be. Use the score to focus the last two weeks: concentrate on mapping approval, reconciliation and business validation, which are the groups that most often slip. Repeat the score weekly so that trend and risk are visible.

Common mistakes

Teams often start cleansing too late, treat the mock load as a technical test only, and let master data change freely in the source after the final extract. Another trap is skipping the old-to-new key cross-reference, which finance and support need for months. Do not rely on counts that match but values that do not, for example an inventory quantity that ties while the cost does not. And never skip business validation: users find problems that technical checks cannot.

Frequently Asked Questions

How many mock loads do I need?

Two full mock loads is a practical minimum for most ERP projects, and three is common for complex or regulated environments. The first finds errors, the second confirms fixes, and the third rehearses the real cutover timing.

Who signs off on master data?

The business data owner for each object signs the readiness certificate, for example purchasing for vendors, sales for customers and engineering for BOMs. IT confirms technical reconciliation but does not own the business decision.

Which records should I migrate?

Migrate active records and those with open or recent transactions, usually defined by a cut-off such as 12 to 24 months of activity. Archive the rest. Agree the rule with owners and legal before cleansing begins.

What is a delta load?

A delta load transfers changes made to the source after the last full extract, such as new vendors or updated prices. It lets you freeze less of the business, but it must be rehearsed like any other load.

If you would like help profiling and reconciling master data for a cutover, our team can run read-only checks against your source and target systems.

Talk to an Expert Explore More Free Tools

Related Tools

ERP Operations

More ERP Migration & Selection tools

See all

Master Data Go-Live Cutover Readiness Checklist for ERP Projects