ERP Data Migration: A Manufacturing Go-Live Checklist

ERP data migration moves agreed records from old systems into a new enterprise resource planning system, with mappings, validation, and business approval. For a manufacturer, success means more than importing a spreadsheet: stores must trust opening stock, production must recognise unfinished jobs, and purchasing must see what suppliers still owe.

This checklist is for owners, operations managers, stores teams, and project leads at small manufacturers in India and other markets. It covers operational data for a system transition, not accounting or tax migration instructions. The aim is to prepare a testable brief and a clear go/no-go decision before staff start recording live work in the new system.

Choose what must move and what can remain accessible

Separate configuration, master records, opening positions, open transactions, and historical reference data. Configuration includes locations, units, statuses, and permissions. Master records include items, suppliers, customers, BOMs, and routes. Opening positions describe the factory at the agreed changeover time. Open transactions describe obligations or work that continue afterward.

Do not assume every old row needs to become a live transaction. Decide what must be operational in the new system and what can remain in a controlled, searchable archive. Test access to that archive and its links from migrated references. Retaining a backup that nobody can open is not a usable history plan.

Keep migration distinct from ongoing ERP integration. Migration establishes the starting state for a transition; integration exchanges subsequent events between systems. Decide where one ends and the other begins so neither repeats the other's work.

Assign owners before cleaning the files

Create a register with one row for each data set: source, business owner, target object, selection rule, extract time, mapping version, validation rule, and acceptance evidence. A technical team can transform a file, but the stores owner must explain stock status and the production owner must explain a partly completed job.

Identify competing sources. An item description in an old ERP, a production spreadsheet, and a supplier catalogue may differ for a reason. Choose the authority for each important field. Put unresolved conflicts in an exception list with a named reviewer rather than filling blanks with plausible defaults.

Give each extract a dated, read-only source copy. Perform cleanup on a working copy and retain the change decisions. This lets the team repeat the import and explain why a value changed without relying on a particular employee's memory.

Protect item identities, units, and dependencies

Preserve a mapping from old identifiers to new identifiers. Check leading zeros, spaces, obsolete codes, duplicate supplier references, and units such as pieces, packs, metres, and kilograms. Similar descriptions do not prove that two items are interchangeable.

Make conversions explicit. If a pack contains ten pieces, record the approved conversion and where it applies. Do not use one conversion for every supplier pack without checking the item. Test decimal precision and dates using actual target formats rather than relying on the spreadsheet's display.

Load dependencies in the sequence required by the target system. An item referenced by a BOM must exist before the relationship can be accepted. Preserve the applicable revision and status, not just a list of components. The BOM and revision-control guide explains the underlying product-definition decisions.

Reconcile opening stock by meaningful dimensions

For an inventory system for manufacturers, an overall quantity is not enough. Compare item, unit, location, lot or serial where applicable, and quality status. Keep held material separate from usable stock. A reservation is usually a claim on existing stock, not another physical quantity to add to it; confirm the definitions in both systems.

Use the main inventory management guide to agree what each stock state means before mapping it. For this migration, document how physical checks and source records establish the opening position and how unexplained differences are resolved.

A matching grand total can conceal a location swap or a duplicated lot offset by a missing one. Compare individual records as well as totals. Keep quantities in compatible units and use approved conversions; adding kilograms and pieces creates a number with no operational meaning.

Rehearse a changeover with movements still arriving

Consider fictional component PL-010. At a test cutoff it has 240 usable pieces and 60 held pieces, giving 300 physical pieces. Of the 240 usable pieces, 40 are reserved for a job. Under this example's definition, 200 are free to allocate. These are test quantities, not a client result.

1. Import the 300-piece opening position with its usable/held split, and represent the 40-piece reservation using the target system's supported method.
2. During the rehearsal gap, record an accepted receipt of 25 pieces and an issue of 15 unreserved usable pieces in a controlled movement register.
3. Apply each gap movement once, with its source reference and target transaction reference.
4. Check the resulting position: 250 usable plus 60 held equals 310 physical pieces. With the reservation unchanged at 40, free-to-allocate stock is 210.
5. Inspect the lot, location, and status detail, then attempt the next normal issue and a held-stock issue using ordinary user permissions.

Do not import opening stock and then replay historical receipts and issues that are already included in that opening figure. Similarly, if the final extract already includes the two gap movements, do not post them again. The test must identify an unambiguous boundary, not just a convenient file timestamp.

Carry remaining obligations, not completed work twice

For open purchase orders, distinguish ordered, already received, cancelled, and outstanding quantities. A fictional line for 100 pieces with 65 received and none cancelled has 35 still due. Preserve the original reference and relevant history while ensuring the new system does not treat all 100 as a new incoming commitment.

For a production job already in progress, identify completed operations, remaining operations, material already issued, remaining WIP, and quality holds. Do not simply recreate the original job as untouched. Agree whether jobs finish in the old system or migrate under a tested target workflow, and verify the next real operation.

The WIP tracking guide helps define these states. Sales-order fulfilment and returns need the same care: retain what remains to be done, with enough history to explain it. Keep related finance decisions with the responsible finance team and implementation specialist.

Test imports in a resettable trial environment

Run a representative data set through the complete loading sequence. Include an unknown item, duplicate identity, invalid unit, obsolete revision, held lot, partially received order, and unfinished job. Every rejected row needs a visible reason and owner; fixing only the rows that happen to import does not resolve the exceptions.

Check the tool's create-versus-update behaviour before retrying. ERPNext's Data Import documentation, for example, describes separate insertion and update workflows and warns against changing the ID used to identify existing records during updates. This is a product-specific example, not a promise that another importer behaves identically.

After a trial, compare record-level results and control totals, then have users perform real tasks on the migrated data. Record loading time, validation time, corrections, and reset steps. A file accepted without errors has passed an import check, not necessarily an operational acceptance test.

Set an explicit go/no-go checkpoint

Agree the final extract boundary, permitted work during the changeover, movement capture, integration pause/restart sequence, owners, and decision time. Require evidence for stock reconciliation, open-work continuity, required references, permissions, and critical workflows before authorising ordinary users to proceed.

Microsoft's go-live checklist calls for repeated migration tests, validation within the available changeover window, and business sign-off. Apply that principle to your own scope and software rather than borrowing a vendor checklist unchanged.

Define the stop conditions and a rehearsed recovery route. Restoring an earlier database after new receipts, issues, or dispatches have occurred can remove those records. Identify who reconciles post-switch activity before any recovery; a backup alone is not a complete return-to-old-system plan.

Bring evidence to the implementation discussion

Your brief should contain the data register, source-to-target mappings, unresolved exceptions, opening-stock reconciliation, open-order/job rules, rehearsal results, and go/no-go owners. Ask a proposed implementation team to demonstrate the difficult records, not just a clean sample import.

Discuss this brief with Ploqy Technologies through the manufacturing software development service. Confirm target-system access, data scope, responsibilities, and acceptance tests before treating migration work as included in a proposal.