Legacy software - a system that works but is technologically outdated - is a headache for almost every company with 10+ years of operations. The right decision between upgrade, migration, and complete rewrite can mean the difference between €20,000 and 6 months and €200,000 and 2 years. Typical rule of thumb: if fixing the existing system takes more than 50% of new development - better to start from scratch. If less than 30% - migration is almost always the more rational choice.
This article breaks down how to objectively assess a legacy system, what migration techniques exist, and how to avoid the biggest traps in a rewrite.
Three types of legacy software (and different approaches)
Don’t treat all “old” systems the same. There are three basic scenarios:
Type 1: A system that works but can’t be modified
- The technology is outdated (e.g. PHP 5, Visual Basic 6, old Java-EE)
- The original development team is long gone
- Every small change takes weeks
- Approach: Refactoring or gradual migration (strangler fig pattern)
Type 2: A system that’s breaking more and more often
- Bugs are spreading like a virus
- Performance is dropping, especially during peaks
- Security updates have been skipped for years
- Approach: Urgent migration plan, stabilizing the existing one until the new one is done
Type 3: A system that no longer fits business needs
- The business changed, the software didn’t
- Adaptation attempts create chaos
- The owner no longer understands what the system does
- Approach: Complete reassessment - often means new development
Real cost of maintaining a legacy system
The biggest mistake: thinking “don’t touch it” is the cheapest option.
Hidden costs of a legacy system:
- Slower employee work. A system that takes 10 seconds per operation instead of 1 second, at 100 operations daily, loses 15 minutes per employee - daily. Monthly: 5 hours per employee.
- More errors. Old systems have more bugs. Every error means manual intervention.
- Security risk. Old systems have unpatched security holes. One big hack can cost 10x more than the entire migration.
- Growth impossibility. New features are expensive or impossible. Competitors move forward, you don’t.
- Talent retention. Developers don’t want to work on outdated tech. Hard to find someone to maintain it.
Typical total annual cost of maintaining an outdated system for a small/mid-sized company: €20,000-€80,000+ through lost time, errors, and missed opportunities.
Three migration techniques
Depending on system size and risk tolerance, we pick one of three techniques:
1. Strangler Fig (gradual migration)
What: We gradually replace parts of the old system with the new, like a strangler fig plant slowly overgrowing a tree.
How: The new system takes over one feature at a time. The old one stays in parallel until the last piece is migrated.
When to use: Large systems with many features, where a “big bang” migration is too risky.
Duration: 12-36 months.
Cost: €40,000-€300,000+, but spread over time.
Risk: Low - you always have a working system.
2. Big Bang (full replacement in one day)
What: At a specific moment, the old system shuts down and the new one starts up.
How: Development of the new system in parallel with the old one, intensive testing, then “switch over.”
When to use: Smaller systems, or when the old is so bad that parallel operation isn’t worth it.
Duration: 6-18 months of development, then 1 day for migration.
Cost: €30,000-€150,000.
Risk: High - if something doesn’t work after the switch, crisis.
3. Parallel run (both systems running)
What: Old and new systems run in parallel for months.
How: Data syncs between them, users gradually move to the new one.
When to use: Critical systems where downtime isn’t allowed, or when you must prove the new system gives the same results.
Duration: 3-12 months of parallel running.
Cost: €50,000-€250,000+ (more expensive due to double infrastructure).
Risk: Lowest - you always have a backup.
Decision criteria: migrate or rebuild?
Six questions that help decide:
1. How often is the system modified? Often = worth investing in a new one. Rarely = can be “glued together” for another year.
2. Is there documentation? Yes = migration is realistic. No = probably better to start from scratch.
3. How “deep” is the system in business processes? Deep = big migration cost, but no choice. Shallow = relatively easy to replace.
4. Do you have resources for parallel running for several months? Yes = strangler fig or parallel. No = big bang or extending the status quo.
5. What’s the risk of data leak or breakdown? High = urgent (security comes first). Low = you have time.
6. How tolerant is the company to downtime? Not = parallel running mandatory. Yes = big bang or strangler fig.
Biggest traps in a rewrite
Five things that often go wrong:
1. Trying to copy all old system features 1:1. Many old features aren’t used, or work wrong, or are from a previous business model. Map actual usage before you build.
2. No data migration plan. The old system has 5-15 years of data. Migration isn’t “just a script” - it’s often 20-30% of total project scope.
3. Not enough parallel running. A switch over in the first month brings problems. Plan at least 2-3 months of parallel running where possible.
4. No user training. The new system has different logic. Without a training plan, users reflexively resist and ask for “the old way.”
5. No plan for after migration. Migration is a moment. The Operate phase is years. The maintenance and new-feature plan must be agreed before starting.
How a development partner approaches legacy systems
A proper flow we use:
Phase 1: Legacy audit (2-4 weeks)
- Code and architecture review
- Identification of key features and business rules
- Risk and opportunity assessment
- Written report with recommendations
Phase 2: Decision (1-2 weeks)
- Presentation of options with costs and timelines
- Collaboration with the client on picking the approach
- Final scope and contract
Phase 3: Development/migration (varies)
- According to the chosen approach (strangler, big bang, parallel)
- With continuous progress measurement
Phase 4: Stabilization (1-3 months)
- Gradual user redirection
- Active error tracking
- Fast response to issues
Frequently asked questions
Can we do the audit ourselves or do we need an external expert? Your own team can identify functional issues. An external expert is mandatory for an objective technical assessment - because internal developers (if they still exist) have emotional attachment to the system.
What if the original developers are no longer available? A more common scenario than you’d think. The audit takes a bit longer (3-5 weeks instead of 2-4), but it can always be done. The hardest part is systems in technologies practically no one uses anymore.
Can we migrate only part of the system? Yes, that’s exactly the strangler fig approach. You migrate the most painful parts first, the rest stays in the old system until its turn comes.
How long does a typical migration project take? Small system: 3-6 months. Mid-sized: 8-18 months. Large system with historical data: 18-36 months.
Have a legacy system?
Book a free Discovery call. We review your current system, identify risks and opportunities, and propose a realistic migration plan - with concrete numbers and timelines, not generic estimates.
Reach out at [email protected] or through the form on our homepage.