MENTARA
Book a call
Software Services

Modernisation fails as a programme and succeeds as a sequence.

Rewrites stall because they ask a business to fund two years of no visible change. MENTARA decomposes modernisation into increments that each stand alone.

Discuss an engineering priority Read the detail

More in Software Services

The decision in front of you

Most modernisation programmes are approved as a single large commitment and then quietly abandoned somewhere in year two — not because the engineering was wrong, but because the business could not keep funding a change it could not see, while the old system still needed maintaining alongside it.

The alternative is not a better plan for the same shape of work. It is a different shape: decomposition into increments that each deliver something on their own, so the programme survives a change of sponsor, a budget cycle, or a shift in priority. That constraint should drive the technical sequencing, and usually does not.

The failure mode

The rewrite that has to finish before anything improves.

The instinct facing a difficult legacy system is to rebuild it properly. It is often technically the cleanest answer and it is usually the one that fails, because it requires the organisation to fund parallel running — two systems, two sets of changes, two sets of defects — for as long as the rebuild takes, while receiving no benefit until the end.

Meanwhile the old system cannot be frozen, because the business still needs changes. So the target is moving, the rebuild falls behind, and at some point someone reasonable asks why a large sum has produced nothing users can see. That question is usually fatal, and it is a fair question.

Decomposition is harder and works better: identify a capability with a real boundary, route traffic through a seam, move it, retire the old path, and repeat. Each step is independently valuable and independently abandonable. This is well understood in principle and rarely done, because the first seam is genuinely difficult to find in a system with no clean boundaries, and finding it requires senior engineering judgement applied to your specific mess rather than a reference architecture.

Capability

What MENTARA does.

01Application modernisationDecomposition strategy, seam identification, strangler routing and incremental migration — sequenced so each increment stands alone and the programme can stop without stranding you.
02Product and experience engineeringBuilding and evolving the applications your customers and staff actually use, with the discovery and instrumentation to know whether changes worked.
03Integration engineeringThe connective work that determines whether modernisation is possible at all — APIs, events, contracts and the anti-corruption layers that let new and old coexist during transition.
04Quality and release engineeringTest strategy, pipelines and release practice that make frequent change safe. Without this, decomposition is riskier than the rewrite it replaces.
05Platform and developer experienceReducing the friction between a change being written and being live — usually the largest and least examined constraint on delivery pace.
Approach

How the work runs.

  1. 01 Map the seams, not the architecture

    Where can this system actually be cut, given its data model, transaction boundaries and hidden coupling? This is the analysis that determines whether incremental modernisation is even available to you.

  2. 02 Sequence by value and risk

    Order increments so early ones deliver visible benefit and reduce risk in the ones that follow. The first increment's job is partly to prove the pattern to a sceptical sponsor.

  3. 03 Build the safety net first

    Characterisation tests, observability and release controls before moving anything. Modernising without these is how a migration becomes an incident.

  4. 04 Migrate and retire

    Move the capability, route traffic, and actually decommission the old path. Retirement is the step that gets skipped, and skipping it means you now maintain both — the outcome the programme existed to avoid.

Starting points

Where engagements usually begin.

01Modernisation readiness assessmentWhether incremental decomposition is viable for your system, where the seams are, and what sequence the technical constraints actually permit.
02First incrementOne capability taken end to end — extracted, migrated, old path retired — as proof the pattern holds before a larger commitment.
03Delivery pace diagnosisWhy changes take as long as they do. Usually environments, test reliability and release process rather than engineering capability.
04Integration foundationThe API and event layer that makes subsequent modernisation possible, built as its own deliverable.
Questions

What buyers ask.

Should we rewrite or modernise incrementally?

Usually incrementally, but not always. A full rewrite can be right when the system is genuinely small, when the domain has changed so fundamentally that the existing model is an obstacle, or when the platform is at end of life with a hard date.

The assessment is short and worth doing before committing, because the two paths have very different funding profiles and the wrong choice is expensive to reverse.

Can you work alongside our existing engineering team?

That is the normal arrangement. We are usually most useful supplying senior engineering judgement — decomposition strategy, seam analysis, release safety — alongside a client team that knows the domain far better than we will.

Where you also need capacity, it comes through Workforce Solutions under the same lead and the same plan rather than as a separate supplier relationship.

What if our system has no documentation?

That is the normal condition, and it is why seam analysis is engineering work rather than a document review. Behaviour is established from the code, the data and production observation, and characterisation tests capture what the system actually does before anything is changed.

07

Where MENTARA fits best.

Scope

We fit where the constraint is finding the right sequence and proving it — the first increments, the seam analysis, the release safety that makes the rest possible — with a small senior team rather than a large one.

A very large multi-year rewrite needing dozens of engineers from day one is a scale requirement, and a large integrator serves it better.

Where this connects

Bring the modernisation that has stalled.

Share the business context, constraints and expected outcome. MENTARA will identify the relevant accountable route.

Submit your requirement

One partner. One plan. Measurable outcomes.