Challenge
Every change takes longer than the last, nobody dares remove anything, and the knowledge sits with two people who are both needed elsewhere.
See the service →
The situation
Good work has been done for years. Every connection, every script and every report was built because someone needed it. Added together, a system has emerged that nobody oversees as a whole, and that is a different problem from a system that was badly built.
It shows up in lead time. A change that technically takes an hour takes three weeks, because working out what will break is the real work. A habit develops of never removing anything: leaving an old table in place is cheaper than establishing whether it is still used. So it only grows.
The reflex is to move to a new platform. That relocates the problem: without insight into what is actually used, you migrate the whole tangle along with it, including the scripts nobody can explain. On top of that both environments run side by side for a while, temporarily doubling the maintenance load.
There is a staffing side too. When the knowledge sits with two people, that risk grows the longer they remain indispensable, and it makes their work unattractive, because they never get to anything else.
What helps
Manageability starts with an overview, not with clearing out. Measuring what is used is the first step towards that, not the last.
Measure what actually runs
Which tables are queried, which reports opened, which connections used. That measurement makes the discussion factual, but it is not proof in itself: a year-end close or an external consumer leaves no trace for months. Measure, then trace dependencies, then have an owner sign off.
Get the knowledge out of people’s heads
A document on its own goes stale; simply adding people mostly spreads assumptions. It works when they go together: current runbooks, automated tests and rotation across the work. Maintenance that rests on one person is not maintenance.
Renew in pieces
Component by component, while the rest keeps running. Slower than a single migration on paper, often finished sooner in practice. With tightly coupled systems or expired support a targeted migration can be the right call: that is a judgement, not a rule.
Further reading
Service
Maintenance of data and AI systems under recorded agreements, including further development where needed.
Solution
A foundation that grows with you, so the next extension does not become another layer of sprawl.
Article
What it takes to turn something that came together fast into software an organisation can run on.
Twentynext does both. We renew a data platform in parts, while the rest keeps running, and maintain it afterwards under agreed terms. Building and maintaining come from the same team, so the knowledge does not stay with two people. We have worked from Eindhoven for organisations across the Netherlands since 2014.
Rarely. Without insight into what is actually used, you migrate the whole sprawl, including scripts nobody can explain, and two environments run side by side for a while. With tightly interwoven systems or expired support, a targeted migration can be the right choice: that is a judgement, not a rule.
Measure what actually runs: which tables are queried, which reports are opened, which integrations are used. Then trace dependencies and have an owner sign off, and get the knowledge out of people’s heads with current runbooks, automated tests and rotation across the work.
Work with us
The people who build it also run it afterwards. Eindhoven, since 2014.

Martijn van Grieken
Director Data & AI
We use Google Tag Manager to measure visits and Leadinfo to recognise which company is visiting. Neither loads unless you agree. If you choose essential only, the site works as normal and we measure nothing. If you arrived via an advertisement in ChatGPT, we also use the OpenAI measurement pixel to attribute conversions to that advertisement. Cookie statement · Privacy statement