Preparing Inventory for an ERP Upgrade
ERP READINESS DECISION
Decide what must be clean, migrated and reconciled
An ERP upgrade is not a file import. Define the future item and location model, choose the history and open transactions required, clean data at source and prove opening quantity and value through a rehearsal.
01 – SCOPE
Choose the migration boundary
Separate master data, open documents, opening balances, selected history, attachments and records that should remain archived.
02 – CLEAN
Fix the operating model
Resolve duplicates, units, locations, status, tracking, valuation groups and ownership before mapping fields.
03 – PROVE
Reconcile the cutover
Tie source, transformed file, imported records, physical stock and finance totals at the agreed cut-off.
Rehearse one complete inventory cutover
Migrate representative items, locations, open supply and demand, opening quantity and value into a test company, then run normal and exception transactions.
Preparing inventory for an ERP upgrade means deciding which records the new system must operate from day one, cleaning the business rules behind those records, and rehearsing a reconciled cutover. Copying every legacy field and transaction can import years of duplication; migrating too little can remove the evidence needed for orders, stock, warranty, traceability and finance.
Use the item-master cleanup guide before mapping fields, the clean stock-count guide for opening quantity, and the inventory systems service for the end-to-end migration and operating model.
1. Define the future-state inventory model
Start with how the new ERP should represent items, variants, units, warehouses, locations, lots, serials, expiry, ownership, valuation groups and replenishment. Do not let the legacy export define the design by default. A code may currently combine product, supplier and location because an old spreadsheet needed it; the new model may need those as separate fields.
| Data group | Migration decision | Acceptance evidence |
|---|---|---|
| Items and variants | Active, inactive, replacement and duplicate rules | Approved item register and mappings |
| Units and packaging | Base, purchase, production and sales conversion | Conversion tests with representative transactions |
| Locations | Warehouses, bins, transit, quarantine and virtual states | Location register and ownership |
| Open documents | Purchase, sales, transfer, production and return states | Source-to-target document reconciliation |
| Opening inventory | Quantity, cost, lot or serial and cut-off | Count, valuation and ledger tie-out |
| History | Operational history to migrate, archive or summarise | Access and retention decision |
2. Create a migration decision register
For each data object, name the source, owner, target field, transformation, validation, load order and reconciliation total. Mark whether the record will be migrated, archived or retired. Microsoft documents Business Central templates and configuration packages for records such as items, locations, units, posting groups and item journal lines. The available import tool does not decide which source values are correct.
3. Clean master data before extraction
- Choose the surviving item for each duplicate and retain legacy aliases for search and history.
- Separate product identity from description, supplier code, barcode and channel title.
- Confirm base units and every purchase, production and sales conversion.
- Retire unused locations and map balances before removing them.
- Complete mandatory category, tax, posting, tracking and replenishment fields.
- Resolve negative, zero-value and inactive items that still have quantity or open demand.
- Assign a business owner and approval date to the clean dataset.
4. Decide how much history to migrate
Many SMEs need clean opening balances and open operational documents more urgently than every closed transaction in the new ERP. Keep history when it supports warranty, traceability, customer service, regulation, analytics or audit. Otherwise, use a controlled archive that remains searchable and read-only. Microsoft migration guidance distinguishes master data, transactional data, opening balances and setup data; use those categories to make the decision explicit.
5. Control open orders and movements
List open purchase orders, receipts not invoiced, sales orders, picks, shipments not invoiced, returns, transfers, production orders and stock in transit. Decide whether each will be completed in legacy, cancelled and recreated, or migrated in its current state. Avoid counting a dispatched transfer at the source and importing it again at the destination. Freeze or tightly log changes during the final extraction.
6. Prepare opening quantity and value
Set a cut-off date and count plan. Reconcile physical quantity to the legacy subledger, resolve material differences, and let finance approve the opening cost and ledger value. Preserve item, location, lot or serial detail required by the new system. An opening journal that balances financially but loses location or tracking detail will block operations after go-live.
7. Build transformation and validation rules
| Rule type | Example | Validation |
|---|---|---|
| Format | Trim spaces and standardise dates | Reject malformed values |
| Mapping | Legacy warehouse A becomes CT-CENTRAL | Every active code maps once |
| Default | Apply approved posting group by item category | Owner reviews every defaulted record |
| Derivation | Create variant from controlled attributes | Compare record counts and combinations |
| Exclusion | Do not migrate obsolete zero-balance items | Archive list retained |
| Relationship | Item unit and barcode attach to surviving item | No orphan child records |
8. Rehearse in the right load order
Load setup and reference records before items, then locations, units, suppliers, customers, open documents and inventory balances in the dependency order required by the ERP. Microsoft notes that import templates should retain their expected columns. After loading, test receiving, transfer, production where relevant, sale, return, adjustment and close. Do not accept a test because the import reports no errors.
9. Reconcile every migration layer
Compare source record count and control totals to the extracted file, transformed file and imported system. Reconcile item quantities by location, inventory value by approved grouping, open order quantities, lots or serials and general-ledger control accounts. Sample individual records in addition to totals. Two errors can offset in a total while leaving the wrong stock at the wrong location.
10. Plan cutover and rollback
Write the final extraction time, transaction freeze, count, transformation, load, validation, approval and release sequence. Assign owners and decision deadlines. Define what would stop go-live and how the team would restore the legacy operating path. Keep both systems from accepting live transactions simultaneously unless a controlled coexistence design exists.
Worked rehearsal
A distributor migrates fifty representative items across two locations into a test company. The sample includes alternate units, a duplicate, an inactive item with stock, a partially received purchase, an allocated sale, an open transfer and a serialised product. The first load balances in total but places transfer stock at both sites. The team corrects the state mapping, reruns from a clean test company and then proves receiving, transfer, sale, return and valuation. That rehearsal is more valuable than a successful raw import.
Sources checked
- Microsoft Learn: Import business data from other finance systems
- Microsoft Learn: Migrate data to Business Central
- Microsoft Learn: Changing from a QuickBooks app to Business Central
Reviewed by
Mitrend Digital editorial team
2026-07-17
Evidence used for this page
Reviewed against current Microsoft Business Central data-import and migration guidance. Includes an original migration decision register, reconciliation pack and cutover rehearsal.
Turn the guide into a practical next step
This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.
