Legacy Application Modernization
Modernize without the rewrite gamble
We replace aging financial systems in slices, with a rollback path at each step.
- Incremental migrationno big-bang cutover
- Off the monolithto modular services
- Data migrationnothing lost
- Zero downtimeruns through cutover
- Maintainableyour team can own it
Why teams bring us in
The call usually comes after a plan for one big migration weekend fell apart.
The people who wrote it have gone
Payment logic, fee tables, and dunning rules sit in COBOL programs nobody on the current team has opened. The documentation stops well short of the code. We treat the source as the specification, replay it against production data, and write down what the system does before anyone argues about changing it.
Release trains measured in quarters
A change to a product rule waits for the next core release window, and the window moves. Meanwhile the product team has committed to a launch date. We carve the fast-moving pieces out first, put them behind an API, and give that team its own deployment path while the core keeps its release calendar.
Nobody will approve a weekend switch
The board has seen a migration weekend go wrong, so the appetite for one is gone. Incremental delivery gives them something to approve in pieces. Each step ships behind a routing switch, runs against live traffic in shadow mode, and gets reverted by a configuration change instead of a restore from backup.
Assessment and roadmap
Nothing gets migrated before we know what runs and what only looks like it runs.
Code and dependency archaeology
We inventory the programs, jobs, copybooks, and stored procedures, then map which ones still run in production and which have been dead for years. Static analysis gives the call graph. Job schedules and database access logs give the truth about usage. The output is a dependency map you can point at during a planning meeting.
Slice order and sequencing
Not all of the monolith is worth moving, and the order matters more than the target architecture. We rank candidate slices by transaction volume, change frequency, regulatory exposure, and how tangled the data is. Low-risk slices go first to prove the pipeline works. The ledger and the payment path go last, once the pattern has been exercised.
Cost, risk, and rollback plan per step
Each roadmap step carries an estimate, the reconciliation checks that prove it worked, and the route back if it did not. Finance sees where the licence and mainframe MIPS spend drops. Risk sees which control moves and who signs off. Nobody has to accept a plan whose only checkpoint sits at the end of the programme.
Migration engineering
The monolith comes apart one function at a time, with the old path left standing.
Strangler-fig routing
A facade sits in front of the legacy entry points, so callers keep the same contract while the implementation behind it changes. One function at a time moves to the new service, with the facade deciding per request which side handles it. Traffic starts at a trickle for internal users. The legacy path stays warm and callable throughout.
Re-architecture your team can staff
Target design follows what the client can hire for. Java or .NET with Postgres and Kafka beats an exotic stack that one contractor in the region understands. We keep service boundaries close to the business domains the old system already implied, because those boundaries survive reorganisations. Kubernetes shows up when the operating team asks for it.
Data migration with reconciliation
Nightly extracts hide differences that only show up at month end. We move data in a versioned pipeline, keep both stores writable during the overlap, and compare balances, counts, and checksums after each batch. Breaks get investigated before the next slice moves. The migration scripts stay idempotent, so a failed run can be replayed without duplicating rows.
Business rules read out of the old code
Interest accrual, eligibility, and fee waivers were encoded by people who talked to the regulator in person. We extract those rules into readable form, replay them against historical cases, and have a business owner confirm the outputs match. Only then do they move into a rules engine or service code. Blind rewrites are how a rounding rule quietly changes.
Cutover and handover
Cutover is a dial, watched by your operators and reversible by configuration.
Parallel run against live traffic
Both systems process the same input for a defined period, and only one of them is authoritative. The new service answers in shadow mode while its output is diffed against the legacy result. Mismatches land in a queue with the request payload attached. The run continues until the diff rate holds flat across a full month-end cycle.
Gradual traffic shift with a way back
Cutover happens as a percentage, moved by configuration and watched on a dashboard the client's operators own. A canary group goes first, then a product line, then the rest. Error rates, latency, and reconciliation breaks each have a threshold that flips routing back to legacy without a deploy. Sessions in flight finish on the side that started them.
Documentation and handover to your team
Handover starts in the first sprint, because a document written at the end is a document nobody reads. Client engineers pair on the slices, own runbooks for the services they will operate, and take the on-call rotation before we leave. Architecture decisions stay in the repository with the reasoning, including the options we rejected. Nothing lives only in our heads.
How we work
Replacing a system that cannot be switched off is a sequencing problem before it is an engineering one.
Presales engineering
Our architects read the estate first: what the system does, what depends on it, which parts carry regulation, and where the data actually lives. You get a System Design and a migration plan from that stage.
Characterisation first
Legacy systems are under-documented and over-relied-on. We write tests that capture what the system does today, including the behaviour nobody intended, so a refactor has something to be correct against.
Strangler-fig delivery
New capability sits alongside the old system behind a routing layer, taking traffic slice by slice. The legacy path stays live until its replacement has earned the traffic.
CI/CD from the first slice
Pipelines, migrations and rollback belong to the first increment rather than a hardening phase. A modernization that cannot be deployed safely is not modernized.
Two systems, one source of truth
The legacy core keeps answering until reconciliation shows the new service agrees with it, request by request.
What you get
A dependency map of what you run
An inventory of programs, jobs, and data flows, marked with what production traffic touches and what has been idle. Dead code gets flagged for retirement instead of migration. The map outlives the project and gives the next audit a starting point.
Business rules written down in plain language
Extracted rules with their source program, the historical cases used to verify them, and a business owner's sign-off. Auditors get a document. Your engineers get something they can change next year without opening the COBOL listing that nobody wants to touch.
Deployments measured in days
Once a slice sits in its own service with tests and a pipeline, the team behind it stops waiting on the core release calendar. Product changes that used to need a quarterly window ship inside a sprint. The core release train keeps running for what remains on it.
A stack your own team runs
Runbooks, dashboards, and on-call ownership sit with client engineers before the engagement closes. We stay available for a defined support window after handover. The exit is planned at the start, so continuing with us becomes a choice about the roadmap instead of a rescue.
Where this works best
The cheapest conversation about a rewrite is the one that happens before it starts.
Talk to the team who would build itGood fit
A system that runs the business, cannot be switched off, and now blocks the roadmap, under regulation that makes a big-bang replacement unacceptable.
Not a fit
A rewrite motivated by the stack being unfashionable rather than by a business constraint. We will tell you during Discovery.
Questions
The questions that come up in the first call, answered plainly.
How long before we see anything working?
The first slice usually reaches production inside the first few months, and it is deliberately a small one. Assessment runs in parallel with early engineering rather than blocking it. We pick a low-risk function with clear boundaries, ship it behind the facade, and use it to prove the pipeline, the reconciliation checks, and the rollback route before anything touches the ledger.
What happens if a slice goes wrong in production?
Routing flips back to the legacy path, which is still running and still holds the data it needs. Because the shift moves in percentages under configuration control, the revert is a setting change made by the operations team, no release required. Anything written during the window gets reconciled against the legacy store, and the mismatch queue tells us what to replay.
Nobody here understands the COBOL any more. Is that a blocker?
It is the normal starting condition. The code is the specification, so we read it, trace the paths that production data exercises, and rebuild the rules as executable tests. Historical transactions become the check. Your business people confirm the outputs against cases they recognise, which is a shorter conversation than asking them to describe a fee rule from memory.
Can we keep the mainframe running during all this?
Yes, and for a while you should. The legacy core stays authoritative until reconciliation says otherwise, which is what makes the parallel run useful. Licence and MIPS costs come down as workloads move off, step by step, and the decommission decision arrives when the last slice has been stable for an agreed period. Some clients keep the mainframe for a narrow set of batch jobs.
How do you work with our in-house team?
Mixed teams, with your engineers on the slices from the first sprint. We do the parts you have no bandwidth for and the parts that need migration experience, and your people own the domain knowledge and the eventual operation. Code review runs both ways. By the time we hand over, the runbooks have been used by the people who will keep using them.
Part of Billing
Billing systems that charge the right amount and reconcile without a spreadsheet.
Make recurring revenue
predictable.
Involuntary churn, failed renewals, a billing engine that fights you? Tell us what's leaking and we'll fix the pipeline.