From legacy to cloud: why DACH prefers evolution

Ask a German or Swiss CTO about their cloud strategy and you rarely hear about a migration deadline. You hear about a sequence.

That difference is often read as conservatism. It is better understood as a different bet: that the cost of a wrong architectural decision exceeds the cost of moving slowly. In a market where systems run for fifteen years and regulators ask about outsourcing, that bet is usually correct.

The DACH approach: measured, not hesitant

The distinction matters because the two look identical from outside and behave very differently.

Hesitant means the decision is deferred. Nothing is decided, nothing ships, and the estate ages.

Measured means the decision is decomposed. The question “should we move to the cloud?” becomes twenty smaller questions with individual answers, each of which can be acted on now.

The second produces continuous movement without a big-bang commitment. It also produces something a board can approve — a next step with a cost and a date, rather than a programme with an outcome three years out.

Why the methodical path works better here

Three reasons specific to this market.

Regulatory answers have to precede architecture. Under revDSG/nDSG and GDPR, and under FINMA rules for supervised businesses, you need documented answers on data residency, access, sub-processors and exit. Deciding architecture first and discovering the constraint later means rebuilding — which is far more expensive than asking early.

Systems have long lives. A core system installed in 2011 and still running is normal here. Its replacement will also be expected to run for a decade, which justifies more care in the design than a two-year product cycle would.

Buyers ask about continuity. DACH procurement weighs supplier stability heavily. An architecture that creates a hard dependency with no exit is a procurement problem as much as a technical one.

Legacy systems still have value — if modernised, not replaced

The phrase “legacy system” implies something to be removed. In most Swiss and German mid-market companies the legacy system is the accumulated encoding of how the business actually works, including rules nobody has written down anywhere else.

Replacing it wholesale means re-deriving those rules from scratch, which is the single most common cause of failed replacement projects.

The alternative is to change what it is, incrementally:

• Expose its data through a stable interface, so new systems can read it without touching its internals
• Move capabilities out one at a time, routing traffic gradually behind a facade
• Leave the parts that work alone. Not every module needs to move, and the ones that are stable and cheap to run are the last priority

Covered in full in seven principles of legacy modernisation without downtime.

From monolith to modular — without the microservices detour

Modernisation is often assumed to mean microservices. For most mid-market estates that is a decision, not a consequence.

Microservices solve an organisational problem: several teams that need to release independently. With one or two teams, you acquire distributed-systems complexity without the problem it solves — network failures between things that used to be function calls, distributed transactions, and an operational burden that needs staff you do not have.

A well-structured modular application — clear internal boundaries, one deployment, one database — delivers most of the maintainability benefit at a fraction of the operational cost. It can be split later if a real reason appears.

Hybrid cloud as the architecture that fits

Hybrid is often presented as a compromise or a transitional state. In this market it is frequently the correct end state, because the constraints genuinely differ across the estate:

• Regulated or particularly sensitive data stays in Switzerland — on-premises, Swiss colocation, or a Swiss region with contractual access limits
• Variable-load and customer-facing workloads go to the cloud, where elasticity is worth paying for
• Non-production environments go to the cloud without argument — they should not exist most of the time
• Stable workloads on hardware not yet depreciated stay put until the refresh date decides

The discipline hybrid requires is that the split follows the constraints rather than habit. A hybrid estate that grew by accident is two platforms and two operating burdens; one that was designed is a set of deliberate placements.

For the cost comparison behind those placements, see cloud vs on-premises: what makes sense for SMEs.

What the incremental path actually returns

The honest answer is that it returns less in year one and more in year three.

A replacement project shows nothing until it lands, then shows everything at once — assuming it lands. An incremental path shows a smaller result every quarter and compounds, because each step reduces the cost of the next one.

What to measure, rather than “cloud adoption”:

• Time to deliver a change the business asked for
• Number of manual steps in a release
• Cost per environment, once attribution exists
• Hours spent on incidents that recur

If those are not moving, the programme is migrating rather than modernising — the distinction that decides whether it was worth doing.

Related: application modernization and Cloud & DevOps.

If you want a read on what your first increment should be, book a call. No obligation.