Legacy Modernisation.
Replacing the old system without stopping the business.
Drema modernises legacy systems incrementally. We route functionality away from the old application piece by piece behind a stable interface, so value arrives continuously and there is never a single night on which everything must work. Big-bang rewrites are the approach we are usually called in to rescue.
Replacing the old system without stopping the business.
What usually
goes wrong.
The system runs the business and nobody wants to touch it. The framework is years past end of life, the original developers have gone, there are no tests, and every change carries the risk of breaking something nobody remembers exists.
Everything that ships
with this work.
Not a menu to choose from. Each piece is here because leaving it out is what makes this kind of project fail six months later.
System archaeology
Mapping what the system does, what it integrates with, and which parts are genuinely still used.
Risk-ranked roadmap
A sequence ordered by business risk and value, so the dangerous and valuable parts move first.
Characterisation tests
Tests that capture current behaviour — including its quirks — giving a safety net before any change.
Strangler-pattern migration
A routing layer that sends traffic to new implementations feature by feature, reversibly.
Database modernisation
Schema evolution and data migration with dual-write and reconciliation where downtime is unacceptable.
Decommissioning plan
Retiring the old system only once the evidence shows nothing still depends on it.
The order matters more
than the tools.
Most of what separates a project that lands from one that stalls is sequence. This is the order we work in, and why each step comes where it does.
- 01
Understand before changing
Undocumented behaviour is usually load-bearing. We learn what it does before we touch it.
- 02
Establish a safety net
Characterisation tests and monitoring so regressions are detected immediately.
- 03
Insert a seam
A routing layer in front of the legacy system that lets traffic be redirected per feature.
- 04
Migrate incrementally
One capability at a time, each independently reversible if the numbers look wrong.
- 05
Retire
Switch off old paths once usage data confirms they are genuinely dead.
Where this gets
put to work.
The situations this service is built for. If one of these sounds like your problem it is worth a conversation — and if none of them do, say so on the call and we will point you at what would actually fit.
End-of-life frameworks
Moving off unsupported versions that have become a security exposure.
Monolith decomposition
Extracting the parts that need to scale or change independently — without splitting everything.
On-premise to cloud
Re-platforming with a migration path that does not require a shutdown weekend.
Rescuing a failed rewrite
Recovering a big-bang replacement that has stalled, by restructuring it as incremental delivery.
Have a use case that is not on this list? That is usually the interesting one.
Chosen to fit,
not to impress.
We pick tools that suit the problem and that your team can maintain after we hand over — never to pad a capability list.
Questions we
get asked.
Straight answers, including the ones that talk you out of work we would otherwise be paid for.
Should we rewrite from scratch?
Almost never in one go. A rewrite means running two systems while the new one catches up on years of accumulated business rules, during which the business cannot stand still. Incremental replacement delivers value throughout and can be stopped at any point with the gains kept.
How do you avoid breaking things nobody documented?
Characterisation tests that capture the current behaviour before we change anything, plus monitoring that compares old and new paths in production. Where behaviour is odd we preserve it deliberately and question it separately from the migration.
Can we keep shipping features during modernisation?
Yes, and you should — a feature freeze is what turns modernisation into a political problem. Incremental migration means new work goes into the new architecture while the old system continues serving what has not moved yet.
How long does it take?
It depends on system size, but first value should land within weeks, not years. If a plan has nothing in production for the first six months, we would push back on that plan.
What if the original developers are gone?
That is the normal case. We reconstruct understanding from the code, the database, logs and the people who use the system daily, who often know its behaviour better than any document does.
Can you work with an unfamiliar old language?
Frequently, yes — the analysis and migration patterns transfer even where the language is unusual. If we genuinely are not the right team for a specific stack, we will say so rather than learn on your budget.
Talk it through with a founder.
Bring the actual problem. You will get a straight answer on whether legacy modernisation is the right approach
— including when it is not.
