Support for existing solutions
Not every system needs replacing. Most of them need someone who knows how they work, keeps them updated, and fixes things before they become urgent.
Old is not the same as broken
There is a persistent idea that software has a shelf life, and that a system built five years ago should be replaced on principle. In practice, plenty of systems built years ago still do their job accurately and quickly. What they usually lack is not modernity. It is someone paying attention.
The systems that genuinely need replacing are the ones that block the business: they cannot be changed without breaking, they cannot be hosted anywhere current, or nobody can work on them. Everything else is a maintenance question, and maintenance is dramatically cheaper than a rewrite. A rewrite also carries a risk that is easy to underestimate, which is that the new version will be missing the dozens of small behaviours the old one accumulated because a real customer once needed them.
Taking over something we did not write
Inheriting a codebase is its own skill. The documentation, if it exists, describes an intention rather than the current state. The person who knows why a particular workaround exists has usually moved on.
So we start by making the system observable to us. We get it running outside production, reproduce its current behaviour, follow the data through the integrations, and check what the deployment actually does. Only after that do we form opinions. The output of that first phase is a written map of the system, which is useful to you regardless of what we do next, because it turns knowledge that lived in one person's head into something your company owns.
How long that takes depends less on the size of the codebase than on how unusual it is. A conventional application built on a familiar framework can be understood in days. A system with a homegrown framework, undocumented data migrations and business rules encoded in database triggers takes considerably longer, and we would rather say that at the start than discover it halfway through a fixed quote.
Stabilise before improving
There is a strong temptation to start with the visible problem, the thing that has been annoying people for months. We generally do not, because the first job is reducing the chance of a bad week.
That usually means checking a few unglamorous things:
Backups exist, run on a schedule, and have actually been restored at least once to prove they work.
There is somewhere to test that is not production.
Deployments can be reversed, so a bad release is an inconvenience rather than an incident.
Credentials are not sitting in the repository, and access is limited to people who still work there.
Something tells us when the system is down, other than a customer.
Once those are true, everything else gets safer and faster, including the visible problem.
Steady maintenance, then a real decision
After stabilisation, the work becomes a rhythm. Reported bugs get fixed. Dependencies are updated far enough to stay supported, weighed each time against the risk of disturbing something that currently works. Integrations get adjusted when a supplier changes their API. Small changes get made as the business needs them.
Most of that work is unremarkable. A form that stopped sending mail because a provider tightened its sending rules. A report that needs one more column. A page that renders badly on a screen size that did not exist when it was built. None of these is interesting on its own, and together they are the difference between a system people trust and one they quietly work around.
Alongside that, we keep an eye on the honest question: is maintaining this still cheaper than replacing it? That answer changes over time, and it usually changes for a specific reason rather than a general one. A framework version goes out of support and the upgrade path is blocked. A change that should take a day starts taking a week because of accumulated coupling. Hosting for the required runtime becomes hard to find.
When we think you have reached that point, we say so, and we say which part to replace first. Rewriting a system in one go is rarely necessary. Replacing the piece that has become expensive, while the rest keeps running, usually is.
What you get
Handover of a system we did not build
We read the code, run it locally, and work out how it actually behaves rather than how the documentation claims it behaves. That is the part most handovers skip.
A safe way to change things
Before touching anything, we make sure there is a working backup, a non-production environment and a deployment path that can be reversed.
Fixes and small changes
Reported bugs, broken integrations, content and configuration changes, and the small feature adjustments that keep a system usable as the business shifts.
Dependencies kept alive
Frameworks, libraries and runtimes are updated far enough to stay supported and secure, weighed against the risk of breaking something that currently works.
Documentation of how it really works
As we learn the system we write it down: the architecture, the integrations, the deployment steps and the known landmines that new people always step on.
An honest maintain-or-replace verdict
At some point maintenance stops being the cheaper option. We tell you when we think you have reached that point, and which parts to replace first.
How we work
- 01
Read the system and run it
We get the code, the access and the hosting details, stand the project up outside production and confirm we can reproduce its current behaviour before proposing anything.
- 02
Assess the real risks
We look for the things that would hurt: unsupported runtimes, missing backups, hardcoded credentials, integrations that will break when a supplier changes, single points of failure.
- 03
Stabilise first
The first work is whatever reduces the chance of an incident. Backups, access, monitoring and the most exposed dependencies come before feature requests.
- 04
Take over routine maintenance
Updates, fixes and small changes move into a regular cycle, with a single point of contact so you are not chasing whoever is available.
- 05
Revisit the bigger question
Periodically we review whether continued maintenance still makes sense, or whether a specific part has become expensive enough to be worth rebuilding.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- WordPress
- WooCommerce
- PHP
- Laravel
- Symfony
- Node.js
- React
- MySQL
- PostgreSQL
- Docker
- Git
- Sentry
Frequently asked questions
Related work
More services in this category
Infrastructure organization
Infrastructure that grew one urgent decision at a time is hard to change safely. We map what you actually have, retire what nobody owns, and write down the rest.
Service management and environment configuration
Most outages start as configuration that drifted quietly out of date. We keep your environments consistent, updated and described well enough that changes stop being a gamble.
Monitoring and rapid problem response
Monitoring only pays off if someone acts on it. We instrument the systems we maintain, keep the alerts trustworthy, and handle what they surface.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
Latest
Technical guides, security insights, and what we've learned building with AI.
Inherited a system nobody fully understands anymore?
Message usTell us what the system does and who built it, and we will outline how a takeover would work, starting with a safe way to run and change it.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more