Legacy modernization, for a system you cannot switch off.
Replaced one capability at a time, with the old one still running.
The system everybody complains about is usually also the system the business depends on, which is why it survives every plan to replace it. We do it the way that works: understand what it actually does, put a seam in front of it, move one capability at a time, and keep both running until the new side has proved itself on real work. No weekend where everything changes at once.
How systems get replaced
The approach depends on what is wrong: the technology, the hosting, the data, or the fact that nobody left understands it.
Strangler rewrite, one capability at a time
A routing layer in front of the old system sends each request to whichever side owns that capability now. Functionality moves across piece by piece, and the old system shrinks until there is nothing left in it.
- A routing seam in front of the old system
- One capability moved per release
- Both sides live at the same time
- The old system shrinking, measurably
Replatforming without changing behaviour
Where the software is fine and the platform underneath it is the problem: an unsupported runtime, hardware nobody sells, a database version past end of life. Behaviour is deliberately held constant so that any difference after the move is a defect rather than a debate.
- Runtime and framework upgrades
- Move to supported infrastructure
- Behaviour held constant on purpose
- Automated comparison before and after
Desktop or on-premise system moved to the web
Software that runs on a machine in one building, needed by people who are not in that building. The workflow is preserved rather than reimagined, because the users are already fluent and retraining them is a hidden cost nobody budgets.
- The existing workflow preserved
- Browser access with real permissions
- Local files and printing handled
- Phased rollout by team or site
Database and data migration
Moving the data, which is usually where a modernization actually succeeds or fails. Decades of accumulated exceptions live in there, and finding them before cutover rather than after is the whole job.
- Profiling before mapping
- Cleansing rules agreed with the business
- Reconciliation counts and totals
- Rehearsed migrations, not a first attempt
A spreadsheet estate that became the system of record
No vendor, no server, and no way to see who changed what. Replaced with something that has a database, permissions, and history, while keeping the flexibility that made the spreadsheets win in the first place.
- The real process mapped from the files
- History and permissions introduced
- Existing data imported, not retyped
- Export kept, because people still need it
Rewriting a system nobody left understands
The original team has gone and the documentation is a folder of screenshots. Behaviour is recovered from the code, the database, and the people who use it daily, and written down before anything is rebuilt.
- Behaviour recovered from code and data
- Rules confirmed with daily users
- Written specification produced first
- Dead functionality identified and dropped
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
How a replacement is kept safe
Every build ships end to end, from first scope to live deployment and ongoing support.
