ERP Data Migration: A Mid-Market Strategy Guide

Eighty-three percent of data migration projects either fail outright, exceed their budget, or miss their deadline — a figure Gartner has tracked for years, and one that hasn’t meaningfully improved. Yet when mid-market companies plan a system change, data migration consistently gets the least planning time. It gets squeezed into the final weeks before go-live, assigned without clear ownership, and treated as a technical chore rather than the strategic risk it actually is.

Your ERP data migration strategy shouldn’t start when implementation begins. It should start before you sign the contract.

Why Most ERP Data Migrations Fail

The causes are well-documented. Three root causes appear in nearly every post-mortem: inadequate change management, poor data migration execution, and inexperienced teams. According to Curiosity Software’s analysis of migration failures, these three factors drive the majority of project failures — and they compound each other.

Those categories unpack into patterns mid-market IT leaders recognize immediately.

Dirty data treated as a go-live problem. Teams discover data quality issues during migration — duplicates, missing fields, inconsistent formats — and attempt to fix them under deadline pressure. The fix is rushed and incomplete. Data cleansing belongs months before go-live, not days before.

No single owner. IT assumes the business owns data quality decisions. Business units assume IT handles the technical mapping. The implementation vendor assumes both sides have it covered. Nobody signs off on what gets migrated, what gets archived, and what gets left behind.

Compressed timelines that cascade into shortcuts. Boards set go-live dates before anyone has assessed the data. When the timeline tightens, validation passes get cut, test loads run on incomplete datasets, and cleanup gets deferred to “after go-live” — where it rarely happens.

According to McKinsey, migration inefficiencies will account for over $100 billion in wasted spend over the next three years. Most of that waste concentrates in the mid-market, where IT teams are smaller and margins for error are thinner.

The Shadow Data Nobody Inventories

The most dangerous data in any migration isn’t in your ERP. It’s in the spreadsheets, Access databases, SharePoint folders, and FileMaker files that orbit around it.

This shadow data is often the most operationally critical information your company has: customer-specific pricing, carrier rate tables, product configurations, approval workflows, exception handling rules. It lives in files that one or two people maintain, and it never appears on a formal data inventory.

During migration planning, teams focus on the systems they can see — the ERP, the CRM, the accounting package. Shadow data surfaces late, usually when someone asks “where did the pricing matrix go?” two weeks after cutover.

Why this is a mid-market problem specifically:

Lean teams build workarounds. When a system doesn’t do exactly what’s needed, someone builds a spreadsheet to fill the gap. Over years, that spreadsheet becomes mission-critical.
No formal data governance. Enterprise companies have data stewards and governance frameworks. Mid-market companies have “the person who knows where that file is.” We’ve written about key person dependency as a business risk — shadow data is where that risk concentrates during migrations.
System changes expose the dependency. The old ERP and its satellite files formed an informal system. Replacing just the ERP without accounting for the satellites breaks workflows nobody documented.

Before any migration begins, run a shadow data audit. Interview every department — not just managers, but the people who do the daily work. Ask: “What files do you use every day that aren’t in the main system?” The answers will reshape your migration scope.

If you’ve already worked through process mapping, this audit is its data counterpart — and just as critical.

Who Should Own Data Migration?

This question surfaces in every mid-market implementation, and the wrong answer is the most common one: “everyone.”

Shared ownership means no ownership. Data migration needs a single accountable person — a Data Migration Lead — with authority to make cross-functional decisions about what gets migrated, what gets cleaned, and what gets archived.

Where each group fits:

IT manages the technical execution: extraction, transformation, loading, and system configuration. They own the how.
Business units own data quality decisions: which records are accurate, which are obsolete, which need correction. They own the what.
The implementation vendor provides target system expertise: schema mapping, field requirements, data format specifications. They own the where.
The Data Migration Lead orchestrates all three, resolves conflicts, and holds the timeline. They own the outcome.

This role doesn’t require a new hire. In our experience working with mid-size businesses, the most effective migration leads are senior IT staff or operations managers who understand both the technology and the business processes. The key qualification isn’t technical depth — it’s cross-functional authority and the willingness to make unpopular decisions about data quality.

A Phased Migration Strategy for Mid-Market Companies

The “big bang” approach — migrating all data at once on go-live weekend — works for small datasets and simple schemas. For mid-market ERP transitions, a phased approach reduces risk by surfacing problems early, when there’s still time to fix them.

Phase 1: Assess and inventory (weeks 1–4).

Map every data source, including shadow data. For each source, document:

What data it contains and how much
Who owns it and who uses it daily
How it connects to other systems — automated or manual
What percentage is current, historical, or obsolete

Most mid-market companies discover they only need to actively migrate 40–60% of their data. The rest is historical records that belong in an archive, not a new system.

Phase 2: Cleanse before you move (weeks 4–10).

Migrating dirty data into a clean system contaminates it. Cleansing includes:

Deduplication. Merge customer records that exist in three slightly different versions across systems.
Standardization. Phone formats, addresses, naming conventions, date formats — pick one standard and apply it.
Validation. Verify required fields have actual values, not placeholders. Check that relationships between records are intact.
Archival decisions. Closed deals from 2015, inactive vendors, obsolete product codes — define what moves and what stays.

If your data lives in silos across disconnected systems, expect this phase to take longer than planned. Reconciling records that were never meant to coexist is slow, detailed work.

Phase 3: Map and test load (weeks 8–14).

Map source fields to target fields in the new system. This is where structural differences surface — the old system stores “customer” as one record, the new system splits it into “company” and “contact.”

Run test loads with real data early. Loading actual production data into a test environment months before go-live surfaces mapping errors, performance issues, and missing data when you can still fix them. This is materially different from testing on sanitized sample data, which hides the edge cases that break things in production.

Phase 4: Validate and cut over (weeks 12–16).

Validation is the step that gets cut when timelines compress. Don’t let it.

Record count validation. Does the target have the same number of records as the source?
Field-level spot checks. Sample records across data types and verify every field.
Business logic validation. Do calculated totals, relationships, and reports produce expected results?
User acceptance testing. Have the people who use the data daily verify that their workflows function with the migrated data.

Set a hard cutover date with defined rollback criteria. If validation reveals critical issues, you need a clear decision framework: delay go-live, remediate in place, or roll back.

What Happens After Go-Live

Most migration guides stop at cutover. The reality is that the first month after migration is a legitimate project phase — not a cleanup.

In the first two weeks, users will find data errors that testing didn’t catch. A price that migrated incorrectly. A customer record that merged two different companies. A historical report pulling different numbers than it used to.

Plan for this before cutover:

Establish a data issue triage process. Define how users report problems, who investigates, and what the escalation path looks like. A shared spreadsheet and a daily 15-minute standup work better than a ticketing system nobody checks.
Keep the old system accessible in read-only mode for a defined period. Users will need to reference historical data, and having the old system available reduces panic.
Schedule a 30-day data quality review. Compare key reports and metrics between old and new systems. Investigate discrepancies — especially totals that are close but not exact, and records that migrated but lost their relationships.
Track what you learn. Every issue found post-go-live is a lesson for the next migration phase or the next system change.

We covered the broader post-implementation landscape in our ERP post-implementation guide. Data validation is one critical piece of that larger picture.

Frequently Asked Questions

How long does an ERP data migration typically take?

For mid-market companies, a full ERP data migration — from assessment through post-go-live validation — typically takes 12 to 16 weeks. Complex migrations involving multiple source systems or heavy data cleansing can extend to 6 months. The cleansing phase alone often takes 4 to 6 weeks, and compressing it is the most common source of downstream problems.

What is the difference between big bang and phased data migration?

Big bang migration moves all data at once during a single cutover event, typically over a weekend. Phased migration moves data in stages, starting with less critical datasets. Big bang is faster but riskier — if something goes wrong, everything is affected. Phased migration takes longer but lets you validate each stage independently, reducing the blast radius of errors.

How do you decide what data to migrate versus archive?

If the data supports an active business process — open orders, current customers, active products, recent financial records — it migrates. Historical data that no one queries regularly belongs in a read-only archive. Regulatory requirements may dictate retention periods, but retained data doesn’t have to live in your new production system.

Who should be responsible for ERP data migration?

A dedicated Data Migration Lead should coordinate the effort, with IT handling technical execution, business units owning data quality decisions, and the vendor providing target system expertise. The migration lead orchestrates all three groups and owns the timeline and outcome. The role requires cross-functional authority more than deep technical skill.

How do you validate data accuracy after migration?

Validate at three levels: record counts (same totals in source and target), field-level spot checks (sample records across data types), and business logic validation (calculated totals and reports produce expected results). Schedule a 30-day post-go-live review to catch subtle issues that pass automated checks but surface when real users run real workflows.

How Tier2 Approaches Data Migration

Tier2 has spent over 11 years implementing and migrating data across enterprise ERPs — Dynamics, SAP Business One, Totvs, Baan. That consulting history shaped how we build our own platforms.

Both Tier2 Cargo and Tier2 Keel were designed with migration realities in mind. Standardized data schemas, clear field mapping documentation, and built-in import tooling mean the mapping phase described above is structured rather than exploratory. When we onboard a company moving from another system, the data assessment and cleansing phases get the time they need — because we’ve learned that rushing them is how migrations end up in the 83%.

If you’re planning a system change and want to talk through your data migration scope, we’re happy to walk through it.

Before you evaluate a single vendor or sit through another demo, pull one report from your current system and trace where its data actually comes from. If the answer involves more than one system and a spreadsheet, you’ve found the first item on your migration plan.