Software engineering / Capability
Legacy modernisation.
Replace or rework an ageing system in stages, keeping the business running while it changes.
Tell us what you’re building
When to bring us in
Sound familiar?
- Only one person understands how our core system works.
- We’re afraid to change anything because we don’t know what it will break.
- The software is so old that hosting and security updates have become a problem.
The cost of leaving it
The one person who understands the system becomes the bottleneck for every change. Each year the hosting and security updates get harder, and the eventual replacement gets bigger.
Why us
What we bring to legacy modernisation.
We run what we ship
We build and operate SoulCare and SimRhythm ourselves, so releases, support and upgrades after launch are familiar work.
One codebase where it fits
SimRhythm runs on iOS, Android and the web from a single Expo app, which keeps three platforms on one release.
Code and accounts in your name
Repositories, cloud accounts and databases belong to you, and handover includes deployment steps and operating notes.
What the work includes
Replace it in pieces, not all at once.
Old systems often hold rules nobody wrote down. We map what the current system actually does, including the odd behaviours people depend on, before deciding what to keep. Replacement happens in stages, with old and new running side by side where needed and data migrated with checks at each step.
System assessment
A review of the code, data, hosting and the business rules buried in them.
Staged migration plan
An order of replacement that keeps daily operations running at every step.
Data migration
Mapping, cleaning and moving data with reconciliation checks before each cutover.
Parallel running and cutover
Running old and new together where needed, with a rollback plan for each stage.
Use cases
Projects we take on.
Moving off a desktop system
A Windows or Access application that runs a core process, rebuilt as a web application one module at a time.
Putting an API in front
An old system that still works stays in place, with an API added so new products can read from and write to it.
Rehosting before rewriting
Software on an unsupported server moved to a maintained cloud environment first, which buys time for a planned replacement.
What you get
Outputs you can review.
- Assessment of the current system
- Documented business rules and behaviours
- Staged migration plan
- Data migration scripts and reconciliation reports
- Cutover and rollback plans
Technologies we use for this
Where it matters
- Health & social care Carer apps have to record visits and medication on poor signal, then sync cleanly once the phone is back online.
- Property & field services Workers capture photos and checklists on site, so uploads must survive a weak connection and still attach to the right job.
- Fintech & professional services Portals and internal tools need permissions down to the record, plus a log of who viewed, changed or approved each one.
Where AI helps
Useful, on a short leash.
Explaining old code
Summarise what undocumented modules do, as a starting point for engineers who then confirm it against the running system.
Knowledge assistants ↗Checking migrated data
Compare records before and after a migration and flag the ones that look wrong for a person to inspect.
AI evaluation & testing ↗
Where it stops: Automated rewrites of a whole system are a risk, not a shortcut. Each stage is still planned, tested and released by engineers.
What’s changing
Shifts to plan for.
August 2026
Google Play targets Android 16
New apps and updates for phones and tablets must target API level 36. Extensions can be requested until 1 November 2026.
April 2026
Node.js 20 reaches end of life
The Node.js project stopped security fixes for version 20 on 30 April 2026, so services still on it need a move to 22 or 24.
April 2026
App Store requires the iOS 26 SDK
Since 28 April 2026, uploads must be built with Xcode 26. Apps can still support older iOS versions; only the build tools changed.
Process
How the work runs.
Record what it really does
We trace screens, reports and scheduled jobs, and talk to the people who use them, to capture the unwritten rules.
Pick the first piece
The first module to move has clear edges and real value, so the approach is proven early.
Reconcile every run
Each migration run produces counts and totals that are compared with the old system before anyone switches over.
Retire the old part
Once the new module has run cleanly, the old one is switched off and its data archived as agreed.
Cost
What shapes the estimate.
Undocumented behaviour
The less anyone knows about how the system works, the longer the assessment takes.
State of the data
Duplicate, missing or inconsistent records need cleaning rules before they can move.
Tolerance for downtime
A business that can pause for a weekend allows simpler cutovers than one that can’t stop at all.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Common questions
Before you get in touch.
Do we have to rewrite everything?
Rarely. Some parts can be wrapped with an API, some reworked and some replaced. The assessment shows which approach fits each part.
What happens to our existing data?
It is mapped to the new structure, cleaned where needed and migrated with checks that totals and records match before anything is switched over.
What drives the cost of modernisation?
The size of the system, how well it is documented, data quality, the number of integrations and how much downtime the business can accept.
Further reading
- MySQL 8.0 has reached end of life: planning the move to 8.4 What MySQL 8.0’s end of life means, and how to plan, test and roll back an upgrade to MySQL 8.4 LTS.
- Rebuild or refactor: modernising a legacy system safely How to decide between rewriting a legacy system and replacing it piece by piece, and how to move data safely.