Replace the system you are not allowed to switch off.
Map what it does today, including the parts nobody documented. Separate what is worth keeping from what has to be rebuilt. Migrate in stages, each one reversible.
- 01What it does now
- 02What is worth keeping
- 03Stage by stage
- 04A way back
In productionA service retail group whose counter and back office were reconciled by hand, moved onto Guru POS on the same codebase as their ERP.
Why the old system is still running
The spreadsheet, the manual step and the software nobody wants to touch are still running the business. That is exactly what makes replacing them hard.
Nobody knows everything it does
The documentation describes the 2019 version and the behaviour that matters was added by somebody who left.
It cannot be taken down
There is no maintenance window, so every approach that starts with "we switch over on a weekend" is already out.
The rewrite was tried once
It reached 80% and stopped, because the last 20% is the undocumented behaviour and nobody scoped it.
Two systems in parallel forever
The new one launched, the old one never turned off, and now both are maintained.
The rules we work to
These exist because the failure modes above are predictable.
Every stage reverses
A migration step that only works forwards is a bet on a system nobody fully understands yet.
The undocumented behaviour is the scope
It is the part that fails a rewrite at 80%. It is found first, not last.
The business keeps running
No cutover weekend, no freeze on operational change while a project completes.
One set of numbers during the overlap
While both systems run, they have to agree, and something has to check that they do.
Decommission is in the plan
Turning the old system off is a deliverable with a date, not an aspiration for after go-live.
Ownership from day one
Source, infrastructure definitions and documentation are yours throughout, not at the end.
What modernisation actually involves
Six pieces of work. The first one is the one most projects skip.
Behavioural discovery
What the system does today, observed rather than asked about, including the exceptions handled by hand.
Keep or rebuild
An explicit decision per capability, written down with the reason, so nobody relitigates it in month four.
Staged migration
Slice by slice, with the old and new systems agreeing at every boundary during the overlap.
Integration
Keeping the systems that will outlive this project talking to the one replacing part of it.
Process automation
Removing the manual step the old system forced, rather than reimplementing it faithfully.
Decommission
The plan for turning the old system off, agreed at the start. Without one, both systems are maintained forever.
What we build it on.
Grouped by what it does rather than shown as a wall of marks, and short enough that your own team can judge whether they could take it over.
- Backend
- PythonDjangoFastAPINode.js
- Data
- PostgreSQLMySQLRedisData modelling
- Cloud
- AWSDockerCI/CDInfrastructure as code
- Frontend
- ReactTypeScriptNext.jsDesign systems
Work we have done under this line.
Derived from the engagement record rather than listed here, so this section cannot claim work that is not in it.
RetailBangladesh
A service retail group
Guru POS on the same codebase as Guru ERP, so the till opens from the ERP dashboard rather than a second sign-in.
Questions we get asked.
The objections specific to this line, answered here rather than in a first call.
Can you modernise a system we are not allowed to switch off?
That is the usual case. We map what the system does today, including the parts nobody documented, then separate what is worth keeping from what has to be rebuilt. The migration runs in stages and every stage can be rolled back.
What if the original developers are gone?
Common, and it changes the discovery method rather than the plan. Behaviour is observed from the running system and its data rather than reconstructed from people’s memories, which is more reliable anyway.
How do you avoid the rewrite that never finishes?
By not doing one. Work is sliced so that each stage delivers something in production and can be reversed, which means the project has value at every point rather than only at the end. The 80% rewrite fails because it has no value until it is finished.
Where to go next
You do not need to arrive with a perfect technical specification.
Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.
Start your build