ERP Migration Data & Integrations Checklist

Before an ERP migration, you must document every data source that feeds the system and every integration that connects it to other applications. This includes master data, transactional data, configuration data, and the APIs, file transfers, and middleware that move information in and out. Missing even one integration can halt operations after go-live, so a complete inventory is your first and most critical step.

Why Documentation Matters Before Migration

An ERP migration is not just a software swap; it is a data and process transformation. The new system will only be as good as the data you put into it and the connections you re-establish. Without thorough documentation, you risk:

• Data loss – unmapped fields or forgotten tables never make it to the new system.
• Integration failure – a custom API that was never documented breaks silently, causing order or payment errors.
• Process disruption – if you don’t know which system owns the “customer master,” you may end up with duplicates or conflicting records.
• Cost overruns – rediscovering integrations during the project adds weeks of work and consultant fees.

Think of documentation as the blueprint for your migration. It tells you what to extract, how to transform it, and where to load it – and it tells your integration team what to reconnect and test.

Master Data to Document

Master data is the core business entities that are shared across processes. You need to document the source system, the fields, the format, and the owner for each of these:

• Customer master – names, addresses, tax IDs, payment terms, credit limits, sales reps.
• Vendor master – supplier names, remit-to addresses, W-9 or tax info, purchasing terms.
• Product/Item master – SKUs, descriptions, units of measure, costing method, barcodes, category hierarchies.
• Chart of accounts – the full COA with account numbers, descriptions, and whether it maps to the new ERP’s structure.
• Fixed assets – asset IDs, depreciation methods, useful lives, net book value, location.
• Employee master – HR data if the ERP includes HR, or if it syncs with an HRIS.
• Inventory balances – on-hand quantities, locations, lot/serial numbers, and valuation.

For each master data entity, document the source of truth. For example, is the customer master in the CRM and synced to the ERP, or is the ERP the source? This determines which system you extract from and how you handle conflicts.

Transactional Data to Document

Transactional data is the history of business events. You don’t always migrate all of it – often you only need open items and a few years of history – but you must document what exists so you can decide.

• Open sales orders – order number, line items, quantities, promised dates, status.
• Open purchase orders – PO number, vendor, line items, expected receipts.
• Open invoices and payments – AR/AP balances, due dates, payment history.
• Inventory transactions – receipts, issues, adjustments, transfers for the last 1-3 years.
• Production history – work orders, BOMs, routings, labor and machine time.
• Financial history – general ledger entries, budgets, and prior-year actuals.

For each, document the volume (row counts), the date range, and the retention policy. This helps you estimate migration time and storage, and it helps your data cleansing team know what to scrub.

Configuration and Reference Data

Beyond master and transactional data, you have configuration data that defines how the system behaves. This is often the hardest to document because it lives in setup screens, not in tables.

• Numbering sequences – order numbers, invoice numbers, PO numbers, and their current next values.
• Approval workflows – who approves POs, invoices, and expense reports, and under what thresholds.
• Tax codes and rules – tax jurisdictions, rates, and how they map to products and customers.
• Shipping and carrier setups – carrier accounts, service types, and default packaging.
• User roles and permissions – who has access to what, so you can replicate in the new system.
• Custom fields and tables – any customizations in the old ERP that have business logic attached.

Documenting configuration is not just about copying settings; it’s about understanding why they exist. That context helps you decide whether to carry them forward or redesign.

Integrations and Data Flows

Integrations are the connections between the ERP and other systems. You need to document each one with enough detail for a developer to rebuild it.

• System name and owner – e.g., Salesforce, Shopify, a bank, a warehouse management system.
• Direction and frequency – is it real-time, daily batch, or event-driven? Does data flow one-way or both ways?
• Protocol and format – REST API, SOAP, SFTP, flat file, JSON, XML, or a middleware like MuleSoft or Boomi.
• Data mapping – which fields in the source map to which fields in the target, including any transformations.
• Error handling – what happens when a record fails? Is there a retry, a queue, or a manual review process?
• Dependencies – does the integration rely on a specific ERP version or a custom endpoint?

Create a simple table with columns: system, direction, frequency, protocol, data entities, owner, and current status. Even a spreadsheet is better than nothing. The key is to capture the contract of each integration, so you can test it against the new ERP.

How to Build Your Documentation

Start early and involve the right people. Here is a practical process:

1. Inventory systems – list every application that touches the ERP. Interview department heads and power users to find shadow systems (e.g., a department’s Access database).
2. Catalog data – for each system, list the data entities that interact with the ERP. Use data profiling tools to see row counts and data quality.
3. Map integrations – draw a diagram showing data flows between systems. Note the protocol and frequency for each line.
4. Document mappings – for each integration, create a field-level mapping document. Include source field, target field, transformation logic, and any lookup tables.
5. Store centrally – put everything in a shared repository (SharePoint, Confluence, or a simple folder) with version control.
6. Review with stakeholders – validate the documentation with business owners and IT before you start extraction.

The goal is not to create a perfect document, but to create a usable one that answers the questions your migration team will have.

Common Pitfalls and How to Avoid Them

Even with good intentions, teams often miss things. Here are the most common gaps:

• Forgotten custom code – old ERPs often have custom scripts, triggers, or reports that are undocumented. Search for them early.
• Data quality issues – documenting data is not enough; you must also note duplicates, missing values, and inconsistent formats. Plan for cleansing.
• Integration endpoints that change – if you document an API but the vendor changes it before go-live, your documentation is stale. Note the version and review it during testing.
• Assuming the new ERP works the same – even if you map fields, the new system may have different validation rules or required fields. Document those differences.
• Not documenting the ‘why’ – a field may exist only because of a legal requirement or a specific business rule. If you don’t capture that, you might drop it and break compliance.

To avoid these, schedule documentation reviews at key milestones and involve a mix of business and technical staff.

Frequently Asked Questions

How far back should I migrate transactional data?

Most ERP migrations only bring open items (open orders, open invoices, open POs) and 1-3 years of history for reporting. Older data can be archived and accessed via a reporting tool if needed. Document the retention policy and get sign-off from finance and operations on what to include.

What if I don’t have documentation for an old integration?

If an integration is undocumented, you have three options: trace the code to reverse-engineer it, check logs to see what calls are being made, or ask the vendor for API docs. If the integration is critical and can’t be documented, consider rebuilding it from scratch with proper documentation in the new environment.

Should I document integrations that are being retired?

Yes, but mark them clearly. Even if a system is being decommissioned, you need to know what data it holds and whether it needs to be archived. Also, a “retired” integration may still have dependencies you don’t know about.

How do I document a middleware integration?

For middleware (like MuleSoft, Boomi, or SAP PI), document the flow name, the source and target systems, the transformation logic, and the error handling. Include the middleware’s own configuration, such as connection pools and retry settings. The same principles apply as for direct integrations.

Who should own the documentation?

Ideally, a data architect or integration lead owns the overall documentation, but each system owner should contribute details about their system. Assign a single person to maintain the central repository and ensure it stays current.

Can I use automated tools to discover integrations?

Yes, there are data mapping and integration discovery tools that can scan your network and databases to identify data flows. However, they won’t capture the business context, so you still need human interviews and review. Use tools as a starting point, not a replacement.

Related

• Apple Watch Patent Ban: Is It Still in Effect?
• Apple Watch Ultra Night Mode: Does It Turn Red?
• Google’s AMIE Study: What It Shows About Primary Care