“Our data is clean. It’s been in the system for years.”
That’s what the client told us during project kickoff. Six months later, when we ran the first migration rehearsal into D365, their “clean” customer master exploded into 42,000 duplicate records—many with slightly different spellings, outdated addresses, or missing tax IDs.
Credit limits were wrong. Sales orders couldn’t be created. Workflows routed to the wrong approvers. Customer statements were unusable. We had to abandon UAT after day one.
The project delayed eight weeks. An emergency data governance team was formed. Trust in the project took a major hit.
After 20+ D365 implementations, my partner Ba Tran and I can tell you with certainty: Data migration is the most consistently underestimated phase of every ERP project. Not because it’s technically complex—but because companies treat it as an IT task when it’s actually a business transformation challenge.
Here’s what you need to know to avoid becoming another data disaster story.
Why Data Migration Breaks Projects
Most companies budget migration as a technical task: extract data from the old system, transform it to fit D365’s structure, load it into the new system. Done.
But that’s like saying building a house is just “put materials together.” The real work is in the preparation, the quality control, the validation, and the inevitable discovery that your materials aren’t as good as you thought.
Here’s what actually happens:
You discover your “clean” data has been accumulating errors for years. Item masters are inconsistent. Customer records are duplicated. Your chart of accounts doesn’t align with D365’s structure. Historical transactions have missing fields. And nobody documented what any of the codes actually mean.
By the time you discover this—often during the first migration rehearsal—you’re 60-70% through the project timeline. Now you’re trying to fix a decade of data problems in weeks, while also finishing configuration, testing, and training.
That’s when projects derail.
Data Horror Story #1: The 42,000 Duplicate Customers That Took Down UAT
A mid-market distributor insisted their customer master was “clean.” No profiling had been done—they’d been using the same system for 15 years, so obviously the data was fine.
When we ran the first migration load into D365, the system ballooned with 42,000 duplicate customer records.
The fallout:
- Credit limits were wrong
- Sales orders couldn’t be created
- Workflows routed to the wrong approvers
- Customer statements were unusable
- UAT had to be abandoned after day one
Root cause: The legacy system allowed free-text entry, and no one had ever enforced governance. The business assumed “IT will clean it during migration.”
Impact:
- Project delayed 8 weeks
- Emergency data governance team formed
- Required a full rebuild of the customer master
- Trust in the project took a major hit
The lesson: Data cleansing is not optional, and it is never “quick.” If you don’t profile early, the first mock load becomes a crime scene.
Data Horror Story #2: The Inventory That Magically Doubled Overnight
A manufacturer had inventory tracked in three legacy systems. During the first migration rehearsal, the transformation logic accidentally summed quantities across systems instead of deduplicating shared SKUs.
Result: D365 showed twice the real inventory across 18 warehouses.
The fallout:
- MRP generated massive, incorrect production orders
- Procurement issued POs for materials they already had
- Finance couldn’t reconcile on-hand values
- Warehouse teams panicked because counts didn’t match reality
Root cause: The business never validated the mapping rules, and the migration team didn’t have SME sign-off on the transformation logic.
Impact:
- 3-week delay
- Full rebuild of the item master and warehouse mappings
- Required a physical cycle count across all locations
- CFO nearly pulled the go-live
The lesson: Rehearsals aren’t optional—they’re the only thing preventing catastrophic cutover errors. Bad transformation logic doesn’t show up in design meetings; it shows up when you load real data.
The Most Common Data Migration Disasters
- Discovering Data Quality Issues at Go-Live
Not two weeks before go-live. AT go-live.
You flip the switch, users start working, and suddenly:
- Orders can’t be processed because customer tax IDs are missing
- Production can’t start because BOMs have the wrong item numbers
- Finance can’t close because GL accounts don’t balance
This happens when migration validation was cursory. Someone checked that “the data loaded” but didn’t verify it was correct and usable.
- Data Validated by Someone Who Doesn’t Know the Business
Companies try to save SME time by having junior staff or consultants validate migrated data.
The problem: Only the people who actually use the data daily know if it’s right.
A consultant can verify that all required fields are populated. They can’t tell you that customer #12345 should have a credit hold, or that Item ABC-123 has a 6-week lead time that’s not showing up, or that Warehouse B shouldn’t be able to ship certain product categories.
You can’t hire help to validate data. This is business-owner work.
- Historical Data That Doesn’t Map to D365’s Structure
Your legacy system tracked things one way. D365 tracks them differently. Now you need to map 10 years of historical transactions into a structure that didn’t exist in your old world.
Where this gets painful:
- You’ve changed item numbers in the new system
- You’ve restructured customer hierarchies
- You’ve consolidated vendor records
- Your new GL structure doesn’t match the old one
Now every historical transaction needs transformation logic. And if you insist on bringing everything over (because “we need the history”), you’ve just created months of extra work.
The hard truth: Sometimes the right answer is to keep historical data in the legacy system as read-only and start fresh in D365. Fighting to migrate everything is often more expensive than the history is worth.
- Super High-Level Validation That Misses Critical Gaps
The migration team shows the business a few sample records:
- “Does this customer look right?” ✓
- “Is this item correct?” ✓
- “Do these GL accounts make sense?” ✓
Based on cursory spot-checks, the business approves. Then at go-live, they discover:
- 30% of items are missing critical attributes
- Vendor payment terms are wrong across the board
- Location codes don’t match warehouse reality
- Customer ship-to addresses are outdated
What went wrong: The validation was “check a few examples and approve 100,000 records.” That’s not validation—that’s hope.
When Data Work Should Actually Start
The reality: Data typically takes more time and energy than people want to give it.
Most companies want to defer data work until late in the project because:
- “We’re still finalizing processes”
- “The data won’t change much”
- “We’ll worry about that closer to go-live”
Here’s what actually happens:
You discover data problems that require business decisions, process changes, and months of cleanup. By then, you’re also trying to finish UAT, finalize training, and prepare for cutover. Everything compounds.
Our recommendation: Start data work in the first month of the project.
I’ve had customers push back when I wanted to start data migration and validation 6 months before scheduled go-live. They thought it was too early.
But here’s the truth: As important as perfecting processes is to a successful go-live, good data trumps that exponentially.
You can work around a sub-optimal process temporarily. You can’t work around missing, duplicate, or incorrect data. Bad data breaks everything.
A Realistic Timeline for Data Migration Work
Phase 1: Data Profiling & Assessment (2 to 6 weeks)
Purpose: Understand source systems, data structures, volumes, quality issues, and mapping complexity.
Duration depends on:
- Number of source systems (1 vs. 5+ changes everything)
- Whether documentation exists
- Whether SMEs are available
- Whether historical data is included
Realistic ranges:
- Simple environment: 2–3 weeks
- Moderate complexity: 4–6 weeks
- Highly fragmented legacy landscape: 6–10 weeks
Deliverables:
- Data inventory
- Data quality scorecard
- Mapping workbook (initial draft)
- Gap list for cleansing
Phase 2: Data Cleansing (1 to 4 months)
This is the most variable phase because the client owns 80–90% of the work.
Timeline drivers:
- Volume of master data (customers, vendors, items, chart of accounts)
- Number of years of historical transactions
- Whether duplicates, missing fields, or inconsistent formats exist
- Whether business owners are engaged and accountable
Realistic ranges:
- Well-maintained data: 1–2 months
- Typical mid-market client: 2–3 months
- Poor data hygiene or multiple legacy systems: 3–4+ months
Important note: Cleansing almost always takes longer than clients expect. It’s the #1 cause of go-live delays.
Phase 3: Migration Rehearsals (2 to 4 full cycles)
Rehearsals validate:
- End-to-end load scripts
- Data transformation logic
- Cutover duration
- Environment readiness
- User acceptance of migrated data
Typical cadence:
- Mock 1: After initial mappings and first load scripts are ready
- Mock 2: After major cleansing is complete and transformations are stable
- Mock 3: Full dress rehearsal with near-production data
- Mock 4 (optional): Only for complex multi-company or multi-system migrations
When they occur:
- Usually spread across the middle and late phases of the project
- Final rehearsal typically 2–4 weeks before go-live
Rule of thumb:
- 2 rehearsals = minimum viable
- 3 rehearsals = best practice
- 4 rehearsals = high-risk or multi-entity programs
Who Should Own Data Migration?
This is where most companies get it wrong: they treat data migration as an IT task.
IT owns the technical execution: building scripts, running loads, managing environments.
But the business must own:
- Data quality standards
- Validation and sign-off
- Cleansing decisions (what to keep, merge, or purge)
- Mapping rules for transformations
- Acceptance criteria for migrated data
Why this matters:
Only the business knows if the data is correct. Only the business can identify when processes will break because of data issues.
A migration consultant can tell you that all required fields are populated. They can’t tell you that Customer ABC shouldn’t be flagged for credit review, or that Item XYZ has specific handling requirements that aren’t captured, or that Vendor 123 always pays via wire transfer and the payment method is missing.
If IT owns migration without business validation, you’re building on assumptions. Those assumptions fail at go-live.
How to Approach Data Migration Successfully
- Start Early (First Month of the Project)
Don’t wait until processes are finalized. Data profiling should happen early because it often reveals process decisions you need to make.
- Assign Business Owners to Data Domains
- Customer master: Sales/Customer Service leader
- Vendor master: Procurement/AP leader
- Item master: Operations/Supply Chain leader
- Chart of accounts: Finance leader
These owners are accountable for data quality and validation. Not the PM. Not the consultants. Them.
- Profile Before You Promise
Before you commit to a migration timeline, profile your data. Understand what you’re actually working with. Then set realistic expectations.
- Build in Cleansing Time (Not Migration Time)
Most project plans allocate weeks for “data migration.” That’s the load. What they miss is the months needed for cleansing.
Budget for cleansing separately and treat it as a critical workstream, not a side task.
- Rehearse Multiple Times
One mock migration is not enough. You need:
- One to validate the technical approach
- One to validate the cleansed data
- One to validate the full cutover process
Each rehearsal reveals issues. Budget for them.
- Validate, Don’t Just Load
Loading data successfully doesn’t mean it’s correct. Build validation checkpoints:
- Reconciliation reports comparing old system to new
- Spot-checks of high-value or high-risk records
- Process testing using the migrated data
- SME sign-off at the record level, not just “looks good overall”
- Accept That Some Data Won’t Migrate
Sometimes the right answer is to leave historical data in the legacy system as read-only and start fresh in D365.
This is especially true for:
- Old transactions with incomplete information
- Data that requires extensive transformation
- Historical records with no ongoing business value
Fighting to bring everything over can cost more than the history is worth.
The Bottom Line
Data migration is not a technical task that happens in the final weeks of a project. It’s a business transformation effort that spans the entire implementation and requires sustained engagement from the people who actually use the data.
Companies that succeed at data migration:
- Start early (first month)
- Assign clear business ownership
- Budget realistic time for cleansing (months, not weeks)
- Run multiple rehearsals
- Validate rigorously, not superficially
- Accept that not all data is worth migrating
Companies that fail at data migration:
- Defer it until late in the project
- Treat it as an IT responsibility
- Underestimate cleansing effort
- Skip rehearsals or run only one
- Approve data with cursory spot-checks
- Insist on migrating everything regardless of cost
Your D365 implementation can have perfect configuration, excellent training, and strong sponsorship. But if your data is wrong, none of that matters. Users will blame the system, adoption will suffer, and the project will be labeled a failure.
Good data isn’t optional. It’s foundational.
Planning a D365 implementation and want to understand how to approach data migration realistically? Let’s talk about what data readiness actually requires for your specific environment. Schedule 30 minutes here.
Next week in ERP Implementation Insider: “What a Good Cutover Plan Actually Looks Like (And Why Most Are Too Weak)” — how to build a cutover strategy that survives reality, the difference between a task list and a true cutover plan, and why rehearsals matter more than people think.