How to Audit Your ERP Data Before a Migration
Most ERP migrations fail because nobody audits the data first. Here's a structured approach to assessing your data landscape before you move a single record.
Most ERP migrations fail. Not because the new system is bad, but because nobody looked at the data before moving it. You wouldn't move into a new warehouse without inventorying what's in the old one. ERP data deserves the same discipline.
The Problem Nobody Talks About
When a manufacturer decides to replace their ERP, the conversation immediately jumps to features. Which system has the best shop floor module? Can it handle our BOM structure? What about MRP?
Meanwhile, the data sitting in the current system — the data that will become the new system's foundation — gets a hand-wave. "We'll clean it up during migration." That sentence has preceded more failed go-lives than any technical limitation.
What a Real Data Audit Looks Like
A structured data audit answers four questions:
1. What Do You Actually Have?
This isn't "how many tables." It's semantic classification: How many distinct business entities exist across your systems? How are they related? Which departments own which definitions? Where do definitions conflict?
A manufacturer running Epicor 10 might have "Customer" defined in three different ways — CRM accounts, ship-to addresses, and billing entities. These aren't the same thing, but they share a label. That ambiguity will migrate with the data unless someone resolves it first.
2. How Much Do You Cover?
Coverage means: of all the data in your source system, what percentage can you classify into known business domains? If your source has 400 tables and you can only structurally account for 280, you have 70% coverage and 30% uncertainty. That 30% is where migration defects hide.
3. Where Are the Conflicts?
Conflicts happen when two departments use the same term to mean different things — or different terms to mean the same thing. "Part number" in Engineering follows a different convention than "Part number" in Purchasing. These aren't data quality issues. They're definition issues, and they're invisible until you look for them systematically.
4. What's Your Governance Posture?
Can your organization answer: who is responsible for the definition of "Customer"? Is there a single source of truth for part classifications? If the answers are unclear, the migration will replicate the ambiguity.
The Structured Approach
At Mimir Labs, we run this audit through Ratatosk — a structured data governance workshop that produces machine-readable artifacts, not slide decks. The process:
- Parse your schema exports (DDL, ERD, data dictionaries)
- Classify every table and column against the Mimisbrunnr semantic reference model (170 tables, 17 business domains)
- Score each classification with confidence metrics
- Detect conflicts between overlapping definitions
- Produce a governance baseline: taxonomy manifest, coverage report, conflict summary, and executive briefing
The output isn't a recommendation to buy something. It's a structural map of your data landscape that makes any subsequent migration — to any system — less risky.
When to Do This
Before you've selected a new ERP. Before you've signed a migration contract. Before the consultants arrive with their field mapping spreadsheets.
The governance baseline is the cheapest insurance you can buy against a failed migration. A one-day workshop costs a fraction of a single week of go-live delay.
Mimir Labs runs Ratatosk data governance workshops for manufacturers preparing for ERP migration or system consolidation. Schedule a conversation to discuss your data landscape.