That System Everyone’s Afraid to Touch
Every company has one. The application nobody wants to modify because the last person who understood it retired in 2019. The database that “just works” until it doesn’t. The green-screen terminal that three warehouse employees use eight hours a day.
41% of German industrial firms still run on ERP systems built before 2005. Technical debt now consumes 20-40% of the entire technology estate’s value for the average enterprise. And engineers spend 2-5 working days per month dealing with it instead of building anything new.
The fear of touching legacy systems is rational. The cost of not touching them is higher.
Why “Rip and Replace” Usually Fails
The instinct is to burn it down and rebuild. Start fresh. Modern stack. Clean architecture.
Only 29% of large custom software rewrites get delivered successfully. Over a third get abandoned entirely. The problem isn’t ambition. It’s that you’re trying to replicate years of accumulated business logic in one shot, and you always miss something.
A manufacturing client came to us after a failed ERP replacement. Eighteen months in, EUR 400,000 spent, and they were back on the old system.
The replacement couldn’t handle custom pricing rules that had evolved over 15 years. Nobody had documented them. Nobody even knew all of them existed.
The lesson: don’t try to understand the entire system before you start. Modernize incrementally.
The Strangler Fig Pattern: Your Best Friend
Named after the tropical plant that grows around a host tree and eventually replaces it, the strangler fig pattern lets you migrate piece by piece. The old system keeps running while new components grow around it.
Here’s how it works in practice.
You put a routing layer (often an API gateway) in front of your legacy system. All traffic goes through it. Initially, every request gets forwarded straight to the old system. Nothing changes.
Then you pick one module. Invoicing, inventory lookup, whatever hurts most. You build the modern version and redirect that specific traffic to the new service.
Everything else still hits the legacy system.
Repeat. One module at a time. The old system gradually handles less and less until you can switch it off.
This approach works because it eliminates the big-bang risk. If the new invoicing module has a problem, you route traffic back to the old one. Your business never stops.
A rising trend in 2025 is combining the strangler fig with event streaming. Tools like Apache Kafka enable Change Data Capture (CDC) to sync legacy databases with modern data stores in real time. Read-heavy operations get offloaded to the modern stack while writes continue going to the legacy database during transition.
API Wrapping: The Fast First Step
Sometimes you don’t need to replace the legacy system at all. You just need to make it talk to other things.
API wrapping puts a modern REST or GraphQL interface in front of your old system. The legacy application keeps doing what it does. But instead of other systems needing to understand its proprietary protocols or database schema, they talk to a clean API.
This works especially well for:
Systems that function correctly but can’t integrate with anything modern. An old warehouse management system that stores data in a custom format, wrapped with an API, suddenly becomes a data source for your new dashboard.
Systems where the replacement timeline is long but the integration need is immediate. You can’t wait 18 months for the new ERP. But you can build an API layer in 4-6 weeks that lets your e-commerce platform pull inventory data in real time.
The wrapper doesn’t fix the underlying technical debt. But it buys you time and unlocks integration possibilities that didn’t exist before.
Data Migration: The Part That Breaks Things
Code migration gets all the attention. Data migration breaks all the projects.
Your legacy database has 15 years of records. Some fields were repurposed halfway through. Some data was entered inconsistently.
Some foreign keys point to records that no longer exist. Sound familiar?
Three strategies that work:
Dual-write during transition. Both old and new systems write to their respective databases simultaneously. A sync process keeps them aligned. When you’re confident the new system is correct, you cut over.
ETL pipelines with validation. Extract data from the old system, transform it to match the new schema, load it into the new database. Run validation checks at every stage. Mismatches get flagged for manual review.
Phased migration by entity. Migrate customers first, then orders, then invoices. Each entity gets its own validation pass. This is slower but catches problems early.
Whatever you choose, build a rollback plan before you start. Test it. Actually test it, not “we’ll figure it out if something goes wrong.”
The SAP Elephant in the Room
SAP’s S/4HANA forced migration deadline is 2027. Mainstream maintenance for ECC 6.0 ends. If you’re running legacy SAP, this isn’t optional anymore.
Your options boil down to three paths. Greenfield: start from scratch on S/4HANA (expensive, thorough). Brownfield: convert your existing ECC system in place (faster, carries over customizations).
There’s also the selective approach: migrate specific data and processes while rebuilding others.
For most Mittelstand companies, the brownfield approach makes sense. You keep your existing customizations and data. But you need to clean up years of accumulated configuration first.
Don’t treat S/4HANA as just a technical upgrade. It’s a chance to simplify processes that have calcified over decades. The companies that use this migration to eliminate unnecessary complexity come out stronger.
Phased Rollout: Module by Module
Never do a big-bang rollout. Never.
The pattern that works: pick the module with the highest pain and lowest risk. Modernize it. Deploy it alongside the old system. Let both run in parallel until you’re confident. Then cut over.
For a typical mid-sized company, a reasonable sequence looks like this:
Month 1-2: API wrapper around the legacy system. Immediate integration benefits with zero risk to existing operations.
Month 3-4: First module replacement (pick the one your team complains about most). Run it in parallel with the legacy module.
Month 5-6: Second module. By now, your team has the pattern down.
Month 7+: Continue module by module. Each one gets faster as you build confidence and tooling.
The total timeline for a full migration is typically 12-24 months for a mid-sized system. That sounds long. But compare it to the 18-month failed rewrite that ends with nothing.
Managing Risk During Migration
Things will go wrong. Plan for it.
Keep the old system running until each new module has been stable in production for at least 30 days. No exceptions. The cost of running two systems temporarily is much less than the cost of a failed cutover.
Build automated comparison tests. Feed the same input to both old and new systems and compare the output. Discrepancies get logged and investigated. This catches the edge cases that manual testing always misses.
Document as you go. The biggest risk in legacy modernization isn’t technical. It’s losing the business knowledge embedded in the old system.
Every rule you discover, every edge case you encounter, write it down. Your future self will thank you.
Funding the Journey
KfW’s digitalization programs cover legacy modernization projects. The ERP-Förderkredit Digitalisierung launched in 2025 specifically targets this kind of work. Software development, cloud migration, and system integration all qualify.
For more on the full digital transformation roadmap, including funding strategies and change management, start with our pillar guide.
Technical debt doesn’t stop growing while you make plans. Every month you wait, the migration gets harder and more expensive.
But the good news: you don’t have to do it all at once. You just have to start.
If you want to understand the downstream effects of leaving systems as they are, read about the true cost of technical debt. And for cloud decisions that come alongside modernization, our cloud migration guide covers the European angle.
Stuck on legacy systems? Let’s map your modernization path. We’ll assess your current architecture, identify the highest-value modules to migrate first, and build a phased plan that doesn’t disrupt your business.
