Software you did not build. In good hands.
A system you lean on every day, built by someone else. The supplier is gone, or no longer the right one, or the developer who knew it has left. We take it over: first understand what runs, then keep it stable and safe, then develop it further. Nothing has to be replaced first.
Six situations we see every year.
Five steps. Then it is ours to keep running.
The first three steps are the same as on the legacy page. They end in a handover file. Nobody manages what nobody understands.
- STEP 1What is there? Source code, build pipeline, configuration, database, contracts, licences, access. We check what is complete and what is missing, and whether the system can be built and tested at our end. You know up front what still has to come from the previous supplier.Readiness report
- STEP 2What does it do? Size, complexity, technical debt and security posture, and a map of the system: which parts call each other, where the data comes from, which jobs run at night.Map of the system
- STEP 3Which rules are in it? The calculations, conditions and status changes, written down in plain language with their place in the code. Your people check them. From now on there is documentation that is right.Rules, with source
- STEP 4Make it safer A security scan of the running system: known vulnerabilities, outdated packages, secrets in the code, injection. Ranked findings and a fix for each, which you approve before it goes in. Passwords and keys are rotated on day one.Ranked findings
- STEP 5Handover and management The handover file (architecture, dependencies, rules with source, findings) becomes the basis of the management agreement: what we monitor, how fast we respond, what a change costs, how we report. Then we run it.Management agreement
Keeping it running is a job, not a phone number.
Management at Enigmatry is the same team that builds. The people who answer the phone can also change the code.
From keeping it running to making it grow.
Most systems we take over do not need to be replaced. They need someone who dares to change them again. Once the map and the rules exist, a change is no longer a gamble: we know what it touches, and the tests that record today’s behaviour have to pass.
So further development starts small: the screen everyone hates, the integration that breaks every month, the report that is assembled by hand. One piece at a time, with the map and the rules updated at every release.
And when the system reaches its limits, the modernisation plan is the next step, with the same team, from the same documentation. Management and modernisation are not two suppliers here.
We have been on both sides of a handover.
Incoming and outgoing. Most handovers go better once someone technical is in the room on your side. That is what we are for in the first weeks.
When the supplier cooperates.
We ask for the code, the pipelines, the configuration, the documentation that exists, and a few knowledge sessions. We write the handover file together, and the old supplier signs off that nothing is missing.
When the supplier does not.
We start from what you hold yourself: the running application, an export of the database, the contracts. We record the behaviour from the outside and build the knowledge back up from there. It takes longer, and we say which parts stay uncertain.
Day one.
All passwords, keys and certificates are replaced, access is on named people only, and the previous supplier’s access is closed. Whatever else is still open, this is done on day one.
Six things, before the first week.
The full list comes with the intake. Never production data.
A system that is yours again.
Four questions before anyone signs.
Do we have to migrate first?
No. Taking over and keeping it running comes first. Whether and when to modernise is a separate decision, and the handover file is exactly what you need to make it.
How long does a takeover take?
That depends on what is there. After step one we tell you: what is complete, what is missing, and how long the rest takes. We do not promise a date before we have seen the system.
What does it cost?
The takeover (steps one to five) is a proposal with a fixed price. Management is a fixed fee per month in the same proposal, based on what the handover file shows. Changes come from the backlog, each with its own estimate.
What if we want to leave later?
Then you take the code, the pipelines, the documentation and the data with you, and we do the handover the way we would want to receive one. That is in the agreement from day one, because we have been on the other side of it.
Tell us which system keeps you awake.
What it runs on, who built it, who still understands it, and what the contract with the current supplier says. In one conversation you hear whether we are the right party and what the first step would be.
Taking over and keeping it running, since 2006