[ 03 — MODERNISATION ]
Replace the spreadsheet, the ageing system or the manual process without stopping work.
[ 01 — THE PROBLEM ]
What this usually looks like
Before
- The system everyone complains about is also the system everything depends on.
- The original developer is gone and nobody is sure what parts of it still do anything.
- It runs on a version of something that stopped getting security updates years ago.
- Every previous attempt to replace it stalled because the business could not stop for a cutover.
After
- A staged migration: old and new run side by side and one process moves at a time.
- We map what the system actually does today before changing it, including the parts nobody can explain.
- The replacement runs on supported, patched software with the upgrade path written down.
- Every stage has a way back. Nothing is switched off until its replacement has been doing the job for a while.
[ 02 — WHAT YOU GET ]
Deliverables, not deliverable-sounding words
A system audit
What exists, what it does, what depends on it, and what is genuinely dead. Usually the first honest map anyone has had.
A migration plan
The order processes move in, what runs in parallel, how long each stage takes and how to reverse it.
Data migration
Extracted, cleaned, deduplicated and reconciled, with a report showing what changed and what could not be matched.
The replacement system
Built in stages, each one live and in use before the next begins.
Decommissioning
The old system archived read-only rather than deleted, so a question about 2019 still has an answer.
[ 03 — HOW IT WORKS ]
The steps, and how long each one takes
- 01
Audit
1–2 weeksRead the code, the database and the spreadsheets, and talk to the people who use them. Produce the map.
- 02
Plan the stages
3–5 daysPick the first process to move: valuable enough to matter, small enough to be safe.
- 03
Run in parallel
2–4 weeks per stageNew system live alongside the old for the first process. Both get the data; the outputs are compared.
- 04
Move the rest
2–6 monthsOne process at a time, each with its own go-live and its own way back.
- 05
Retire the old system
1 weekOnly once nothing depends on it. Archived, documented, and the licence finally cancelled.
[ 04 — EXAMPLES ]
What people use this for
Spreadsheets to a real database
Years of files with conflicting copies, consolidated into one source of truth with the reports people actually used.
Desktop system to web
Moving an installed application off one office PC so the team can work from anywhere, with real backups.
Unsupported platform rescue
Getting off a framework or runtime that no longer receives security patches, without rewriting everything at once.
The system everybody complains about is usually also the system everybody depends on, which is why it never gets replaced.
Stages, not a cutover
We run the old and the new side by side, move one process at a time, and keep a way back at every step. The first process is chosen to be valuable enough to prove the point and small enough to be safe. Nothing is switched off until its replacement has quietly been doing the job for weeks.
The audit comes first
Before anything changes we map what the system actually does, which is rarely what the documentation says and often more than anyone still remembers. That map is useful even if you decide to do nothing else.
[ 05 — STACK ]
What we build it with
Chosen because they are boring, well supported and easy to hire for. Nothing here will be abandoned next year.
- Python
- PostgreSQL
- Next.js
- TypeScript
- Docker
- DuckDB
[ 08 — FAQ ]
Modernisation: questions people ask
Let's talk about modernisation.
Tell us the problem. We will tell you what we would build, what it costs and how long it takes — before you commit to anything.