Every CIO inherits legacy systems. Enterprise resource planning platforms from the 1990s. Customer databases running on deprecated software. Core business applications built by contractors who left the company a decade ago. Eventually, these systems need to be replaced or modernised.

The business case is usually clear: reduce maintenance costs, improve performance, enable new capabilities, eliminate technical debt. The risks seem manageable: project overruns, data migration issues, training requirements.

But the projects that go badly wrong — and many do — usually fail due to risks that weren’t properly assessed upfront. Here’s what gets underestimated.

The Undocumented Business Logic Problem

Legacy systems accumulate business logic over years. Rules about how orders are processed, how pricing is calculated, how inventory is allocated. Much of this logic exists only in the code, not in documentation.

When you migrate to a new system, you need to replicate or replace that logic. But if nobody knows exactly what the old system does — and they often don’t — you discover gaps after go-live.

A pricing system might have special rules for specific customer categories that were added five years ago to accommodate a major client. Nobody remembers those rules exist because they execute automatically in the background. The new system doesn’t include them because they weren’t documented. Invoices go out with wrong prices. The client complains. Revenue is lost.

I’ve seen migrations where 30-40% of the original business logic wasn’t documented anywhere except in code that nobody currently in the company understands. Reverse-engineering that logic is expensive and error-prone.

The Data Quality Disaster

Legacy systems often contain decades of accumulated data with inconsistent formats, duplicated records, and missing information. That’s fine when the system was built to handle that mess — it has workarounds and manual processes that compensate.

New systems are usually less forgiving. They enforce data validation, require specific formats, and don’t tolerate the inconsistencies the old system accepted.

Migration projects discover data quality problems late, often during testing or after go-live. Customer addresses in free-text fields that need to be structured. Product codes that changed formats multiple times over the years. Historical transactions with missing or contradictory information.

Cleaning this data is tedious and time-consuming. Postponing the migration to clean data first means extended timelines. Migrating dirty data means dealing with errors and exceptions continuously after go-live.

The Shadow System Problem

Large organisations develop shadow systems — spreadsheets, Access databases, departmental tools — that supplement or work around limitations in the official system. These shadow systems often handle critical business functions, but they’re invisible to IT and not included in migration planning.

After the official system migration, the shadow systems break because they depended on specific data exports or API calls that the new system doesn’t support. Business processes that relied on these tools stop working.

Finance might use a spreadsheet that pulls data from the legacy system daily and performs calculations that inform cash flow decisions. That spreadsheet won’t work with the new system without modification. If nobody knew the spreadsheet existed, it doesn’t get fixed until after go-live when cash flow reporting suddenly fails.

The Timing and Sequencing Challenge

Most large organisations can’t afford to stop business operations during a system migration. The migration needs to happen while business continues, which creates complex sequencing problems.

Do you migrate all data at once or in phases? Do you run both systems in parallel temporarily? How do you handle transactions that occur during the migration? What happens if you need to roll back?

These questions don’t have universal answers. The right approach depends on specific system characteristics, business requirements, and risk tolerance. Getting the sequencing wrong can result in data loss, duplicate processing, or extended periods where nobody trusts either system.

The Organisational Change Resistance

Technology migrations require changing how people work. New interfaces, different workflows, altered reporting tools. Even when the new system is objectively better, people resist change because they’re comfortable with the old way.

This manifests as workarounds where people continue using old processes and manually entering data into the new system, or as passive resistance where people find reasons why the new system doesn’t work and demand modifications that recreate the old system’s behaviour.

Change management is often treated as secondary to technical implementation, but it’s equally important. If users don’t adopt the new system properly, you’ve spent millions on technology that doesn’t deliver expected benefits.

The Dependency Mapping Failure

Legacy systems are typically integrated with other systems — sometimes dozens of them. The customer database feeds the email marketing platform, which integrates with the CRM, which connects to the billing system. These integration points need to be identified and maintained or rebuilt during migration.

Incomplete dependency mapping means discovering critical integrations after the new system is live and those integrations are broken. An export that runs nightly and feeds a data warehouse used for executive reporting. An API call that provision user accounts in other systems. A file transfer that sends order data to a warehouse management system.

Each of these represents a potential failure point during migration. Finding them all requires detailed discovery work that often gets rushed or skipped under timeline pressure.

The Vendor Lock-In Risk

Migrations often move from one vendor platform to another rather than rebuilding from scratch. This means trading one set of vendor dependencies for another, and the new vendor might be less flexible or more expensive over time.

The new system might use proprietary data formats that make future migrations difficult. Or it might have escalating licensing costs as your organisation grows. Or the vendor might be acquired and the product roadmap changes drastically.

These long-term risks are hard to assess during migration planning, but they can create problems years later when you realise the new system has become as difficult to escape as the old one.

The Budget Underestimation

Legacy system migrations almost always cost more than initial estimates. The median overrun is probably 30-50%, and some projects double or triple their original budgets.

This happens because discovery work uncovers complexity that wasn’t visible upfront. Data cleaning takes longer than expected. Integration work is more complicated. Testing reveals problems that require redesign. Parallel running extends for months rather than weeks.

Budget pressure leads to corners being cut — reduced testing, minimal training, deferred data cleaning. These shortcuts create technical debt in the new system and operational problems after go-live.

What Successful Migrations Do Differently

The migrations that succeed share common characteristics:

Extensive discovery phase. Spending 3-6 months understanding the legacy system, documenting business logic, mapping integrations, and assessing data quality before committing to an approach.

Executive sponsorship. A senior leader who understands the business impact and can make decisions when conflicts arise between technical purity and business requirements.

Adequate budget and timeline. Realistic estimates with contingency built in, not aggressive targets set to satisfy impatient stakeholders.

Proper change management. Investment in training, communication, and user support that’s proportional to the technical investment.

Phased approach with rollback capability. Migrating in stages with clear success criteria and the ability to revert if critical issues emerge.

Getting Outside Expertise

Most organisations don’t migrate legacy systems frequently enough to develop deep internal expertise. Bringing in consultants or AI strategy support who’ve managed similar migrations can help identify risks and navigate complexity.

The value isn’t just technical knowledge — it’s pattern recognition from seeing how these projects succeed or fail across multiple organisations. That experience is worth paying for, especially on large, business-critical migrations.

My Take

Legacy system migrations are difficult, risky projects that fail more often than they should. The technical challenges are real, but the underestimated risks around business logic, data quality, organisational change, and dependency management cause most failures.

Success requires acknowledging this complexity upfront, investing in discovery and planning, maintaining realistic budgets and timelines, and treating change management as equally important to technical implementation.

If you’re planning a legacy system migration, assume it will be harder, slower, and more expensive than initial estimates. Budget accordingly. Plan for problems. Build in contingency. And recognise that some legacy systems exist because they’re genuinely difficult to replace, not because previous IT leaders were incompetent.

The goal isn’t to avoid migrations — sometimes they’re necessary — but to approach them with appropriate caution and realistic expectations.