Manufacturing Data Migration Checklist: BOMs, Stock and Suppliers

Moving from spreadsheets or a legacy accounts package to a cloud MRP system is mostly a data project wearing a software hat. The demo screens always look tidy. What decides whether your first week of production runs smoothly is the quality of the records you load on day one.

This checklist covers the three areas that cause the most trouble for UK manufacturers: bills of materials, stock and suppliers. It also sets out the stages of a migration and the validation steps that catch mistakes before they reach the shop floor.

What manufacturing data migration actually involves

Manufacturing data migration is the transfer of production data, inventory logs and maintenance records between systems. In its broadest sense, data migration is the process of moving data between storage systems, applications or formats. It is normally a one-off exercise rather than a routine task, though it almost always includes preparing, cleansing and reconciling the data along the way.

Four types of data migration are commonly described: storage migration, database migration, application migration and cloud migration. For a typical manufacturing SME, the practical work sits in the last two. You are moving from an application such as a legacy desktop system into a cloud platform, and the database underneath changes at the same time. That double change is why data quality matters so much. There is no longer a familiar system to fall back on when a record looks wrong.

Why so many manufacturing migrations go wrong

Industry guidance from ERP provider MIE Solutions puts the failure rate for manufacturing ERP data migrations at around 75%. That figure is worth sitting with. Failure rarely means the software is broken. It usually means the data arrived incomplete, duplicated, or in the wrong unit of measure, and nobody spotted it before the first works order was released.

The same patterns turn up again and again on projects that struggle:

• No single person owns the data, so gaps sit between departments.
• Source records are spread across spreadsheets, an old system and the finance ledger, with different part numbers in each.
• Nothing is frozen during the final export, so the file changes after it is signed off.
• Testing uses a sample of tidy records rather than the real, full file.
• Suppliers, lead times and stock balances are treated as an afterthought once the items and BOMs are in.

The three stages of an ERP data migration

ERP migration programmes are usually split into three stages, and the sequence matters more than most teams expect. Configuration data goes first because everything else depends on it.

• Stage one, configuration data: company details, chart of accounts mapping, units of measure, warehouses and locations, tax codes, users and permissions. Get this wrong and every later import fails validation.
• Stage two, master data: items, BOMs, routings, work centres, suppliers, customers, price lists and opening stock balances.
• Stage three, open and transactional data: open sales orders, open purchase orders, works orders in progress, outstanding invoices, goods received not invoiced, and whatever slice of history you decide to bring across.

Keep the stages separate in your plan and in your testing. If you load stock balances before your units of measure are settled, you will reload them twice.

Checklist part one: BOMs and routings

Bills of materials carry the most risk of any data group, because an error here quietly corrupts costing, purchasing and production planning at the same time. Work through these points before you load anything.

• Every manufactured item has a BOM, including the ones that were never formally documented.
• Every component resolves to an active item record with a consistent unit of measure.
• Quantities per assembly are correct, including decimals rather than rounded figures.
• Scrap and yield percentages are included where they are used.
• Multi-level structures are preserved, with sub-assemblies kept as sub-assemblies rather than flattened into one list.
• Phantom and non-stock items are flagged correctly.
• Routings, work centres and standard times are mapped, with operations in the right sequence.
• Revision control and effectivity dates are retained if your products are revised over time.
• Obsolete BOMs are archived rather than loaded, so they cannot be picked up by planning.
• Co-products and by-products are mapped, which matters most in food, drink and chemical production.

Common BOM mistakes to catch before loading

Watch for multi-level structures that collapse during a spreadsheet export, duplicate part numbers with different descriptions, components that have no supplier or no cost attached, and items measured in kilograms in one file and grams in another. None of these are dramatic on their own. Together they produce a system that cannot be trusted, which is worse than a system that is obviously empty.

Checklist part two: stock and inventory

Stock balances are the numbers your team will check first, usually on the morning of go-live, so they need to be defensible.

• Current on-hand quantity for every item, by warehouse and bin location.
• A stock valuation method that is consistent between the old and new system.
• Batch, lot and serial numbers, including expiry dates where traceability is required.
• Conversion factors for items bought in one unit and consumed in another.
• Reorder points, safety stock levels and minimum order quantities.
• Quarantined, rejected, obsolete and consignment stock held separately rather than mixed into available stock.
• Work in progress valued and recorded, not left out of the opening balance.
• A stock take or agreed cut-off date, with movements after that date handled deliberately.

Handling stock you cannot verify

In practice, the physical count rarely matches the system on the first attempt, and chasing every difference can delay go-live indefinitely. A workable approach is to migrate the last verified balance, agree a tolerance for discrepancies, and run a focused count across your highest-value and fastest-moving items in the first few weeks. Document the adjustments as you make them, and agree in advance who can approve a write-off.

Checklist part three: suppliers and purchasing

Supplier records look simple until you realise how much planning depends on them. MRP will suggest orders that cannot be placed economically if lead times and price breaks are missing, which is a quick way to lose the team’s confidence in the new system.

• Supplier names, addresses, contact details, payment terms and currency.
• Lead times recorded per item, not only per supplier.
• Minimum order quantities and price break quantities.
• Purchase price lists with validity dates, plus any agreed discounts.
• Approved supplier status and quality approvals, including certificates where relevant.
• Dual-sourced items identified, so planning knows there is a choice.
• Supplier part numbers cross-referenced against your internal part numbers.
• Open purchase orders and goods received not invoiced, ready for the finance cut-over.

Why supplier data deserves more attention than it usually gets

Supplier part numbers are easy to dismiss as a nice-to-have, but in engineering, electronics and automotive work they are the difference between a buyer finding the right component and guessing. Lead time accuracy has an even bigger effect. A lead time that is out by a fortnight will distort every suggested order date in the system.

The records people forget

BOMs, stock and suppliers get the attention. These items often do not, and they can stall a cut-over just as effectively:

• Customers, delivery addresses and agreed pricing.
• Open sales orders and outstanding despatches.
• Works orders already in progress, with operations completed so far.
• Maintenance records, asset registers and calibration dates.
• Quality certificates, inspection records and non-conformance history.
• Document attachments such as drawings, specifications and work instructions.
• User accounts, roles and approval permissions.

Validation: how to prove the data is right

Validation is the part of the project that gets squeezed when time runs short, and it is the part that protects you. A reasonable sequence looks like this:

1. Reconcile row counts between your source files and the new system, so nothing is silently dropped.
2. Compare totals: total stock value, number of active items, number of live BOMs and number of active suppliers.
3. Spot-check a sample of high-value or high-frequency items from item record through BOM to stock balance.
4. Run planning in a test environment and compare the suggestions against what an experienced planner would order.
5. Build and complete a test works order, including material issue and any backflushing.
6. Review key reports such as stock valuation, shortage lists and supplier spend.
7. Get sign-off from the people who own the data, not only from the project manager.

The cut-over freeze and migration tools

Agree a freeze window before the final export, keep the legacy system read-only afterwards, and decide in advance what happens if something needs to be reversed. Some platforms and add-ons include purpose-built migration tools rather than plain import templates. One documented example is the Cim 200 manufacturing migration tool, which handles a quick handover of works orders from Sage 200 Manufacturing. Most cloud MRP systems instead rely on spreadsheet imports for items, BOMs, suppliers and stock. Whichever route you take, keep the mapping document that shows each source column and where it ends up.

Getting help with a manufacturing data migration

Smart Manufacture is a UK-based ERP and MRP consultancy and the UK’s leading partner for the MRPeasy platform. Implementation work includes data migration alongside system setup and team training, with support that continues after go-live. If your BOMs, stock records and supplier lists are sitting in a mixture of spreadsheets and an ageing system, a short conversation about sequencing and validation is usually enough to turn a worrying project into a manageable one.

Frequently Asked Questions

How long does a manufacturing data migration take?

It depends on the size and state of your source data. A small manufacturer moving a few hundred items, simple BOMs and a short supplier list can often complete the exercise in a few weeks alongside the wider implementation. Larger businesses with multi-level BOMs, batch traceability and years of history need longer, and the cleaning work usually takes more time than the loading itself.

Should we migrate historical transactions?

Most manufacturers bring across open transactions and a limited slice of history, often the current and previous financial year, because fully closed orders rarely earn their keep in a new system. Check what your accountant requires, and what any traceability obligations demand, before you decide. If you need deeper history, migrate it after go-live so it cannot hold up the main cut-over.

Who should own the data migration?

Ideally someone from operations or supply chain who knows the products, rather than the IT contact alone. That person owns the templates, chases missing values and signs off each data group. Finance should own stock valuation and supplier terms, engineering should own BOMs and routings, and purchasing should own lead times. One named owner keeps the whole thing moving.

Can we clean up our data after go-live?

You can, but it is harder than it sounds. Once production starts, every record you touch has live transactions attached, so corrections ripple into stock, costs and planning. Cleaning items, BOMs and suppliers before loading is far quicker. If something genuinely must wait, note which records are affected and put a short, dated clean-up plan in place.

What if our BOMs only exist in spreadsheets?

This is common among SME manufacturers, so do not treat it as a blocker. Export what you have, then standardise the columns before loading: item code, description, unit of measure, quantity per assembly and scrap percentage. Expect inconsistencies between sheets and resolve them one by one. Spreadsheet BOMs generally need more validation than system exports because nothing enforces the rules for you.