GUIDE · ERP AND MES GO-LIVE
What to check in production data
before an ERP or MES go-live.
Published · ProdCrest
Short answer. Before go-live, fix the things the new system will turn into rules: one product list with a mapping from every spelling used on the floor, part weights and cavity counts that carry a confirmation date, one reason-code list, one unit per quantity and written definitions of good output, scrap and downtime. Migrate only history that has passed the record checks, label it as migrated, and run the old and new records side by side for a period, reconciled per work order, before the old ones are switched off.
Why go-live exposes old data problems
A spreadsheet tolerates variety. One operator types the part number, another types the product name, a third writes the reason for a stop in their own words, and the weekly total still comes out. An ERP or MES does not tolerate that variety: it needs a code that exists in its master, a unit it knows and a reason from its list. Whatever is unclear in the old records has to be decided at the moment of import, usually under time pressure, and the decisions then sit inside the new system as if they were facts.
Migrated history also becomes the baseline. The first months after go-live are compared with it, so an error carried over from the old records later looks like an improvement or a loss that never happened.
A synthetic example: what a pre-go-live check finds
The ProdCrest demo uses synthetic data: an invented moulding plant with four machines, eight products, three shifts and four weeks of records (334 shift-log rows, 112 ERP work orders). Every figure below was produced by that dataset; none is a customer result. Read as preparation for loading those records into a new system, the checks show what would have to be decided first:
| Finding | In the synthetic records | Decision before go-live |
|---|---|---|
| Product identity | 106 of 334 rows name the product instead of the part number; 8 products appear under 16 different texts | One product master and a mapping table from every historical spelling |
| Part weights | 2 of 8 products have a weight last confirmed more than 12 months before the period | Re-weigh and date the weights that convert kilograms to pieces |
| Counts | 21 rows hold a counter reading (shots) where pieces were expected | Record which quantity each field holds, and the active cavity count |
| Downtime reasons | 27 distinct reason texts in two languages for five classes; 13 rows fit no class (cleaning, 5S, meetings, training) | One code list, and a written rule on whether planned activities count as downtime |
| Dates | All dates written day first; 119 rows have a day of 12 or less and could be read either way | One date format for the import, confirmed from the whole file |
| Completeness | 4 duplicated rows and 6 shifts with no row | Repair or list them before the history is loaded |
| Timing | Work orders are confirmed the morning after production; 2 were confirmed after the period closed | A period-close rule the new system enforces |
| Agreement | 17 of 112 work orders differed between shift log and ERP before the checks | A tolerance and a reconciliation routine for the parallel run |
None of these is unusual, and none needs software to find. What matters is that each one is decided before the import, by the people who know the floor, rather than during it by whoever runs the load.
The checks, step by step
1. One master for each thing that will become a code
Products, machines, reason codes, defect codes and units each need one list. Build a mapping table from every spelling found in the old records to the code it means, and keep it as a file the team can read. Rows that map to nothing stay visible as exceptions; they are not given the nearest code to make the import pass.
2. Confirm the physical facts in the master
Part weights, cavity counts, cycle times and machine capacity drive every conversion and plausibility check the new system will make. Give each value the date it was last confirmed, and re-check the ones that are old. In the synthetic plant, the two stale weights were both lighter than the parts made today, so converted scrap for those parts was overstated; the scrap guide shows the effect. Record the cavity count that is actually running, not only the tool's nominal one; the shot-count guide explains why.
3. Write the definitions down before configuration
Agree in writing what good output means (passed inspection, or everything made), the unit for scrap, the downtime classes and what counts as downtime, where a shift starts and ends, and how rework is booked. These choices become settings in the new system; if they are not written down first, they are made implicitly by whoever configures it.
4. Decide what history to migrate
Load only a period that has passed the record checks and been reconciled, and mark it as migrated. Keep the raw exports archived, unchanged, so any migrated figure can be traced back. Opening values, such as stock or open work orders, need their own sign-off, because they cannot be checked against production later.
5. Run the record checks on that history
Date format, product identity, duplicates, missing shifts, units, plausibility and a second-source cross-check: the seven checks for production records describe each one. Repair what has a clear correction; list the rest with a reason.
6. Plan a parallel period
Keep the old record running for a few weeks after go-live and compare it with the new system per work order, with a tolerance agreed in advance. The reconciliation guide sets out the method. Switch the old record off when the differences are explained, not when the calendar says so.
7. Give the exception list an owner
Every unmapped code, stale weight and unexplained difference needs a person who closes it and a date. An exception list without an owner tends to become the permanent explanation for numbers nobody trusts.
Limits
These checks show whether the data is consistent enough to load and compare. They do not say whether the new system is configured well, whether people will record into it correctly, or what the go-live will change in the plant. Those answers come from the floor, the project team and the first weeks of use.
See the checks applied in the interactive demo. ProdCrest can run a production data review on your exports inside your environment before a go-live, or support the parallel period as part of operations support. Describe your situation.