Old software. Understood first, then renewed.
Your system has run for years and does its job. But nobody knows exactly how any more, and every change feels like a gamble. We first map what your software really does. Then we modernise it step by step, with proof that nothing changes that must not change.
Most legacy projects do not fail on technology. They fail on the order of things.
They start rewriting before anyone knows what the old system does. Or there is no safety net that shows when the new system calculates differently. Twenty years of taking over other people’s systems taught us one order that holds: first understand, then decide, then build, always with a test that proves the behaviour did not change.
That is why we sell the plan before the build. The plan is one assignment with five steps. Building starts only when you have signed off on it.
Five steps. Each one delivers something you keep.
One assignment, a fixed scope, and after every step a result you can stop at, steer on or continue from. The old code is never touched: analysis and new code live apart.
- STEP 1What is there? We start with five questions the code does not answer: what is in scope, can the system be built and tested at our end, is there a build pipeline, were there earlier attempts, and what must not be touched. Then we check whether everything is complete. You know up front what is missing.Readiness report
- STEP 2What does it do? We map size, complexity, technical debt and security. You get an interactive map of your system: which parts call each other, where data comes from, and how a user moves through the main processes.Map of the system
- STEP 3Which rules are in it? The knowledge about rates, conditions and calculations often lives only in the code. We take those rules out and write them down in plain language, with a reference to the exact place in the code. Your people check them. That gives you documentation that is right, even if you never migrate.Rules, with source
- STEP 4What is the plan? From that we write the modernisation plan: target architecture, phasing and a behaviour contract that sets down what the new system must keep doing. It is a plan your steering group can approve. Nothing is built until you sign.Plan for sign-off
- STEP 5Build, with proof Before we change anything, we record the current behaviour in tests. The new system has to pass them. So you see in black and white that it calculates the same. Which of the three routes below we take, the plan decides.Same behaviour, proven
The plan picks the route. Not our preference.
Upgrade.
The same technology, a newer version, such as .NET Framework to the current .NET. Your code stays. We only fix what breaks between the versions. We migrate one part completely first and use those lessons for the rest.
Replace step by step.
One part at a time, while the old system keeps running. No big bang, no night in which everything has to move at once. First the tests that pin down today’s behaviour, then the new part, then the proof that both do the same.
Build anew.
A new architecture, built from the rules we took out of your old system, on a foundation that stays yours. With acceptance tests that show from day one whether it is right, and two moments where you give the go.
If an upgrade turns out to touch most of the code after all, we say so and choose another route together.
One assignment for the plan. Or take-over first.
The modernisation plan. From “what does it do” to a plan your board can sign.
The five steps above for one system: readiness, map, rules, plan, and the tests that record today’s behaviour. You get a proposal with a fixed price for the five steps. Building afterwards gets its own proposal, per route.
Ask for the planManagement and further development. We take the system over from your supplier or the developer who left.
Steps 1 to 3 as a handover file: architecture, dependencies, rules with their source, security findings. On that basis we keep the system stable and safe, make it safer while it runs, and develop it further at a fixed management fee in the proposal. We have been the incoming party and the outgoing one.
Management and further developmentYour old system stays untouched. Your data stays where it is.
The analysis is as good as what is in the code.
The full list comes with the intake. This is the short version, so you know what to look for before the first conversation. Never production data.
Six signs you recognise.
Migrations that held.
Our own foundation, Entry, was born inside one of them.
Off a low-code platform, onto .NET
A parking-permit system that had outgrown its low-code platform, but was locked into it. We rebuilt it and migrated it to .NET. The building blocks we wrote along the way became Entry, our open-source foundation.
Read the case Case · FOSIMRebuilt to keep running
A traffic-flow simulation that Rijkswaterstaat uses for large infrastructure projects and research. We took it over from TU Delft and partly rebuilt it so it runs on current systems. The simulation model itself stayed intact, and the software can move to the browser later.
Read the case Case · NT2 OnlineModernised, then developed further
An online learning environment that had to be modernised before it could grow: the publisher supplied the teaching methods and content, we invested in the technology.
Read the caseFour questions that come first.
Do we have to replace everything?
Rarely. Understand it first, then replace the part that hurts most. A system that is stable and understood can run for years. The goal is that you can change it again, not that you have new software.
What if the source code is gone?
Then the running system is the specification. We record its behaviour from the outside (screens, database, integrations) and build against that. It takes longer, and we are open about the parts that cannot be seen from the outside.
How do we handle the current supplier?
We join the conversations with your supplier, or take them over. Most handovers go better once someone technical is in the room on your side. If the supplier does not cooperate, we start from what you already hold: an export of the database and the running application. Source code helps, but it is not a condition.
What does it cost to find out?
The plan is one assignment with a fixed scope and a proposal with a fixed price for the five steps. Building afterwards gets its own proposal, per route, and at the end of every phase you decide whether we go on.
Show us the system everyone works around.
Tell us what it runs on, how old it is and who still understands it. Together we look at what is there, what it does and which route fits. Then you decide on the next step.
From old system to new, since 2006