The 5 most common pitfalls in legacy system migrations

Legacy system migrations are technical, financial, and organizational projects all at once. They rarely fail for purely technical reasons (the target technology exists, capable developers can be found). They fail because of five organizational-decisional error patterns that repeat with disturbing consistency: underestimation of the domain knowledge hidden in the code, dirty legacy data not cleaned in time, big-bang without fallback, end-user rejection, non-specialized vendors. Let’s look at them one by one with the appropriate level of detail, because knowing them in advance is worth 50-150k euros in errors not made.

TL;DR

• Pitfall 1: the domain knowledge in legacy code is always 3-5 times greater than what is documented. Estimating by lines of code is wrong; it should be estimated by business rules to disambiguate.
• Pitfall 2: historical legacy data is always dirty (duplicates, mixed encodings, meaningful blanks). Migrating it “as is” propagates the problems into the new system. Data cleansing must be done before the migration, not after.
• Pitfall 3: shutting down the old system on go-live day without a documented and tested fallback is the single riskiest decision. Parallel running for 4-12 weeks is almost always cheaper than recovery after a failed go-live.
• Pitfall 4: end-user rejection sinks technically perfect migrations. Without serious change management (40-80 hours of training for power users, champion users from month 4) the new software gets bypassed with parallel Excel spreadsheets.
• Pitfall 5: vendors who sell the standard “modernization package” without adaptation to your context are the single most reliable predictor of failure.

Why these pitfalls still exist in 2026

These are not unknown pitfalls. They have been documented in technical literature and public project post-mortems for at least 15 years. Yet they repeat at a constant rate. Three structural reasons:

First, the rotation of technical staff. The IT managers who lived through the 2008-2012 failures are often retired or have changed roles. The new generations of CIOs encounter the same problems for the first time, without access to the institutional memory of their sector.

Second, the vendor-customer information asymmetry. Software houses that live off migrations have an interest in underestimating complexities to close the contract. The customer who has never done a migration does not know what to ask to unmask the underestimation.

Third, the go-live pressure. When the project drags on, the political pressure to “go into production anyway” pushes to skip exactly the steps (data testing, parallel running, user training) that protect against the pitfalls. You pay for it later.

Organizations that avoid these pitfalls do not do so by luck: they do so because someone on the team has lived through the previous failure or has studied the cases.

Pitfall 1: underestimating the domain knowledge in the code

What it is

Legacy code contains not only explicit logic (algorithms), but implicit decisions: business rules negotiated verbally, historical exceptions, workarounds for edge cases. This implicit knowledge is the true asset of the legacy and what needs to be recovered with the migration.

How it manifests

A typical real example: a twenty-year-old RPG code calculates the agent commission as commission = order_value * 0.05 by default, but with three exceptions: for customer “MILANO-001” (historical, verbal contract from 2003) the percentage is 0.067; for products in the “FUORI-CATALOGO” category it is 0.03; for orders from Southern Italy over 5,000 euros there is a 0.01 surcharge (introduced in 2007 by a sales director who was later fired, no one remembers why).

These rules are in no document. They exist in the code as nested IF statements with often outdated comments. Those who migrate see the IFs but do not understand why they are there. They decide not to carry them over (noise?), or they carry them over literally (preserving rules that are no longer valid).

Why it happens

Three main causes. (1) Project estimation by lines of code: 50,000 LOC × X euro/LOC = estimate. Ignores that the 50,000 LOC contain 800-1,500 implicit business rules. (2) Reluctance to invest in serious reverse-engineering: the consultant is given “the code” and is expected to produce the “new code”, without a budget for the stakeholder interview phase. (3) Critical stakeholders already out of the company: those who knew the rules are retired, unavailable, or expensive to re-engage.

What to do to avoid it

Code audit before the quote. Invest 3-6 weeks in a serious audit of the legacy codebase with modern tools (static analysis, AI as a copilot for reading RPG/COBOL). Output: a list of 200-500 identified implicit business rules, each with: description, when it triggers, required decision (preserve/revise/eliminate).

Stakeholder workshop. For each rule identified in the audit, decide with a competent stakeholder (sales, tax, administrative manager) whether it is still valid, modified, or can be eliminated. Time required: 30-60 hours of workshops distributed over 8-12 weeks.

30% buffer in the estimate. Add a contingency of 25-35% to the initial quote for discoveries of implicit business rules during development. It is almost always necessary; better to plan for it.

AI as an analysis copilot. Use a modern LLM (Claude, GPT, Gemini in code mode) to read RPG/COBOL blocks and produce an explanation plus a list of assumptions. It is not automation, it is an accelerator of human understanding. It reduces reverse-engineering time by 30-40% without replacing expert review.

Pitfall 2: dirty legacy data not cleaned in time

What it is

Historical data from legacy systems contains errors, duplicates, obsolete encodings, empty fields with implicit meaning. Migrating it “as-is” into the new system propagates the problems, and in many cases makes them worse because the new system has stricter consistency constraints that bring out previously silent errors.

How it manifests

Typical examples from Italian systems of the 2000s:

• Customer records with duplicates: the same customer registered 3-5 times with variants (with/without VAT number, with different capitalization, with obsolete vs updated addresses). In the legacy system they coexist peacefully. In the new system (with a unique constraint on VAT number) the migration fails or produces an “unusually small” customer database.
• Mixed encodings: product codes that mix old and new systems (e.g. “100-AB” from 1998 vs “PROD-2019-001” from 2019), with cross-reference tables maintained manually in Excel.
• Empty fields with meaning: the “last activity date” field being empty means “active customer” in some historical records; it means “customer never contacted” in others. The new system interprets both as null and loses the semantic information.
• Dates in incompatible formats: some dates as “DDMMYYYY”, others as “YYMMDD”, others as free strings (“January 2003”). The new system wants ISO 8601 timestamps.
• Mystical encodings: text files in UTF-8, some in CP1252, some in ISO-8859-1, with Italian accents that become ? or à if interpreted incorrectly.

Why it happens

Three causes. (1) Underestimation of the problem in the quoting phase (quotes say “data migration” as a single line item without detail). (2) Lack of a data engineer on the project team (a specific role, not a generic developer). (3) Postponing the cleansing “until after go-live” which becomes “never”.

What to do to avoid it

Data migration pilot in the first 4-6 weeks. Migrate a sample of 5-10% of the data (the most active customer records, orders from the last 12 months) into the new system in a test environment. Measure: how many records pass without modifications, how many require manual correction, how many are unrecoverable. It is the single metric that best predicts the real cost of data migration.

Data quality assessment as a formal deliverable. Output of 15-30 pages: inventory of tables, count of anomalies by type, estimate of cleansing work by type, decisions on what to discard/correct/migrate with caveats. Approved by the business owner before proceeding.

Cleansing budget of 15-25% of the total project. For serious migrations on historical data of 10-50M records, data cleansing typically costs 15-25% of the total project. Underestimating it is the number one source of budget overrun.

Clear expectations on data loss. Not all historical data is recoverable. Some are irrecoverably dirty (e.g. customer records from 1998 with unstructured free fields). Consciously decide what to migrate, what to discard, what to archive in read-only long-term storage.

Pitfall 3: big-bang without fallback

What it is

Big-bang = shutting down the old system on the day the new one starts. Without fallback = without a tested plan to return to the old one if the new one does not hold up.

How it manifests

The tragic recurring pattern: Sunday night the cut-over is done. Monday morning the new system runs but with critical bugs discovered only in production (e.g. invoice printing does not work, orders do not close, orders get stuck in an undefined state). Business operations partially stop. It is discovered that the rollback plan to the old system “exists as a document” but has never been tested. When you try to implement it, incompatibilities emerge (the data has been migrated in the meantime, some new records have no equivalent in the old one).

The company finds itself in limbo: the old system shut down, the new one not operational, the staff sent home. Emergency consultants are called at 200-400 euros/hour. People work day and night for 3-7 days. Typical direct emergency costs: 50-200k euros. Indirect costs (lost sales, customer complaints, loss of internal trust): immeasurable.

Why it happens

Four causes. (1) Go-live pressure: the date has been announced, stakeholders are expecting it, “postponing is embarrassing”. (2) Underestimation of the difference between test and production environments (the test saw normal cases, not edge ones). (3) Refusal to invest in parallel running (it costs 15-25% of the project, “it is not necessary”). (4) Reluctance to invest in writing and testing a rollback plan (it seems like an admission that go-live could fail).

What to do to avoid it

Parallel running of 4-12 weeks. Both systems active in parallel, with data syncing. Expensive (double licenses, double data entry, reconciliation) but gives time to discover problems in production while maintaining operations. For mission-critical business it is almost always indispensable.

Documented and tested rollback plan. Writing it is not enough: it must be tested. At least a week before go-live, simulate a rollback in a test environment and time it. If the rollback requires 8+ hours, it is not a plan: it is the illusion of a plan.

Strangler pattern where possible. Module-by-module migration instead of total migration. A single module cut-over is reversible in a few hours if necessary; a total system cut-over is irreversible after a few hours.

Go-live in a cold operational window. Never during business peaks (month-end close, half-year close, high season). Always in low season (mid-August, the week between Christmas and New Year, long weekends). It gives room to handle unexpected events without operational pressure.

Pitfall 4: end-user rejection

What it is

Even technically perfect new software does not work if end users (operators, billing staff, warehouse workers, sales staff) reject it or bypass it. They go back to parallel Excel spreadsheets, shared files, off-system processes.

How it manifests

Typical pattern: you go into production with the new system. The staff uses it for a few weeks, complaining that “the old one was faster”, “I cannot find the button for X”, “this changes everything and we do not understand why”. Slowly, some senior operators start using their personal 2018 Excel again “because it works better for what I do”. After 6 months, 30% of operations happen outside the new system. After 12 months, the company has two parallel systems: the official new one, the de facto historical one. The data diverges. Management does not understand why the new system’s KPI shows different figures from operational reality.

Why it happens

Four causes. (1) Insufficient training: 4-8 hours vs the 40-80 needed for power users. (2) Failure to communicate the why of the migration: users perceive the change as imposed, not as an improvement. (3) UI/UX of the new system objectively worse in some flows compared to the legacy one optimized over 20 years of iterations. (4) Absence of internal champion users who become positive reference points.

What to do to avoid it

Layered training. Power users (5-10% of staff): 40-80 hours of training distributed over 6-8 weeks. Standard users (rest of staff): 8-16 hours of training targeted at their specific flow. Quarterly refresh post-go-live for the first 12 months.

Champion users from month 4-6 of the project. Identify 3-5 respected people in operational teams and involve them in development as internal consultants. They see the system grow, give feedback, become natural ambassadors when going into production.

UX review done by real users. Requirement documents approved by managers are not enough. The flows of the new system must be tried by those who will actually use them, in 60-90 minute sessions with observation. You always find things that managers would never have imagined (e.g. the warehouse worker who needs to see the status of an order without having to do a full login).

Communication of the why, not just the how. Users accept change if they understand why it is being done. A series of short all-hands meetings (15-20 minutes) explains the context: regulatory pressure, rising legacy costs, scarcity of developers, opportunity for more modern work. Without this framing, change is perceived as a whim of management.

Pitfall 5: non-specialized vendors

What it is

Legacy modernization is a specialty. Not all good developers know how to do migration. Relying on a “generalist” vendor that does “a bit of everything” and has sold you the modernization package is the single most reliable predictor of failure.

How it manifests

You sign with a well-known vendor, maybe a large one, who has one or two “modernization” case studies on their site. You discover after starting that: (a) the team assigned to the project is junior, because the seniors are on more profitable clients; (b) the methodology is that of green-field projects (new software development, not migration), unsuitable for the context; (c) the project manager has never managed a legacy migration before; (d) every important technical decision requires escalation to an external consultant (at your cost) who has the specific experience.

The project drags on. The vendor makes promises to not lose the contract, but the promises are not kept. You get to 60% of the budget spent with 30% of the work done. From there you go: to a partner change (expensive, loses time), or to letting the project end in a suboptimal way to close it anyway.

Why it happens

Four causes. (1) Vendor selection based on brand (well-known logo) instead of on specific case studies of the same type of migration. (2) Lack of technical questions to the vendor during the selection phase: you ask what they do, not how. (3) Reluctance to invest in technical due diligence of the vendor (checking references, asking for a specific portfolio, interviewing the project lead before signing). (4) Bias towards large vendors for reasons of perceived safety (“they are big, they cannot go wrong”), even if the specific track record is weak.

What to do to avoid it

Vendor selection with technical due diligence. At least 3 vendors in the short list. For each: 3-5 case studies of migrations similar to yours (legacy technology + size + sector), interviews with previous clients (not just testimonials from the site, but direct calls), meeting with the proposed project lead (not just the sales rep).

Specific technical questions to the vendor:

• How do you handle the reverse-engineering phase of RPG/COBOL code?
• What is your data cleansing methodology?
• How do you plan parallel running and the rollback plan?
• How many migrations of this specific type have you completed in the last 36 months?
• Who are the specific people assigned to our project? Can I speak with them?

Vague or generic answers = red flag.

Contract with milestones and economic gates. No opaque fixed price. Break the project into 4-6 milestones with specific deliverables and economic gates (e.g. milestone 1 = 20%, milestone 2 = 25%, etc.). If a milestone is not reached, payment is blocked until a solution is found.

Right of audit and of partner change. The contract must provide for the customer’s right to perform a technical audit at any time (with a third-party consultant at their own expense) and to terminate/change vendors if the audit identifies serious problems. Without these clauses the customer is a hostage of the vendor.

How to structure a project to avoid the 5 pitfalls

Four operational principles that, applied together, drastically reduce the risk of falling into the pitfalls above.

1. Serious assessment before the quote. 4-8 weeks of independent assessment (also from a third-party consultant, not just from the proposed vendor) before signing multi-year contracts. Output: documented migration plan, cost estimate within a ±20% range, list of specific risks.

2. Pilot before all-in-one. Migrate a module, a location, a product line before extending to everything. Validate the approach on a reduced scale. Iterate before scaling.

3. Weekly governance. Weekly steering committee with executive sponsor, project manager, tech lead, business owner. Quick decisions. Clear escalation. No monthly waits to decide.

4. 30% risk buffer. On time, on budget, on resources. Migrations have unknowns that emerge only during execution. A 30% buffer is realistic; less is optimistic; more is disorganized.

FAQ

Is it better to do everything in-house or outsource?

Almost always outsource the technical execution of the migration, because it requires specialized skills that are difficult to sustain as a permanent internal team. The following must be kept in-house: the executive sponsor, 1-2 internal technical references (legacy experts), the business owner for each domain, the change management lead. Healthy internal/external mix: 30% internal + 70% external typical.

How long should the initial assessment last?

For migrations of medium systems (5-20M of business value managed), typically 4-8 weeks. Below that it is superficial, above that it is inefficient. The assessment includes: code audit, data audit, stakeholder interviews, strategy definition, cost and time estimation.

How do you measure if the migration is going well during execution?

Five key KPIs: (1) milestone completion rate (are we at the expected gates or behind?), (2) defect density in testing (under control or growing?), (3) data migration success rate on pilots (above 95%?), (4) user training coverage (are we on pace with the roadmap?), (5) budget burn rate vs real progress.

When do you decide to stop a struggling project?

When two signals emerge together: (a) the budget burn rate exceeds the real progress rate by 30%+, (b) the vendor cannot produce a credible recovery plan within 30-60 days. Continuing a project on the wrong track is the most expensive way to end it.

Do AI-assisted migrations reduce these pitfalls?

Marginally, and only for pitfall 1 (domain knowledge). AI accelerates reading legacy code by 30-40%, but the other four pitfalls are organizational-decisional and are not addressed by AI. On the contrary: companies that get convinced that “AI solves the migration” often skip the change management steps (pitfall 4) and vendor due diligence (pitfall 5), and end up in worse pitfalls.

Can every pitfall be prevented with a good contract?

No. The contract is a tool, not a solution. Migrations that work have solid contracts plus active operational governance plus a competent internal team plus a specialized vendor. The contract alone is a necessary but not sufficient condition.

Conclusion

The five pitfalls of legacy migrations are not inevitable. They are predictable, known, and can be avoided with specific choices made before the start of the project: serious audit, early data cleansing, planned parallel running, structured change management, vendor selected for specific track record. Companies that do these five pieces well spend 20-30% more in the early phases and save 40-80% on the total project curve.

If you are planning a legacy migration and want to discuss the specific risks of your case, let’s talk. We can do a structural risk assessment even before getting into the technical scope.

To go deeper: the pillar page legacy modernization, the related articles AS/400 migration guide for the overall strategic framework, and how much it costs to modernize a custom ERP from the 2000s for the economic angle.