service · legacy modernisation

"Only Dave knows how it works." And Dave's retiring.

A critical process running on something old, undocumented and fragile is a quiet emergency. We unpick it, document what it actually does, and replace it safely. Sometimes that's an incremental migration, sometimes a clean planned cutover. We pick whichever genuinely de-risks your situation, and nothing goes live until it's proven.

in plain terms

Legacy modernisation means safely replacing the fragile, undocumented system everyone's scared to touch - we map how it really works, then migrate it incrementally or cut over cleanly, whichever de-risks it, and remove the key-person risk that came with it. A legacy system is anything critical that's fragile, undocumented, depends on one person, or runs on software no one supports anymore; if the policy is 'don't touch it, it works', it qualifies. Rather than rip and replace blind, we document what it actually does first, then choose the lower-risk path and bring your existing data and history across, verified against the old system before anything is switched off. We document as we go, so the knowledge ends up in the system and the team instead of in one person's head - which is usually the real risk you're carrying.

De-risk my system →

the quiet emergency

When you can't upgrade, integrate, or audit it.

Key-person riskOne person understands it, and they're leaving, retiring, or already gone.
Frozen in placeCan't upgrade, can't integrate, can't audit. Everyone's scared to touch it.
Held together with tapeAn Access database, a VBA-laden workbook, an ancient line-of-business app, or a tangle of scripts.
No safety netIf it breaks, the business stops, and nobody's sure how to put it back.

how we do it

Document first. Then the right kind of cutover.

Incremental or big-bang isn't a religious question. It's a risk call. We make it deliberately, never by ripping it out and hoping.

Discovery & documentation

We map what it actually does (the data, the integrations, the failure modes) and write it down. This alone removes the key-person risk, and it's worth doing even if you change nothing else.

Replace it the lower-risk way

Often a bleed-out migration. Stand the new path up beside the old, run both in parallel, compare outputs, and bleed the work across a slice at a time. When a clean break is genuinely safer, we plan and rehearse a single cutover instead. Either way, the old piece only switches off once its replacement is proven.

A modern target that fits

Usually Microsoft 365 (SharePoint, Lists, Power Platform), a small web app, or a proper integration. Chosen to suit your business, not to be clever.

the discipline

We preserve behaviour, not just code.

Before we replace a component, we capture its real inputs and outputs as the regression check, because "the new code passes my test" isn't the same as "the system still works". We verify against how the old thing actually behaved, and keep a dated decision log so there's an audit trail of every change.

→ Map trusted before anything changes
→ Incremental or big-bang, to fit the risk
→ Cutover only once it's proven
→ Dated decision log per project

common questions

Modernisation, answered straight.

What counts as a legacy system?

Anything critical that's fragile, undocumented, depends on one person, or runs on software no one supports anymore. If the policy is 'don't touch it, it works,' it's legacy.

How do you replace it without breaking everything?

We map what it actually does first, then take the lower-risk path: incremental migration piece by piece, or a planned clean cutover. We don't rip and replace blind.

What about the data and history inside it?

It comes across. Preserving your existing data and history is part of the plan, not an afterthought, and we verify it against the old system before switching off.

What if only one person understands it?

That's exactly the risk we remove. We document it as we go, so the knowledge ends up in the system and the team instead of in one person's head.

start a conversation

Start with discovery.

A fixed-price discovery engagement de-risks the whole thing and scopes the rest, so you're never signing up for an open-ended rebuild. Often overlaps spreadsheet replacement and business automation.

De-risk my system →All services