Service 04

Legacy modernisation without the big-bang rewrite

The system works, which is exactly the problem: nobody wants to touch it, the one person who understands it is near retirement, and every new requirement takes months. We replace it piece by piece while it keeps running.

Problem

What legacy really costs

Industry benchmarks commonly put the majority of IT spend on maintaining existing systems rather than building new capability. Whatever your exact number, the symptoms are familiar: unsupported frameworks and databases, security findings that cannot be fixed, a vendor who has disappeared, and a team that avoids changes because nobody knows what will break.

Big-bang rewrites fail often enough to be a cliché: two years of parallel development, a feature freeze, and a cut-over weekend nobody sleeps through. The alternative is an incremental migration with the old and new systems running side by side — boring by design.

Typical starting points

  • Business applications on end-of-life platforms: old Java EE or .NET Framework, Access, FileMaker, Lotus/HCL Notes, Delphi, classic ASP, unsupported PHP or Oracle Forms.
  • An in-house or vendor system whose original authors are gone and whose source code may or may not be complete.
  • Monoliths that block cloud migration, SSO, mobile access or integration with new systems.
  • Audit or security findings that the current platform cannot satisfy.
Approach

How we modernise

We follow the strangler-fig pattern: put a facade in front of the old system, move one capability at a time behind it, and retire the old system when nothing routes to it any more.

  1. Assessment (fixed fee, 2–4 weeks)

    Code, data and interface inventory; what is used and what is dead; risks and dependencies; options (retain, rehost, refactor, rebuild, replace with a product) with cost ranges — and a recommended sequence.

  2. Safety net first

    Characterisation tests around critical behaviour, a copy of production data for verification, monitoring, and a data-migration rehearsal pipeline. Nothing moves before it can be checked.

  3. Migrate by capability

    Each capability (e.g. customer master data, invoicing, reporting) is rebuilt, run in parallel, compared against the old system’s output, then switched. Users see continuous small improvements, not a cut-over.

  4. Retire and hand over

    Old components are decommissioned with a documented checklist; the new system comes with documentation, tests, CI/CD and a team that knows it — yours, ours, or both.

Deliverables

What you get

  • Assessment report with options, risks, costs and a phased roadmap — usable as an RFP basis if you tender.
  • A modern, maintainable application stack on supported platforms, deployed in your cloud or data centre.
  • Migrated and verified data, with reconciliation reports.
  • Automated tests, CI/CD, monitoring, infrastructure as code, documentation.
  • Incremental releases with the business running throughout — no feature freeze beyond short, agreed windows.
Indicative range
Investment
CHF 80,000 – 250,000+
Duration
4 – 9 months for a typical mid-sized application

Indicative, for planning. Very large or multi-system modernisations run longer and are phased. The assessment produces a fixed price for the first phase. How pricing works →

Typical technology

Target stacks are deliberately mainstream: Java/Kotlin (Spring) or TypeScript/Node.js services, React or server-rendered front ends, PostgreSQL or SQL Server, containers on AWS/Azure or a Swiss host. The point is that your next team — in-house or another vendor — can take it over.

A representative engagement

Illustrative scenario — not a client case study

Before

An insurance intermediary runs policy administration on a 15-year-old .NET Framework application with a SQL Server database, maintained by one external developer. A new SSO requirement and a security audit cannot be satisfied on the current platform.

After

Over seven months, the application is rebuilt capability by capability behind a routing facade: first authentication and the read-only policy views, then document generation, then policy changes. The old application is decommissioned after a three-week parallel run with matched outputs. The team now has tests, a deployment pipeline and two people who know the code.

We publish real case studies only with written client permission. Until then, this section shows the shape of the work, not a result we claim.

Led by a software engineer (since 2008) with roles at

  • Deutsche BörseGerman stock exchange, 2014–2018
  • SAPSenior Software Engineer, 2019–2022
  • UnbluSenior Software Engineer, 2022–2024
  • InfosysSoftware Engineer, 2008–2012

Founder’s employers — not Monolith clients.

FAQ

Common questions

Can’t we just keep patching the old system?

Sometimes that is the right answer for a few more years, and our assessment will say so if it is. The question is what each year of delay costs in security exposure, blocked projects and key-person risk — we make that visible so you can decide.

Will users have to learn a new system overnight?

No. Capabilities move one at a time; users switch screens gradually, and we keep familiar workflows where they work. Training is incremental.

We do not have the source code. Is modernisation still possible?

Often, yes — by treating the old system as a black box: characterising its behaviour through tests and data, and rebuilding capabilities from the outside in. The assessment determines how much of the logic can be recovered from data, documentation and users.

How do you control cost on a project this size?

By phasing it. Each phase has a fixed price and a defined outcome; you can stop after any phase with a working, improved system. The assessment is a fixed fee and tells you what phase one costs before you commit.

Other services

Related services

Which application is everyone afraid to touch?

Tell us what it does, what it runs on and what is pushing you to change now. You receive a written assessment within two business days.