Build · Modernisation & Integration

Inherited systems, stalled builds and the estate nobody wants to touch

Architecture, APIs, cloud, data migration and legacy replacement. The work usually starts with an independent assessment of what you have, because the most expensive decision in modernisation is the one taken before anybody looked properly.

What we do

From an assessment you can buy on its own, through to a replacement programme that keeps the business running while it happens.

Independent technical assessment

A written view of what you have: architecture, code health, security posture, dependency age, delivery risk and what it would cost to continue. Bought on its own, before anyone commits to a direction.

Architecture and code review

Where the system is actually failing, as distinct from where it is merely unfashionable. Those are different lists and only one of them is worth funding.

Incremental replacement

Route by route and capability by capability, with the old system live throughout. Slower on paper than a rewrite, and considerably more likely to arrive.

API and integration layers

A deliberate seam between the systems you keep and the ones you replace, so the next change does not require the same excavation.

Data migration

Mapping, cleansing, reconciliation and the cutover plan, including how you prove afterwards that nothing was lost.

Cloud migration and re-platforming

Moving the estate without treating the move as a rewrite, then addressing the parts that genuinely need rebuilding once it is stable.

Straight talk

Four things suppliers rarely volunteer

The rewrite is the risky option

A full rewrite spends its first year rebuilding functionality you already have, against a moving target, with no route back.

Legacy is where AI helps least

Published evidence puts coding-assistant gains far lower on complex existing code than on greenfield work, which is precisely why this stays careful human engineering.

The seams carry the risk

Most modernisation failures happen at the boundary between old and new, not inside either one.

Reversibility is the feature

Every step should be one you can stop at without leaving the business half-migrated.

DORA 2026 and METR, 2025–2026

None of that means never rebuild. It means the decision should follow evidence about your specific estate, and the evidence should be produced by someone who is willing to lose the larger piece of work by telling you the truth.

Rescue and modernise

Assessment before further investment

Stalled builds, inherited codebases and projects where confidence in the current supplier has gone all share a problem: the next decision has to be made without reliable information. An independent assessment produces that information, and it is deliberately available as its own engagement so you are not buying a recovery programme in order to find out whether you need one.

If the finding is that the existing team should continue, that is the finding.

What an assessment covers
  1. 01Architecture and data model

    What was built, and what it implies about change cost

  2. 02Code health and test coverage

    How safely anything can be altered today

  3. 03Security and dependency posture

    What is unsupported, exposed or out of date

  4. 04Delivery and options

    Recovery, incremental replacement or rebuild, with costs

How we deliver

FAQs

Questions worth answering

Can you take over an existing or stalled build?

Yes. The usual starting point is an independent technical assessment covering architecture, code health, security posture and delivery risk, together with a recovery plan and a cost of continuing, before anyone commits to further development.

Should a legacy system be rewritten or modernised in place?

Modernised in place, in most cases. A full rewrite spends its first year rebuilding functionality that already exists, against a moving target, with no route back. Incremental replacement keeps the current system live while capabilities move across one at a time, and every step is one you can stop at.

Does AI make legacy modernisation cheaper?

Much less than it makes greenfield work cheaper. Published evidence puts coding-assistant gains substantially lower on complex existing code, so a modernisation programme should not be priced as though a tool will absorb the difficulty. We quote on what the estate actually is.

Inherited something difficult?

Bring us the system and the decision you are trying to make about it. An assessment is a small piece of work and it is the one that stops a large one going wrong.