Your Legacy System Isn't the Problem. Your Data Is.

For: COO at a 50–200 person manufacturing or services business who has budgeted for a legacy system replacement and is three months into scoping, convinced the old software is what's slowing them down

If you're three months into scoping a legacy replacement, here's the uncomfortable thesis: your old system is not what's slowing you down. Your data is. Swap the platform without fixing the data underneath, and you will spend a large budget to automate the same dysfunction — faster, at greater scale, and with a shinier UI. The new system will not save you. It will indict you.

I've watched this play out at manufacturers with 30 years of ERP history, at services firms with a decade of CRM sprawl, and at distributors whose product master is a shared understanding held together by three people who've been there since 2004. In every case, leadership arrived at the same conclusion: the software is old, so the software must be the problem. It's a comforting diagnosis because it has a vendor-shaped solution. It is also, most of the time, wrong.

The dysfunction is in the data, not the database

Legacy systems are usually blamed for four things: they're slow, they don't integrate, reporting is painful, and nobody wants to use them. Those are real complaints. But peel them back and you almost always find the same underlying issue.

Reporting is painful because the same customer exists under six different spellings. Integration is hard because the SKU field is a free-text string that sometimes contains a SKU and sometimes contains a note the warehouse guy typed in 2011. Users hate the system because they have to enter the same information three times, in three formats, to get one order through. The system isn't slow — the humans working around it are.

None of that gets fixed by moving to a modern platform. In fact, modern platforms are worse at tolerating bad data. Legacy systems are forgiving in weird ways: they accept nulls, they let you overload fields, they don't validate much. A modern ERP or CRM will reject records the old one happily swallowed. So on day one of go-live, your ops team is drowning in exceptions for records that flowed just fine last week.

Three examples of how this actually breaks

1. The manufacturer with 40,000 "unique" parts. A mid-size manufacturer I've seen migrate had a part master with roughly 40,000 SKUs. After deduplication — matching on dimensions, material, and supplier — the real number was under 12,000. The rest were duplicates created over 20 years because the search in the old system was bad, so people just made new part numbers. Migrating 40,000 parts into a new MRP meant inventory math was wrong from hour one. Reorder points fired for phantom SKUs. Real stockouts hid behind fake stock. The new system was excellent. The data made it useless.

2. The services firm with a customer who was six customers. A B2B services business went into a Salesforce migration convinced their pipeline reporting problems were a Dynamics limitation. After migration, revenue by customer looked stranger, not clearer. The reason: their largest account existed as six separate records — different spellings, different legal entities entered inconsistently, one with a trailing space. Legacy reports had been quietly wrong for years. The new system just made the wrongness legible.

3. The distributor whose pricing lived in an Excel file. Legacy ERP had customer-specific pricing, but overrides had migrated to a spreadsheet maintained by one sales ops person. The scoping team missed it because it wasn't in the system of record. Go-live shipped 400 invoices at list price to accounts that had negotiated discounts. The recovery took months. That wasn't a software failure. It was a data-inventory failure.

Why smart teams miss this

The scoping phase of a legacy modernization is structured around the new system. Vendors demo capabilities. RFPs list requirements. Consultants map processes to modules. Almost nobody, in the first 90 days, does a rigorous audit of the data that's about to be lifted.

When data does get discussed, it's usually framed as "migration" — a technical activity that happens near the end, owned by a data engineer, budgeted at some percentage of the implementation. That framing is the trap. Migration is not a technical activity. It's an editorial one. Someone has to decide which of six customer records is the real one. Someone has to decide whether a 2013 part number with no transactions in five years should come along. Someone has to decide what "active" means. These are business decisions, and if you don't make them deliberately, your migration script will make them for you — usually by taking everything.

This is why digital transformation efforts fail more often than the vendor case studies admit. The technology worked. The data underneath didn't.

The counter-argument, honestly

The strongest pushback to this thesis is that you can't fix the data inside the old system. The tools are bad, the schema is rigid, and every hour spent cleaning legacy data is an hour not spent moving forward. Better to migrate, clean in-flight, and let the new platform's validation force discipline going forward. There's truth in that. Cleaning data inside a system that fights you is genuinely painful, and I've seen data-quality projects that turned into two-year archaeology digs producing nothing shippable.

But the answer isn't "skip the data work." It's "do the data work as a parallel workstream from week one of the modernization project, not as a migration afterthought." That means:

• Data profiling and deduplication start the same week as vendor selection, not six months later.
• A business owner — not IT — is accountable for the master records in each domain: customer, product, vendor, employee.
• Cleanup happens in a staging environment against the new schema, so you're not fighting the old system's constraints.
• You define what does not come across. Aggressive retention rules. Cold data goes to an archive, not the new production system.

Done this way, the data workstream runs alongside the implementation and lands ready. Skipped, it becomes the six-month post-go-live crisis that everyone pretends was unforeseeable.

What to do differently on Monday

If you're three months into a scoping exercise for legacy system modernization, stop and do four things before you sign an implementation SOW.

1. Profile the actual data. Run counts on your top five master tables. How many customers? How many are duplicates? What percentage of records have complete required fields under the new system's rules? If you can't answer this in a week, you don't know what you're migrating.
2. Find the shadow systems. Every legacy environment has spreadsheets, Access databases, and one person's laptop doing real work. Inventory them. Anything the business depends on that isn't in the system of record is a migration risk hiding in plain sight.
3. Appoint data owners by domain, not by department. Customer data has one owner. Product data has one owner. These people have the authority to make editorial calls — merge these two records, retire this SKU, standardize this field — without a committee.
4. Budget the data workstream separately. Not as a line item under "migration." As its own workstream with its own lead, its own timeline, and its own success criteria measured before go-live, not after.

The businesses that come out of a modernization project actually operating better are the ones that treated the data as the product and the platform as the delivery mechanism. The ones that treated the platform as the product are the ones calling their implementation partner nine months later asking why the reports are still wrong.

Your legacy system is old. That's fine. Old software has run good businesses for decades. What's actually running your business badly is the twenty years of data drift no one has looked at closely. Fix that first, or fix that in parallel, but do not — under any circumstances — assume the new platform will fix it for you. It won't. It will just show you, in high resolution and real time, exactly how broken it is.

Frequently Asked Questions

How do I know if my data is bad enough to delay a modernization project?

Run a basic profile on your top three master tables — customers, products, and vendors. If more than 10% of records have duplicates, missing required fields, or non-standard formats, you have a data problem large enough to derail a migration. You don't need to delay the project, but you do need a parallel data workstream starting immediately.

Can we just clean the data during migration instead of before?

Some of it, yes. Formatting, deduplication rules, and field mapping can happen in-flight. What can't happen in-flight is the business decisions: which duplicate is the real record, which historical data to retire, what "active customer" means. Those decisions need business owners and time, and if you compress them into the migration window, they get made badly or not at all.

Who should own data quality — IT or the business?

The business, with IT enabling. Customer data belongs to whoever runs the customer relationship. Product data belongs to whoever runs the catalog. IT builds the tools and enforces the rules, but the editorial authority — which record wins, what standard applies — has to sit with the people who use the data to make decisions.

What's the risk of skipping data cleanup and just going live?

Best case, your operations team spends the first quarter after go-live in exception-handling mode instead of running the business. Worst case, financial reporting is unreliable, customer-facing errors ship, and executive trust in the new system collapses within the first year. Either way, the cleanup happens — you just pay for it under worse conditions.

How long should the data workstream take relative to the platform implementation?

It varies too much by data volume, complexity, and current state to generalize responsibly. What matters is that it starts at the same time as vendor selection and finishes before go-live, not that it fits inside a fixed window. For a scoped assessment of what your specific data situation requires, talk to CodeNicely for a personalized review.