Legacy modernization
Modernise the system in steps the record can prove.
A rewrite is a bet. A sequence of governed runs 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
- human gates before any cut-over
- 2
- of migrations logged with their actor
- 100%
Why modernise 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 transition
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 modernisation 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 modernise
-
Assessment and record
Discovery produces a map of the system, its dependencies and its real users, as artifacts.
-
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 design_approval transition
- 04
Build the step
One module, one API, one migration at a time, as jobs on runners 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 as a transition. The next step is the next run.
In the record release_candidate, released
Ways to modernise
| 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 artifacts in the audit log |
| Rollback | Hard | Not applicable | A transition |
| Price | Unknown until it is over | Hidden | Per run, scoped at discovery |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
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 as artifacts: 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 modernisation?
- 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.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
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