Discover: mapping a system across a wall of diagramsDiagnose: reading dashboards to locate the problemDesign: wireframes and interface work for the solutionDeliver: shipping the finished productEvolve: continuous improvement after launchAn ageing system being re-platformed piece by piece
Assess · Replace · Run

Platform modernisation

Modernisation for a system that still earns money and cannot be switched off for a rewrite. We replace it a seam at a time, with the old path running in shadow until the new one has been proven on the same traffic, in the same month.

  • Live
    Throughout the work
  • Seam
    At a time, not all
  • Shadow
    Run before cutover
  • Back
    Out at every step

Sectors that trust us

What is modernisation?

Modernisation is moving a working system onto something maintainable without an outage and without a period where neither version is trustworthy. It is mostly a sequencing problem: which seam to cut first, how to prove the replacement on real traffic, and when the old path can finally be deleted.

Modernise or rewrite?
A rewrite asks the business to stop needing changes for a year, which no business can honestly agree to.
Is the old code the problem, or the process around it?
Usually not. The problem is that nobody can change it safely, which is a testing and deployment problem.

Key takeaways

  • Always live: the system stays in service for the whole of the work, with no freeze agreed.

  • Proven in shadow: each seam serves real traffic silently before it is allowed to answer anyone.

  • Rehearsed rollback: every step has a way back that has been run on purpose, not just written down.

  • Deleted on a date: the old path is switched off by a dated plan rather than left running forever.

  • Yours to change: your team can alter the result without a call to us, which is the real test.

Why modernise

Leaving it alone only defers the risk.

How rewrites fail

  • A freeze is agreed, then quietly broken by month two.

  • Both systems run for years because neither is trusted.

  • The new version is tested on invented data, not real.

  • Cutover is one night, with no way back after it.

How we replace

  • The seam is chosen for value, and shipped in weeks.

  • Old and new run together on the same real traffic.

  • The two are compared daily until they stop differing.

  • Rollback is rehearsed, so cutover is boring.

What we replace

Modernisation delivered seam by seam, with the system still live.

  • Seam assessment

    Where the system can be cut, in which order, and what each cut is worth once it has landed in production.

  • Data migration

    Schema, backfill and the reconciliation that proves both stores agree before the old one is switched off.

  • Shadow running

    The new path serving the same live requests, its answers compared against the old ones but not yet returned.

  • Decommissioning

    The old path switched off on a dated plan, which is the only real end of the work and the part most teams skip.

Three routes

One route per component, chosen by evidence.

  • Lift

    Rehost

    The running system moved onto managed infrastructure, its code left exactly as it is.

    Weeks, lowest risk
  • Most chosenReshape

    Replace by seam

    One boundary at a time, old and new sharing live traffic, the old path then deleted.

    Months, no outage
  • Rebuild

    Rewrite a part

    Only where code resists every other route, and only a part small enough to finish.

    Rare, by exception

The stack we move to

Current, well supported, deliberately boring.

  • TypeScript
  • Node.js
  • PostgreSQL
  • Kubernetes
  • Docker
  • Kafka
  • Terraform
  • GitHub Actions

How it works · our method

The SiaSol five-phase method, applied to this service.

  1. 01

    Discover

    Most technology projects fail long before the first line of code — they fail at the question.

  2. 02

    Diagnose

    Every slow process has an owner and a cost.

  3. 03

    Design

    Architecture is a set of decisions you live with.

  4. 04

    Deliver

    Software not in production is just cost.

  5. 05

    Evolve

    The handover is the point, not the end.

Where we work

Close where it counts, bilingual everywhere

  • Egypt: Cairo (HQ) and nationwide delivery

  • Saudi Arabia: Riyadh, with teams on client time zones

  • Gulf and beyond: Arabic and English, one delivery standard

Cost & engagement

Modernisation: cost and engagement

Cost follows the number of seams and how much data has to move. We quote the assessment alone, because any number before the map is a guess.

  • Fixed · two to three weeks

    Seam assessment

    The map of where the system can be cut, in order, with a number against each.

  • Per seam · quoted from the map

    Seam delivery

    One seam replaced, proven in shadow, and the old path dated for deletion.

  • Monthly · dedicated

    Embedded team

    A standing team working through the map alongside yours.

Why teams bring us the system nobody wants to touch.

Because we are willing to leave most of it alone. The brief is to make the system changeable, not to make it ours, so the assessment names the seams worth cutting and says which parts should stay. The people who kept it running are our main evidence, and they still own it when we leave.

FAQ

What to ask about Platform modernisation.

01Can we keep shipping features meanwhile?

Yes, and the plan assumes you will. A sequence that needs a feature freeze is abandoned by month two, so each seam is scoped to leave the rest of the system untouched and releasable while it is replaced.

02What does shadow running actually mean?

The new path receives a copy of real requests and computes its answer, which is recorded and compared with the live one rather than returned. Differences are investigated daily until none remain; only then does it serve.

03How long before we see anything?

The assessment takes two to three weeks and ends with a map you can act on without us. The first seam usually ships four to six weeks later, deliberately early: a plan whose first result is months away cannot be corrected in time.

04What if the assessment says not to modernise?

Then it says so, and that is a successful assessment. Some systems are stable, understood and rarely changed, and the honest answer is to spend the budget elsewhere. That conclusion is cheaper than discovering it in month eight.

05Do you work with our existing team?

Yes, and their knowledge is the main input. The people who have maintained the system know where it resists change, which is exactly what the assessment looks for. Replacing them with us would discard the best evidence available.

06Can the old system be switched off completely?

That is the definition of done, written into the plan with a date rather than left as an aspiration. A modernisation that ends with both systems running has not finished; it has produced a second system to maintain.

07Who owns the result when you leave?

You do, and the handover is a dated document plus a walkthrough. Cloud accounts, repositories, runbooks and the on-call path are in your name from the first seam, not transferred at the end as a formality.

Related services

Often paired with this

Learn more

From the journal

Ready to replace the system without ever switching it off?

Tell us what the system does today and who depends on it. We come back with a seam map, an order of work and a number.

Book assessment