// 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.
// 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.
-
Step 1
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.
-
Step 2
Replace it the lower-risk way
Often that's 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 legacy piece only switches off once its replacement is proven.
-
Step 3
A modern target that fits
Usually Microsoft 365 (SharePoint, Lists, Power Platform), a small web app on our stack, 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
// 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. It often overlaps spreadsheet replacement and business automation.