"The data isn't perfect, but we'll clean it up after go-live."
It’s a phrase I hear frequently and, in the moment, it sounds reasonable. But six months later? Not so much.
What's interesting is that nobody says it with confidence. It's usually followed by a quick discussion about timelines, budgets, competing priorities, or the pressure to keep the project moving.
That's understandable. Data cleanup is rarely the most exciting part of an ERP project. New capabilities are exciting. Dashboards are exciting. Go-live dates are exciting. Cleaning up duplicate customers that have somehow survived three system upgrades and two acquisitions? That's a tougher sell.
But here's the reality:
Most ERP failures are data failures.
When an ERP project struggles after go-live, the conversation often centers on configuration decisions, user adoption, or implementation mistakes. But in reality, many of the problems started long before the new system was installed.
An ERP data migration doesn't improve data quality. It transfers whatever already exists. Duplicate customers, inconsistent item records, outdated bills of material, inaccurate inventory balances, and poorly structured financial data all move into the new system along with everything else.
That's not a migration strategy. It's a relocation strategy.
In the first article of this series, I explored how organizations can move ERP systems without disrupting operations. One of the most important factors behind that stability is data readiness, because no migration plan can compensate for information the business can't trust.
Unfortunately, this is also where otherwise well-planned ERP projects often begin to lose control.
Whether you’re considering migrating SAP Business One to Business Central or another ERP platform, the outcome depends heavily on the quality of the information being migrated.
A successful ERP data migration doesn't create data problems. It exposes them.
It doesn't create duplicate records, inaccurate inventory, or inconsistent financial structures. It simply forces the organization to operate with them in a more visible and integrated environment.
That's why data preparation deserves the same level of attention as software selection, implementation planning, and cutover strategy. Before configuration begins, organizations need confidence that the information driving daily operations is accurate, consistent, and governed appropriately.
In this article, I'll focus on the hidden work that often determines migration success: cleaning, validating, and governing data before it reaches the new ERP system.
Why data is the real ERP migration risk
When organizations evaluate ERP projects, most of the attention goes to software selection, implementation timelines, and budget estimates. Data tends to receive less attention because it feels like something that can be addressed later.
That's often where the trouble begins.
An ERP data migration doesn't improve the quality of information moving into the new system. It simply transfers what already exists. If item records are inconsistent today, they'll be inconsistent tomorrow. If inventory balances can't be trusted today, a new ERP system won't magically make them accurate.
ERP data migration challenges are often misunderstood because the migration itself isn't usually the source of the problem. It simply exposes existing conditions that may have been hidden by manual workarounds, spreadsheets, tribal knowledge, or years of operating around system limitations.
I've seen organizations spend months evaluating ERP platforms while assuming their data is "good enough." Then testing begins, and suddenly duplicate customers appear, inventory quantities don't reconcile, and financial structures don't support the reporting leadership expected to see.
At that point, the team isn't solving migration problems. They're solving business problems that have existed for years.
This is why ERP data readiness deserves so much attention before implementation begins. Strong data readiness reduces risk in every phase of the project, from configuration and testing through go-live and long-term adoption.
Unfortunately, many organizations discover ERP data quality issues only after significant project work has already started. The later those issues are found, the more expensive they become to correct.
That's why I often encourage leadership teams to think about data the same way they think about financial due diligence. Before making a major investment decision, you want confidence in the information you're using to make that decision. An ERP implementation should be no different.
How clean does our data need to be before an ERP migration?
One of the most common questions I hear is whether data needs to be "perfect" before migration.
The answer is no.
Perfect data doesn't exist.
The better question is whether the data is reliable enough to support day-one operations in the new ERP environment.
For most organizations, that means critical records must be accurate, consistent, and trusted. Teams should be able to create orders, fulfill shipments, manage inventory, and produce reliable financial reporting without immediately questioning the underlying information.
When evaluating ERP data readiness, I typically focus on three areas:
Accuracy
Do records reflect reality?
If inventory quantities, customer records, or item data can't be trusted today, those issues should be addressed before migration.
Consistency
Are records structured the same way?
Organizations often discover multiple naming conventions, inconsistent units of measure, conflicting product descriptions, and duplicate records that have accumulated over time.
The ERP system doesn't care why those inconsistencies exist. It simply imports them.
Ownership
Does someone actually own the data?
Many ERP data quality issues persist because nobody is accountable for maintaining them. When ownership is unclear, data gradually deteriorates regardless of which ERP platform is being used.
This is where ERP master data management becomes important. Effective master data management isn't just about organizing information. It's about establishing standards, accountability, and controls that ensure data remains trustworthy as the business grows.
Master data cleanup strategy
Before migration begins, organizations should focus ERP data cleanup efforts on the records that drive operational and financial performance.
Item master
The item master often creates more migration issues than any other data set.
Areas to review include:
- Naming conventions
- Product descriptions
- Units of measure
- Product categories
- Pricing structures
- Inactive or obsolete items
Customer and vendor records
Customer and vendor data frequently contains years of accumulated duplication and inconsistency.
Common issues include:
- Duplicate records
- Outdated addresses
- Inconsistent payment terms
- Incomplete contact information
Chart of accounts
Financial data deserves the same level of scrutiny.
Organizations should review:
- Account structure
- Reporting requirements
- Departmental reporting needs
- Dimensional reporting strategy
- Legacy accounts that are no longer required
Many companies view ERP data migration as an opportunity to simplify financial structures that have become unnecessarily complex over time.
How long does ERP data cleanup take and what drives the effort?
The honest answer is: it depends.
I've seen cleanup efforts take a few weeks. I've also seen them take several months.
The timeline is rarely driven by technology. It's usually driven by decisions. Data volume matters, but ownership clarity is often the biggest variable. When responsibility is clearly assigned, decisions get made quickly. When ownership is unclear, projects can spend weeks debating standards, approvals, and reporting requirements.
In many cases, ERP data migration challenges are less about technical complexity and more about organizational alignment.
What are the most common data problems that cause ERP migration failures?
The most common ERP data quality issues tend to be surprisingly familiar: duplicate customer and vendor records, inconsistent item master data, inventory inaccuracies, and financial structures that no longer support how the business operates.
These problems rarely appear overnight. Most have existed for years, supported by workarounds, spreadsheets, and institutional knowledge.
An ERP data migration doesn't create those issues. It simply makes them more visible.
Inventory and bills of material are often where that reality becomes impossible to ignore, particularly in manufacturing and distribution environments.
Inventory and BOM integrity: Why inventory truth is non-negotiable
When leadership teams talk about data quality, inventory is often where the discussion becomes very real.
Manufacturers depend on accurate bills of material, routing information, scrap assumptions, and lot or serial tracking. If those records are wrong, production planning, costing, purchasing, and scheduling decisions can quickly become unreliable.
Distribution organizations face a different version of the same problem. Location accuracy, available-versus-on-hand quantities, and backorder logic all influence customer commitments and fulfillment performance. If the inventory record says a product is available when it isn't, the ERP system can only make decisions based on the information it receives.
One of the most common misconceptions during an ERP data migration is that inventory discrepancies will somehow be easier to resolve after go-live. In reality, those discrepancies often become more visible because the new system exposes inconsistencies that were previously hidden by manual processes.
Inventory truth is non-negotiable. Before migration begins, organizations need confidence that inventory records, bills of material, and related operational data accurately reflect how the business actually operates.
Who should own data during an ERP migration project?
One of the fastest ways to create migration risk is to assume data ownership belongs to IT.
It doesn't.
Technology teams may manage the systems, but business teams own the accuracy of the information inside them.
For example, finance should own financial structures and reporting definitions. Operations should own item and inventory data. Sales and customer service should own customer records. Procurement should own vendor information.
Research from APQC emphasizes that organizations achieve better data quality when ownership, accountability, and governance responsibilities are clearly defined. Without those controls, even well-designed systems eventually suffer from declining data quality.
This is where ERP data governance becomes critical. Organizations need clear answers to four questions:
- Who owns the data?
- Who can make changes?
- Who approves changes?
- How are changes tracked?
Those decisions should be made before configuration begins, not after problems emerge.
Can we fix data issues after ERP go-live?
Technically, yes.
Strategically, it's usually one of the most expensive options available.
When organizations postpone ERP data cleanup, they rarely eliminate the work. They simply move it into a live operating environment where every correction carries greater risk.
A duplicate customer record discovered during testing is an inconvenience. The same duplicate record discovered after customer orders, invoices, and financial transactions have been processed becomes a much larger problem.
The Cost of Delaying Data Cleanup
This is why I often tell leadership teams that data errors eventually become business problems.
Reconciliation of work increases. Reporting confidence declines. Customer service teams spend more time investigating exceptions. Finance spends more time explaining numbers.
Or, as many CFOs eventually discover, data errors turn into financial variability.
The earlier those issues are identified and corrected, the less disruption they create later.
Executive data readiness checklist
Before beginning an ERP data migration, leadership teams should be able to answer "yes" to the following questions:
✓ Have duplicate customer and vendor records been identified and addressed?
✓ Have item master records been reviewed for consistency and accuracy?
✓ Have inventory balances been reconciled and validated?
✓ Have bills of material and routing records been reviewed?
✓ Has the chart of accounts been evaluated for current reporting requirements?
✓ Has data ownership been assigned for each major data domain?
✓ Are data governance and approval processes clearly defined?
If any of these questions produce uncertainty, the organization may not be as prepared for migration as it believes.
Closing perspective
In the first article of this series, I discussed how organizations can approach ERP migrations without disrupting operations. One of the recurring themes was that successful migrations depend far more on preparation than technology.
Data readiness is a perfect example.
An ERP data migration is often viewed as a technical exercise: extract the data, move it, validate it, and move on. In reality, it's a business exercise. The quality of customer records, inventory balances, item masters, financial structures, and governance processes will influence the outcome long after the migration itself is complete.
The organizations that experience the smoothest migrations aren't necessarily the ones with the most resources or the most sophisticated technology. They're usually the ones that invest the time to understand, clean, and govern their data before configuration begins.
In the final article of this series, I'll explore another factor that significantly impacts long-term ERP success: the governance decisions that determine whether a system remains manageable and adaptable as the business grows. Because successful ERP environments aren't built through software alone. They're sustained through disciplined decision-making long after go-live.
If your organization is preparing for an ERP migration, one of the most valuable investments you can make is understanding the quality of the data that will support it.
We work with leadership teams to assess ERP data readiness, identify data risks, and establish the governance structures needed to support a successful migration.
If you'd like a clearer picture of where data-related risks may already exist within your organization, let's start with a conversation.
