Legacy modernization
Modernize the system in steps the record can prove.
A rewrite is a bet. A sequence of governed steps is a plan. We move legacy systems forward one approved, verified, logged change at a time, with the old system running until the new one has earned its place.
Start a project- run per change, each with its own gates
- 1
- sign-offs before any cut-over
- 2
- of migrations logged with their actor
- 100%
Why modernize in governed steps
-
No big-bang rewrite
Each change is a run: scoped, approved, built, verified, released. The business keeps running throughout.
-
The old system is the oracle
Automated QA compares the new path against the old one before a person reviews the cut-over.
-
Decisions are recorded
Why a module was replaced, kept or wrapped is in the design package, not in a departed engineer’s memory.
-
APIs first
An API layer in front of the legacy system lets new work start before the old work ends.
-
Rollback is a step
Release controls mean a bad step is reversed by the record, not by heroics.
-
Operated to the end
We run both systems through the transition and keep operating the new one.
When modernization is overdue
Legacy systems rarely fail suddenly. They slow you down until change becomes frightening.
- 01
Nobody wants to touch it
Changes take weeks because the risk of breaking something is unknown.
- 02
The person who knows it is leaving
Or has left. The system is now undocumented in practice.
- 03
It cannot be integrated
New tools need an API the system does not have.
- 04
Security and compliance have moved on
The platform, the libraries or the hosting no longer pass review.
- 05
A rewrite was tried and abandoned
Usually because it had no record and no gates, and the scope grew in the dark.
- 06
The business logic is the asset
And it is buried in code nobody can safely read.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
How we modernize
-
Assessment and record
Discovery produces a map of the system, its dependencies and its real users, as documents.
-
API layer
An interface in front of the legacy system so new work can start.
Read more -
Strangler migration
Module by module, each one a run with its own approval, QA and review.
-
Data migration
Moved with history, verified against the source at QA, cut over at a gate.
-
Re-platforming
Hosting, runtime and dependencies moved forward under release controls.
-
Operation
Both systems run through the transition; the new one keeps running after.
One governed run per change
- 01
Assess
We map the system with the people who operate it: modules, data, integrations, users and the changes that frighten everyone.
In the record Feature request, research report
- 02
Plan the sequence
The order of changes, what gets wrapped, replaced or retired, and how each will be verified against the old system.
In the record PRD, design package
- 03
Design approval
You approve the sequence and the first step before anything changes.
In the record Logged approval
- 04
Build the step
One module, one API, one migration at a time, under release controls.
In the record Implementation package
- 05
Verify against the old system
Automated QA compares outputs with the legacy path. A person reviews the cut-over at the second gate.
In the record QA report, review report
- 06
Release and repeat
The step goes live with rollback ready. The next step is the next run.
In the record Release candidate, release log
Ways to modernize
| Item | Big-bang rewrite | Leave it | Sydeso |
|---|---|---|---|
| Risk | All at once | Growing | One approved step at a time |
| Verification | At the end | None | Against the old system, before each gate |
| Business continuity | Freeze, then switch | Until it fails | Old system runs until the record says otherwise |
| Record of decisions | Rarely | None | Every step as documents in the audit log |
| Rollback | Hard | Not applicable | A planned step |
| Price | Unknown until it is over | Hidden | Per run, scoped at discovery |
How an engagement is structured.
-
Week one
Discovery
A week with the people who own the problem. We write the feature request, the PRD and the design package, and agree what done means.
- Ends in a PRD and a design package you own
- You approve it before anything is built
- Comes with a price for the build
-
After approval
Build
Development in short cycles against the approved scope. Automated QA writes a report on every release candidate and a person reviews it before it ships.
- Priced per project against the PRD
- Changes are new feature requests, priced the same way
- Every document is yours as it is produced
-
After launch
Operate
We deploy it, monitor it and run releases, month to month. Production is where the next feature request comes from.
- Monthly, separate from the build
- Take it in-house whenever you are ready
- The record comes with it
Questions
- Do we have to stop using the old system?
- No. It runs until the record shows each replacement passed QA and review. Many steps leave the old system in place behind a new API.
- What if the code is undocumented?
- Discovery produces the documentation: a research report and a map of modules, data and integrations. Agents help read the code; people confirm what it does with the operators.
- Can you work with the team that maintains it?
- Yes. They hold the gates and know the edge cases. The record keeps what they know.
- How do you price modernization?
- Per run, against the scope of each step approved at discovery. You see the cost of the next step before it starts.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Where does the work live?
- In your accounts. Code in your repository, infrastructure in your cloud, documents where your team can read them. We bring the process, not a dependency.
- What happens to the work if we stop?
- You keep everything: code, infrastructure, requirements, design packages, QA and review reports. There is no handover because none of it was ever ours.
Tell us what nobody wants to touch.
Describe the system and the change that frightens everyone. We reply with the first step we would take and how we would verify it.
Start a project