Modernise The Application While People Keep Using It
We improve the code, structure and delivery process of individual applications in small steps. Each change is tested against real behaviour and can be reversed.
Applications, Not Platforms
This service is about individual applications: a web app, a mobile app, an internal tool or an API. The focus is on code, structure, tests and the way releases are made.
It is a narrower scope than system modernisation. We do not start by replacing the mainframe or the data centre. We start with the application your users open every day and make it safer to change.
If the platform under the application also needs to move, that work is planned separately so the two do not block each other.
What This Service Covers
Covered
- Web, mobile and desktop application code
- Framework and language version upgrades
- Splitting a large codebase into clearer modules
- Adding automated tests and a deployment pipeline
- Moving an application to current hosting
- API layers in front of older logic
Not covered
- Mainframe and core platform replacement
- Data centre exits and network redesign
- Replacing packaged software such as an ERP
- Organisation-wide infrastructure programmes
Platform-level work is handled under legacy system modernisation.
Four Ways Legacy Applications Fail Quietly
Most legacy applications do not crash. They become slower to change, and the cost shows up elsewhere.
Changes slow down
Simple requests take longer because every change needs manual checks across the application.
Knowledge narrows
Only one or two people dare to touch certain modules. When they are away, work on those modules stops.
Dependencies age
Libraries fall out of support. Security fixes stop arriving, and upgrades get harder the longer they wait.
Workarounds pile up
Teams build spreadsheets and manual steps around the application. The real process drifts away from the software.
Refactor vs Replatform vs Rebuild
Three options with different costs and risks. Many applications need a mix.
| Refactor | Replatform | Rebuild | |
|---|---|---|---|
| What changes | Internal code structure. Behaviour stays the same | Hosting, runtime or framework version. Most code stays | The application is written again on a new stack |
| Risk | Lower, if tests are in place first | Moderate, mostly around environment differences | Higher, as behaviour must be reproduced |
| Effort | Incremental, spread over normal sprints | A defined project per application | The largest of the three |
| Best when | The design is sound but the code is hard to change | The code works but the runtime is out of support | The design no longer fits how the business works |
We recommend an option only after reviewing the code and how the application is used.
The Method
Five steps, repeated for each part of the application.
- 1Step 1
Observe
We measure how the application is used and where it fails. We write tests that record current behaviour.
- 2Step 2
Isolate
We draw a boundary around one module so that it can change without side effects elsewhere.
- 3Step 3
Improve
We refactor, upgrade or rewrite that module behind a feature flag, in small reviewed commits.
- 4Step 4
Validate
We compare old and new behaviour with automated tests and, where possible, a parallel run on real inputs.
- 5Step 5
Transition
We move users to the new module in stages. The old path stays available until the new one is stable.
How Safety Is Built In
Feature flags
New code ships switched off. It is turned on for a small group first, and can be turned off without a new release.
Parallel runs
Old and new code process the same inputs. Differences are logged and reviewed before users see the new result.
Rollback
Each release has a tested way back. Database changes are written so that the previous version still works.
Automated tests
Tests that capture current behaviour are written before the code changes. They run on every commit.
Mobile App Modernisation Safety
Mobile apps add a constraint. Users update when they choose, so old versions stay in use.
Staged rollouts
New versions go to a small share of users first through the app store rollout controls. We watch crash reports before widening the release.
Backward-compatible APIs
The backend keeps serving older app versions while they are still in use. API changes are versioned and additive.
Remote configuration
New features sit behind server-controlled flags, so they can be switched off without waiting for a store review.
How We Use AI Assistance
AI tools help engineers read and test old code faster. They do not make decisions or ship changes on their own.
Reading unfamiliar code
Engineers use AI tools to summarise old modules and trace dependencies. An engineer checks each summary against the code itself.
Drafting tests
AI tools propose test cases that describe current behaviour. Engineers review them, correct them and decide what is kept.
Where it is not used
AI output is never merged without human review. Your code is not sent to any AI tool you have not approved, and architecture decisions are made by people.
A Transparent Engagement Structure
Four phases. You can stop after any of them and keep everything produced so far.
- 1Phase 1
Assessment
An NDA is signed, then we review the code, the release process and usage data. You receive written findings and a recommended option.
- 2Phase 2
Foundation
We add tests, monitoring and a deployment pipeline. Nothing visible to users changes in this phase.
- 3Phase 3
Incremental modernisation
Modules are improved one at a time using the five-step method. Work is tracked in your tools and committed to your repository.
- 4Phase 4
Handover
We document the new structure and work with your engineers until they are comfortable running it. You own all code and IP throughout.
Terms run month to month, with no exit fee.
Talk To An Architect
A conversation with a senior engineer about one application. No sales script.
What we will ask
- What the application does
- The stack and its versions
- How releases are made today
- What worries you most
What you receive
- An initial view on refactor, replatform or rebuild
- The main risks to check first
- A suggested next step
Related Insights
View All Articles- HiringHow to brief a remote developer so week one is productiveA short checklist covering access, context and a first task that is small enough to finish.
- Project ManagementStaff augmentation or a dedicated team: a decision you can make in ten minutesFour questions about ownership, runway and management time that settle the choice.
- ModernisationSigns your legacy platform has become a business riskWhat to look for in release frequency, incident history and hiring difficulty.
Frequently Asked Questions
It depends on whether the design still fits the business. If it does, refactoring is usually lower risk. If it does not, a staged rebuild may be the better option. We recommend one only after reviewing the code.
The method is designed so that they should not. New code ships behind feature flags and is released to small groups first, with the old path kept available.
Yes. Writing tests that capture current behaviour is the first piece of work. Code is changed only after those tests are in place.
Only tools you have approved. They help engineers read code and draft tests. Every change is reviewed by a person before it is merged.
You do. The work is committed to your repository, and all code and IP are assigned to you by contract.