The Dilemma No One Wants to Solve

Your oldest system is probably between 10 and 20 years old. It works. But every update takes longer. Specialists become scarce. Operating costs rise every year.

At the same time, everyone knows: It's terribly risky to touch this system. It is intertwined with hundreds of processes. If something goes wrong, the business stops.

This is the legacy dilemma: Expensive maintenance or costly and uncertain change.

(Most companies choose option three: close their eyes and hope. It works. Until it doesn't anymore.)

What Legacy Systems Really Cost

Most companies dramatically underestimate the costs. They look at the IT budget and think: "500,000 francs per year for a critical system - that's okay."

That's not the whole truth.

The Direct Costs

Hardware support for old systems. Expensive licenses for proprietary platforms. Backup and recovery that require specialized knowledge.

The Hidden Costs

Developers who know old technologies like COBOL earn 30-50% more than average. Debugging takes longer because fewer people understand the system. Documentation that is either outdated or nonexistent.

The Opportunity Costs

This is the largest item that is often overlooked.

Your developer team spends 60% of its time keeping the legacy system running. That means: 60% less time for new features.

When a new requirement comes, integration takes three months. With a modern system, it would be three weeks.

Junior developers don't want to work on COBOL. Your recruiting becomes more difficult.

Add everything up: Your legacy system doesn't cost you 500,000 francs per year. It probably costs you over a million.

The Three Options

There are exactly three strategic paths. None is universally right. All have advantages and disadvantages.

Option 1: Migration

You take the system as it is and move it to a new platform. From on-premise to cloud. From old hardware to modern infrastructure. The business logic remains the same - only the technology underneath changes.

When it makes sense: The system is technologically outdated, but the architecture is solid. You want to lower operating costs without rewriting everything.

Costs: Typically 30-50% of what a rebuild would cost. Timeframe: 6-18 months.

Option 2: Replacement

The old system is completely replaced. Either by a purchased standard solution (SAP, Salesforce) or by a complete rebuild.

When it makes sense: The architecture is broken. Your business processes have fundamentally changed. You need new capabilities that the old system can't provide.

Costs: The most expensive option. Timeframe: 18-36 months for a rebuild.

Option 3: Retention

You keep the system but make it less painful. Optimization, better monitoring, security patches. Maybe you hide it behind modern APIs so new systems can communicate with it.

When it makes sense: The system is stable. There are no major expansion requirements. You don't have the budget for migration or rebuild.

Costs: The cheapest option in the short term. But the opportunity costs remain.

How You Decide

The question is not: What is the best option? The question is: What is the best option for you?

Four Questions You Should Ask Yourself:

How critical is the system? If it fails, does the business stop? Then you are risk-averse - prefer migration over rebuild.

How is the architecture? Solid base, just old technology? Migration. Broken architecture with a hundred patches? Better replacement.

How often do you need new features? Frequently new requirements? Then the innovation bottleneck is expensive. Stable, rarely changing requirements? Retention can work.

How does your budget look? Large investment budget? Replacement is realistic. Small budget, but high pressure? Migration is the compromise.

The Most Common Mistake

The biggest mistake we see: Doing nothing and hoping.

"The system still runs. Why should we touch it?"

The problem: Time is working against you.

With each year, operating costs rise. With each year, fewer developers find the technology interesting. With each year, security becomes more questionable.

Eventually, your best expert retires. Or changes jobs. And suddenly nobody understands how the system really works.

That's the point at which it becomes expensive. Really expensive.

The second biggest mistake: Replacing the entire system when a migration would have sufficed. Rebuilds are risky, expensive, and take a long time. If the architecture is solid, migration is almost always the better way.

When It Goes Wrong

Legacy modernization is risky. But risks are manageable if you recognize them early.

The biggest problems we see:

Hidden Dependencies. The system depends on a hundred small things that no one has documented. Solution: Dependency mapping early in the project. Who uses which data? Which systems are dependent?

Performance Degradation. The new system is slower than the old one. Solution: Baseline measurements before migration. Performance tests under load before you go live.

Data Loss. During migration, data is lost or corrupted. Solution: Multiple dry runs. Data validation after each migration.

Scope Creep. Initially, it was a migration, now it's becoming a rebuild. Solution: Strict scope definition. Just migration, no new features. Changes must be approved.

The Point

Legacy systems are not inherently bad. They are often reliable, stable, proven. The problem is: They become more expensive as the world around them changes.

There is no universal answer. Some systems should be migrated. Some should be replaced. Some should be retained - for now, with smart management.

The worst thing you can do is nothing. The second worst is: Replacing the entire system when a migration would have sufficed.

The right decision? The one that fits your situation. Not some generic best practice.

The first step is always the same: An honest conversation. What does it really cost us? What are our options? And how long can we wait?

After that, it becomes concrete.

Do you have a legacy system giving you headaches? We conduct assessments for Swiss companies - honest, pragmatic, with clear recommendations. Talk to us.