What does 'can't evolve' actually look like?
Crescentic re-engineers software that already runs your business — infrastructure, front end, data model, and AI where it genuinely helps. We work incrementally on live systems rather than betting the company on a rewrite, and the engineers who learn your system stay on it. This page is for CTOs and engineering leaders with a system that works, matters, and has become the thing slowing everyone down.
Rarely a crisis. Usually a slow accumulation of things nobody has time to fix, until the sum of them means a two-day change takes three weeks. The system is not failing. It is just no longer somewhere your team can move quickly, and everyone has quietly started routing around it.
- A build that fails intermittently, or takes long enough that nobody runs it locally.
- A framework several major versions behind, where upgrading is a project nobody will fund.
- Infrastructure that exists as configuration on machines, held in one person's memory.
- A data model that hard-codes an assumption — a supplier, a country, a plan type — that stopped being true.
- Deployment that is a procedure someone performs rather than a pipeline that runs.
These are all the same problem wearing different clothes: the cost of change has gone up until it exceeds the appetite for change. The work is bringing that cost back down, in the order that unblocks the most.
We re-engineer without burning it down.
Evolution, not replacement. The system stays live and keeps shipping while the constraining pieces are replaced underneath it, one at a time and reversibly.
What does modernization work look like in practice?
Compliance software has an unusual property: the rules change under you, in 170 jurisdictions, and the product has to keep shipping anyway. There is no quiet period to rebuild in. That is the context for the clearest example we can give of this work.
Note what is not in that story: a rewrite, a migration weekend, or a period where the product stopped shipping. The platform served its customers throughout.
How do you modernize a system without stopping the business?
- 01
Find the actual constraint
Not the thing that is most annoying — the thing that is most expensive. Frequently it is the release path rather than the code, and fixing that first makes everything after it cheaper.
- 02
Make change safe before making changes
Reliable builds, a deployment you can repeat, and a way back. Until reverting is routine, every improvement carries risk that has nothing to do with the improvement.
- 03
Replace one piece at a time, in production
Infrastructure into code, the framework forward, the data model corrected — each shipped and verified on its own rather than merged into one all-or-nothing cutover.
- 04
Then add what wasn't previously possible
AI features, new integrations, the roadmap that was blocked. This is the point of the exercise, and it comes last because it only works once the system can change.
Is a schema change on a live system really possible?
It is the hardest version of this work, so it is worth being concrete about. On an eSIM commerce platform we built, the first version had been built against a single supplier and the supplier’s name had gone into the domain model — the table was called airalo, the join column airalo_order_id. That is fine until the business needs a second supplier for a country the first covers badly, and discovers a vendor’s name is load-bearing across the schema of a live store with real orders in it.
We took it out reversibly, while the store kept trading, without breaking a historical order. The supplier we migrated to now carries roughly three quarters of a 7,700-plan catalogue — which is the actual measure of whether the migration worked.
Where does AI belong in an existing system?
Later than the pitch decks suggest. A model layered onto a system you cannot deploy reliably inherits every problem that system already has, and adds non-determinism to them. The order matters: make the system changeable, then add the AI it can now support.
When it does fit, the useful applications are unglamorous — extracting structure from documents nobody has time to read, classifying work as it arrives, search across material that is too large to review by hand. Each of those needs an answer to the same question before it ships: what happens when the model is wrong, and who finds out.
| Full rewrite | Patch in place | Incremental modernization | |
|---|---|---|---|
| Time to first benefit | End of the project, if it lands | Immediate, then it stops | Weeks, then continuously |
| Risk profile | One large bet | Low, and accumulating | Many small reversible ones |
| Business disruption | Feature freeze while it runs | None | None — the system stays live |
| Undocumented behaviour | Has to be rediscovered | Preserved by accident | Preserved deliberately |
| Typical outcome | Overruns, sometimes cancelled | Constraint returns, worse | Cost of change comes down |
Where to start
Usually with a short, paid assessment: we go through the codebase, the infrastructure and the release process, and come back with what is actually constraining you, the order to deal with it in, and what that costs. You own the output regardless of whether you carry on with us.
Occasionally the assessment concludes that the thing you thought was the problem is not the problem. That is a good outcome, and we would rather find it in two weeks than eight months in.
01.What is legacy system modernization?
It is re-engineering software that already works so it can keep changing. The system is usually not broken — it is running the business — but something about it has become the constraint: the build, the deployment process, a framework that is years out of support, or a data model that assumes something that stopped being true. Modernization is removing that constraint without stopping the business that depends on the system.
02.Should we rewrite our legacy system or modernize it?
Almost always modernize. A rewrite asks you to reproduce years of accumulated behaviour — including the undocumented parts that only exist because a real customer needed them — while the original keeps moving and no one gets new features. Rewrites are the projects that quietly run for two years and get cancelled. We replace the constraining pieces one at a time, in production, with the system live throughout. A full rewrite is occasionally right, and we will say so, but it should be a conclusion rather than a starting assumption.
03.Can you modernize a system without downtime?
That is the normal expectation, and it shapes how the work is sequenced. Changes go out incrementally and reversibly, behind the ability to go back, rather than as one migration weekend. We have taken a supplier's name out of the database schema of a live commerce store, mid-trading, without breaking a historical order — that is the standard the approach is built around.
04.Where does AI actually fit into modernizing an old system?
Usually later than people expect. A model layered onto a system you cannot deploy reliably inherits every one of that system's problems and adds non-determinism. The sequence that works is: make the system changeable, then add the AI that the newly changeable system can support. When it does fit, the wins are unglamorous and real — extraction from documents, classification, search over material nobody can read at volume — and each one needs a plan for what happens when the model is wrong.
05.How do you work on a system your team knows and you don't?
We read the code and the deployment path before proposing anything, and we expect the first weeks to be slower than they look. The knowledge that matters is rarely written down: which service cannot be restarted during business hours, which table is load-bearing for a report someone runs monthly. We find that by working in the system, alongside your team, not by asking for documentation that does not exist.
06.What does an assessment involve before you commit to work?
A short, paid engagement where we go through the codebase, the infrastructure and the release process, and come back with what is actually constraining you, in what order it should be dealt with, and what it will cost. Sometimes the answer is that the thing you thought was the problem is not. You own the output whether or not you continue with us.
The rest of what we do
Build
New products from idea to launch — web, mobile, and AI-native — with the same team after.
Read more →Lead
Fractional CTO leadership, technical strategy, and due diligence when you need a senior technical voice.
Read more →For agencies
Delivery capacity and specialist engineers for agencies and enterprise teams that need a partner.
Read more →