The old system nobody wants to touch

It works, but nobody fully understands it any more, the original developer is long gone, and every small change is made with your heart in your throat. We don’t default to throwing it out — we default to finding out exactly what it has first.

Message us on WhatsApp Send an email

The first instinct with an old system is “let’s rewrite it from scratch”. It’s often wrong. A system that has run for ten years also contains business decisions nobody consciously remembers — rules, exceptions and edge cases learned from the reality of the business, not from documentation. A from-scratch rewrite risks losing all of that at once.

That’s why we start with an audit: we read the code, check the database, see how a deploy is done and how often it breaks. The audit produces a list of real risks and a recommendation — incremental modernisation, screen by screen, or, when it genuinely justifies itself, a rewrite. The gap between those two decisions is tens of thousands of euros, so it deserves checking, not assuming.

The most frequent request is a desktop-to-web migration: an application written ten to fifteen years ago, in Swing or an abandoned framework, that needs to become reachable from a browser or a phone. It can be done screen by screen, with the old system fully working throughout the transition.

What we do

A short, paid technical audit

We read the code, run the build, check the database and the deployment flow. The result: a list of risks and a reasoned recommendation — repair, modernise or rewrite.

Desktop → web migration

The screens of an old desktop application, brought into the browser one at a time, with the old system still running for as long as the transition takes.

Incremental modernisation

Not a big-bang cutover. Every stage is deliverable and usable on its own, spreading the risk over time instead of concentrating it in a single launch.

Data migration

Cleanup and transfer into the new structure, with verification that nothing was lost or duplicated along the way.

Integration with a current stack

APIs, a current database, modern authentication — the modernised system talks to the rest of your infrastructure instead of staying isolated.

Documentation that never existed

Many legacy systems never had documentation. We write it as we come to understand the system, so the next person doesn’t go through what we went through.

Technologies

What we often find

old Java Swing / AWT
procedural PHP
Visual Basic
databases with no versioned migrations

Where we migrate to

Spring Boot
Laravel
React / Vue
PostgreSQL

Process

technical audit
incremental migration
regression testing
CI/CD

We care about the old stack as much as the new one — you can’t modernise what you haven’t understood first.

A good fit if

nobody left fully understands the system
the developer who wrote it is no longer available
you can’t find people to work on the old technology any more
you need web or mobile access to data locked inside a desktop application today

Frequently asked questions

Do we have to stop using the old system while you work?

No. Incremental migration means exactly that: the old system stays fully functional while we modernise screen by screen, and the transition happens in a controlled way, not in a panicked weekend.

Is a from-scratch rewrite ever the right call?

Yes, when the audit shows the system is smaller than the complexity of repairing it, or when the technology is old enough that nobody can be hired to work on it any more. We don’t decide that in the first conversation — we decide it after seeing the code.

How much does a technical audit cost?

It’s a separate, small stage with a fixed price — see the pricing page for the range. The audit’s output gives you a basis to decide, even if you choose to continue with someone else.

What happens to the business logic nobody remembers any more?

Exactly why we don’t recommend a reflex rewrite. During the audit we specifically hunt for these implicit rules — edge cases, exceptions, old decisions buried in the code — and document them before migrating, not after.

All services

Let’s get specific

Do you have a project like this?

Message us on WhatsApp or by email with two or three sentences about what you need. We’ll come back with the questions that matter and a budget and timeline estimate.