ERP Migrations: The Honest Guide

Every large enterprise has a piece of software they're terrified of. Something built in 1995, running on infrastructure nobody wants to maintain, with documentation that exists only in one person's head. A system so intertwined with operations that ripping it out feels like open-heart surgery while the patient is walking around.

Most companies don't migrate off these systems, not because they can't, but because they're genuinely afraid. And that fear is partially justified. ERP migrations fail with alarming frequency. Not catastrophically, usually, but just enough to reinforce the sense that it's not worth the risk.

I've worked on both sides now—implementing new systems and helping companies extract themselves from existing ones. The failures don't usually stem from technical problems. They stem from underestimating the complexity of the existing system and overestimating how much of that complexity actually matters.

The First Mistake: Paralysis Through Perfectionism

Most companies approach ERP migration as if they need to replicate 100% of their current system exactly. They build a massive requirements document listing every field, every report, every workflow. The scope explodes. The timeline stretches. The budget balloons. Within six months, the project is over budget and behind schedule, and they're already talking about pulling the plug.

Here's what I've learned: you don't need to replicate your legacy system. You need to migrate your critical data and core processes. The difference is enormous.

When I ask clients to identify their truly critical workflows—the ones that stop the business if they break—they usually list fewer than ten. For a $50 million distributor, it's order management, inventory tracking, purchasing, and accounts payable. Everything else is downstream. Yet they'll insist on migrating forty-seven custom reports and seventeen workflows that happened to exist in the old system.

The honest conversation is this: some of those things are going away. Some processes that have existed for years will be replaced with simpler approaches. Some workarounds will be eliminated because the new system doesn't require them. That's not a loss. That's the point.

The Data Migration Truth

The biggest risk in any ERP migration is data migration. Not the technical part—converting from one database format to another is straightforward. The hard part is data quality.

Legacy systems accumulate garbage. Duplicate customer records. Inventory items that don't exist anymore, still tracked because nobody deleted them. GL accounts that haven't been touched in five years. Vendor records with inconsistent naming. When you migrate this data into a new system expecting clean data structures and proper relationships, everything breaks.

We spend three weeks on what I call "data archaeology" with every migration client—reviewing the actual data to understand what's there, what's corrupted, what's duplicated. Then we build a cleansing process that usually eliminates 15-20% of existing records as duplicates or obsolete entries. Clients always push back. "We can't just delete data!" But that data is toxic. It corrupts analytics, breaks reconciliation, creates confusion.

The truth is that data migration requires parallel operation. You can't flip a switch from old to new. You need to run both systems simultaneously while validating that everything matches. That's expensive. That's disruptive. And it's non-negotiable if you want to avoid catastrophic mistakes.

Realistic Timelines and Costs

A real ERP migration—one done properly—takes 12-18 months for a mid-market company. Not 6 months. Not "we'll be live on the new system by Q4." That timeline is fantasy that fails consistently.

The honest schedule looks like this: three months of discovery and planning, three months of system configuration and data cleansing, three months of build and testing, three months of pilot with a subset of operations, and three months of parallel operation before cutover. That's a full year. And that assumes you're migrating to an off-the-shelf system like NetSuite or SAP. Custom ERP adds another six months.

The cost per employee typically runs $5,000-$15,000 depending on complexity. So a 200-person company should budget $1-3 million for a proper migration. Yes, that's real money. But it's cheaper than continuing to run software held together by legacy workarounds and prayer.

What matters isn't the absolute cost. It's the cost per month of operational improvement once you're live. If the migration eliminates three FTEs of manual reconciliation work, you recover the investment in two years. If it enables new business visibility that identifies $500K in annual cost savings through better purchasing, you recover it in six months.

Start a migration when the math works. Gather data for six months to prove the case. Then commit fully. The companies that fail at ERP migration are the ones hedging their bets, maintaining the old system as a fallback, running pilots instead of full commitment. You need organizational will. You need a real deadline. And you need to accept that for 90 days post-launch, everything will feel slower and more frustrating, and that's normal.