ERP Data Readiness: The Hidden Complexity of "Clean Data"

2026-09-24

Executive Summary

• Data migration is not a technical problem — it is a business problem.
• Poor data quality does not disappear when you move it into ERP. It becomes the foundation of every report and decision the system produces.
• There are four common categories of data quality issues that most organizations discover only during migration preparation.
• The cost of fixing data problems after go-live is substantially higher than addressing them before. Most ERP projects do not allocate enough time or resources to this step.

Why Data Migration Is More Consequential Than It Appears

In an ERP project, data migration is the process of moving data from existing systems — spreadsheets, standalone accounting software, paper records, internal databases — into the new ERP.

The description sounds straightforward: export data, clean it, load it into the new system.

In practice, data migration is widely recognized as one of the highest-risk components of an ERP implementation, and one of the most systematically underestimated in terms of time and effort required. Many projects run over budget and schedule not because of technical problems with the software, but because the organization’s data was more complex and lower quality than anticipated.

More fundamentally: poor data does not get cleaned by moving it into ERP. It becomes the foundation of every inventory alert, every purchase order, every financial report the system generates. A single incorrect record in master data can produce cascading errors across operations for months after go-live.

What Data Does ERP Actually Need?

Understanding why data readiness is difficult starts with understanding what ERP actually requires.

There are two main categories:

Master data — the organizational foundation

Master data describes the entities in the business — things that do not change frequently but are used in every transaction:

• Product catalog / SKUs: codes, names, units of measure, product groups, technical attributes, pricing, bill of materials (for manufacturing).
• Vendors: legal name, tax identification, payment terms, bank details, contact information.
• Customers: legal name, tax identification, payment terms, shipping addresses, credit limits.
• Chart of accounts: account structure, cost allocation methodology.
• Organizational structure: entities, warehouses, cost centers, departments.

Master data must be accurate before the system goes live. If it is not, every transaction processed afterward is affected.

Transactional data — historical records

Transactional data covers what has happened — orders, invoices, inventory movements, accounting balances. Not all historical transactional data needs to be migrated; many projects select a cutover date and carry forward only opening balances, not the full transaction history.

Deciding how much historical data to migrate is a business decision, not a technical one, and it significantly affects the volume of preparation work required.

Why Existing Data Is Rarely Actually Ready

These are the most common data quality problems that ERP projects surface during migration preparation:

Duplicates and inconsistency

The same vendor exists as two or three separate records in the system — created by different employees at different times. The same product is referred to by different names in different departments.

This is not an unusual situation. In many SMEs, vendor master data may contain a substantial proportion of duplicate or outdated records — formed naturally in the absence of clear master data governance processes.

Incomplete records

Records exist but are missing fields that ERP requires. A product has a name and a price but no standardized unit of measure. A vendor has a name but no tax identification number or payment terms. A customer has a contact but no formally classified shipping address.

These look like minor details until ERP refuses to process a transaction because a mandatory field is empty.

Data scattered across multiple systems and sources

The product list used by sales differs from the product list used by the warehouse. Inventory figures in the accounting system differ from figures in the warehouse management tool. Customer information exists partly in a CRM, partly in spreadsheets maintained by individual sales staff, and partly in the accounting software.

The question is simple but rarely has an immediate answer: which version is correct?

Inconsistent definitions

This is a subtler problem. For example: “inventory” in the warehouse team’s system might include goods in transit, while “inventory” in accounting only counts goods physically received. “Customers” in the sales system might include prospects, while ERP should only contain entities with actual transaction history.

When these definitions are not resolved before migration, data enters ERP in a form that no one fully understands — and the problem only surfaces when reports start producing numbers that no one can explain.

Inventory records that do not match physical reality

This is a particularly serious issue for manufacturing companies. If recorded inventory does not reflect what is actually on the floor, loading that data into ERP means building the operational system on a false starting point.

It is not uncommon for organizations to discover significant inventory discrepancies for the first time during ERP data migration preparation — after years of operations without a full physical count and reconciliation.

The Real Cost of Inadequate Data Preparation

Data migration problems rarely appear as explicit risks in a project plan. They surface as other costs and consequences:

Timeline delays. Data cleaning taking longer than expected is one of the most common reasons go-live dates are pushed. Every week of delay carries personnel costs, implementation fees, and opportunity costs.

Business decisions made on wrong data. After go-live, if inventory, accounts receivable, or cost reports are inaccurate, leadership either stops using ERP reports for decisions — reverting to previous methods — or makes decisions based on incorrect data. Neither outcome is acceptable.

Post go-live correction is substantially more expensive than pre-migration preparation. Fixing master data after the system is live is significantly more complex than cleaning it before migration, because each incorrect record may already be referenced in multiple real transactions.

Loss of confidence in the system. When users discover that ERP reports are unreliable, they stop using the system as a decision-making tool. This is one of the most difficult outcomes to recover from after go-live, because it requires rebuilding both the data and the organizational trust in the system simultaneously.

Data Readiness Checklist — Before Starting ERP

Questions to assess your current data readiness:

Product catalog / SKUs:

• Is the product catalog maintained centrally, or scattered across multiple sources?
• How many product codes exist that are no longer in use but remain in the system?
• Does each product have complete information: unit of measure, product group, pricing, and BOM where applicable?

Vendors and customers:

• Are there duplicate records?
• Is mandatory information (tax identification, payment terms) complete for all active records?
• Who is responsible for maintaining and updating these records?

Inventory:

• Is inventory on the books reconciled against physical counts on a regular basis?
• What is the current level of discrepancy?
• When was the last complete physical inventory count conducted?

Accounting:

• Is the chart of accounts designed to support the reporting requirements of the business?
• Are opening balances ready to migrate?

Data governance:

• Is there a clear process for adding, modifying, and deactivating master data records?
• Is there a named person or team accountable for data quality?

If several of these answers are “no” or “uncertain,” that is a signal to allocate significantly more time and resources to the data preparation phase — before the ERP project formally begins.

Next in the series: Scope Creep in ERP — When the Project Keeps Growing Beyond the Plan

→ Complete the ERP Readiness Assessment

→ Explore ERP Readiness Solutions

For context on process standardization as a prerequisite for data readiness, see: Process Standardization Before ERP

To understand scope management in ERP projects, see: ERP Scope Creep — When the Project Keeps Growing Beyond the Plan

For the foundational perspective on why ERP projects fail, see: Why ERP Projects Fail

This article is part of a series on ERP readiness for manufacturing SMEs.

Related articles:

• Why ERP Projects Fail — and What the Software Cannot Fix
• Process Standardization Before ERP: The Step Most Companies Skip
• Scope Creep in ERP: When the Project Keeps Growing