Assessment & recovery
Recover the source, build, restore process and operating knowledge. Then map the value, exposure, data and dependencies around the live system.
Modernise legacy software
without rewriting it all.
We assess the software your business depends on, recover technical control and change it in manageable stages. Keep the behaviour that still matters. Replace the constraints that hold the operation back.
Capabilities
01 — 04What we build.
01
02
APIs & interface modernisation
Put controlled interfaces around behaviour worth keeping. Replace brittle file, database or point-to-point links one dependency at a time.
03
Cloud & platform modernisation
Rehost or replatform when infrastructure, support, recovery or delivery is the constraint. Design cost, security and operation into the move.
04
Phased replacement & migration
Record the behaviour that matters and prove the hardest connection. Move data and capabilities in reversible stages, then retire the old responsibility.
AssessStabiliseWrapMigrateRefactorReplaceControlled change
How we do it
Modernisation backed by evidence.
A/01
Recover before prescribing
We start with the real users, rules, records, dependencies and recovery path. The target architecture comes later.
A/02
Prove one difficult seam
Representative data and a lifelike production slice test the assumption that could invalidate the wider migration plan.
A/03
Retire responsibility explicitly
Completion means removing the old jobs, contracts, access paths and unsupported infrastructure that still carry operational risk.
Legacy modernisation readiness scorecard.
Score one business-critical system. This checks whether you have enough operating and technical evidence to begin a controlled change. Our strategy guide has a separate scorecard for business risk.
Score one system from 0 to 3
Every slider starts at 1 for an unproven assumption. Score only the evidence you can demonstrate today. Familiarity with the system and supplier confidence do not count.
Modernisation readiness
Recover the evidence and operating control first
A migration plan still depends on assumptions about recovery, behaviour or ownership. Prove the restore and release paths, record the knowledge held by people and map the live dependencies around one critical journey.
Send the result and your optional context to ORBN for a personal response.
This is directional scoping support, not a security, resilience or migration assessment. A single critical recovery, regulatory or data constraint can outweigh the total.
Where legacy modernisation starts.
Old software is not automatically bad. It becomes a business problem when nobody can recover, change, connect or support it at the pace the operation needs. ORBN can take the work from assessment through production transition. We do not assume the answer is a rewrite or a cloud migration.
M/01
Legacy application assessment
Observe the live operation and recover the technical estate. Map the business value, exposure, data, dependencies and support needs before choosing a target platform.
M/02
Stabilisation and software rescue
Secure the source, builds, access, monitoring and backups. Prove the restore process so the team can understand and change the system with more control.
M/03
API and interface modernisation
Put controlled interfaces around valuable existing behaviour, replace fragile file or database coupling and let new workflows arrive without a big-bang rewrite.
M/04
Cloud and platform modernisation
Rehost or replatform when it removes a real support, resilience or delivery constraint. Plan infrastructure, recovery, cost and security as part of the move.
M/05
Incremental refactoring or replacement
Record the behaviour worth keeping and prove the hardest connection. Move one useful capability at a time behind a stable boundary.
M/06
Data migration and decommissioning
Map, validate and reconcile records before cutover. Remove the old jobs, contracts, credentials and support duties once the new service owns their work.
Choose a route for each capability.
One system may need more than one route. A finance package can replace commodity administration while a proven pricing engine stays behind an API and the workflow around both changes. AWS defines seven common cloud migration routes. A commercial modernisation plan must also cover stabilisation, interfaces and the final removal of operating responsibility. Compare the wider portfolio choices in our UK legacy system modernisation guide.
Scroll horizontally to compare the delivery routes →
| Route | What changes | Useful when | Failure to avoid |
|---|---|---|---|
| Stabilise | The immediate operating controls, source, recovery and observability | The system must keep running but cannot yet be changed safely | Treating containment as the permanent destination |
| Wrap and integrate | Interfaces around useful existing behaviour or records | The core is stable but access, workflow or coupling blocks change | Adding another undocumented dependency with no retirement path |
| Rehost or replatform | Infrastructure or managed platform services, with limited application change | Hosting, support or recovery is the dominant constraint | Moving the same operational failure modes to a newer bill |
| Refactor | Code structure, tests and delivery while behaviour is retained | The capability fits the business but change is slow or unsafe | Refactoring a whole monolith before releasing user value |
| Replace or rebuild | One capability, product or workflow and its operating model | Business fit is poor or a supported product solves the need better | Recreating every historic feature without challenging the process |
| Retire | Users, records, integrations, contracts and responsibility leave the system | The capability is duplicated, unused or no longer justified | Switching off the screen while hidden jobs and data consumers remain |
Cloud migration and application modernisation are related but not identical. NHS England guidance distinguishes moving a workload into the cloud from changing the application to use cloud-native capabilities. ORBN stays platform agnostic until the need and evidence support a choice.
A controlled delivery sequence
WAVE / 01A controlled path into production.
We release in stages and require evidence before each move. The UK Government Service Manual recommends understanding the constraints, testing realistic prototypes, designing interfaces carefully and using wrappers to control the pace of migration. The sequence below puts those ideas into production work.
01
Observe the operation
Name the business outcome and boundary, then watch real users, support paths, scheduled jobs, reports, workarounds and peak operating periods. Source code is only one part of that operating context.
02
Recover technical control
Secure source, build instructions, environments, credentials, logs, backups and a proved restore. Urgent containment can proceed before a larger modernisation route is selected.
03
Characterise behaviour and data
Turn valuable rules, representative journeys, interfaces, totals and exceptions into executable checks or explicit acceptance evidence. Map which system owns each record during transition.
04
Prove the hardest seam
Use lifelike data and load to test the uncertain migration, API, platform, performance or business-rule assumption. Agree what result would show that the proposed strategy is wrong.
05
Release one vertical slice
Deliver one useful capability through the new path, with monitoring and support. Put it in front of a real user so the team can test the whole route instead of an isolated technical layer.
06
Run, reconcile, cut over and recover
Compare old and new behaviour where appropriate, rehearse migration and rollback, define tolerances and give a named owner authority to proceed or stop each changeover.
07
Decommission responsibility
Remove obsolete integrations, accounts, infrastructure, licences, jobs and support duties. Transfer source, runbooks, monitoring and roadmap ownership for the service that remains.
Read the official guidance on moving away from legacy systems and the AWS reference for migration strategies.
Safe operation needs evidence.
Newer technology is not enough. Modernisation should leave the team with stronger control of the service. These checks form part of the acceptance evidence for each migration stage and the support model after launch.
C/01
Source, build and release
Known repositories, dependency ownership, repeatable environments, controlled secrets, release records and a route to reproduce the running version.
C/02
Behaviour and acceptance
Representative journeys, business-rule examples, interface contracts and agreed tolerances that detect an accidental change to valuable behaviour.
C/03
Data integrity and reconciliation
Authoritative ownership, mappings, totals, exception handling and retained evidence that show records arrived complete and mean the same thing.
C/04
Dependencies, access and security
Named consumers and suppliers, least-privilege access, supported components, vulnerability response and visibility of temporary migration paths.
C/05
Observability, recovery and rollback
Service-level signals, actionable alerts, traceable failures, tested restore, recovery objectives and a rehearsed route back when a release or cutover fails.
C/06
Ownership and retirement
Product, technical, security and support owners; runbooks and escalation; agreed exit criteria; and evidence that the old responsibility has actually gone.
Unsupported products do not have a risk-free operating state. The National Cyber Security Centre advises migration away from obsolete products and, when that cannot happen immediately, compensating controls and closer response to security events while the transition is completed. Read the NCSC obsolete-products guidance.
What a legacy modernisation proposal should show.
A target architecture is only one part of the decision. The proposal should show how the operation changes, which assumptions remain and who owns each responsibility. Commercial and technical reviewers then have something concrete to challenge.
01
Outcome and baseline
The business constraint, present cost or exposure, affected users and measurable evidence that the change improved the operation.
02
System boundary
The capabilities, journeys, data, dependencies, contracts and teams inside the proposal. It should also state what remains outside.
03
Strategy by capability
Which parts are retained, stabilised, wrapped, rehosted, refactored, bought, rebuilt or retired, with reasons and rejected alternatives.
04
Evidence and uncertainty
Show the source access, behaviour checks, data profile and dependency map. State the volume and availability assumptions, then identify the test for the hardest unknown.
05
Transition and recovery
Migration waves, parallel-running or synchronisation needs, reconciliation, cutover authority, rollback, support cover and decommission criteria.
06
Whole-life ownership
Delivery and operating cost, source and platform ownership, support model, documentation, skills transfer and responsibility after the project team leaves.
Cost and timeline
SCOPE / 01What a modernisation estimate must include.
Two applications with similar amounts of code can carry very different risk. Hidden integrations, disputed records, unsupported runtimes, availability windows and supplier access often shape the work more than the feature list. A useful estimate separates three decisions.
01
Assess and contain
Recover enough operating control and evidence to identify viable routes, urgent exposure, the hardest unknown and a bounded first change.
02
Prove and transition
Test the uncertain seam, deliver production slices and include data, interfaces, adoption, parallel operation, recovery and cutover. The estimate must cover more than development effort.
03
Operate and retire
Include monitoring, support, cloud or licence costs, security response and continuing change. Offset them only with infrastructure, contracts and manual work that can genuinely end.
For a bounded replacement or rebuild, use our UK custom software cost guide and calculator to challenge team and duration assumptions. If a packaged product may replace the capability, compare whole-life fit with the custom vs off-the-shelf scorecard.
Legacy payment modernisation case study
CASE / 01Replace one costly capability without rebuilding the rest.
A national publisher depended on a 12-year-old in-house subscription and payment platform costing £100,000 a year in support, maintenance and hosting. Salesforce already held the useful customer context, so ORBN replaced the payment capability with Stripe and integrated the service workflow into the existing CRM rather than rebuilding an entire subscription estate.
8,000+
Active direct debits migrated
Historic product records were mapped into a simpler model and reconciled through a controlled six-month transition.
15
Service agents trained
In-person and self-paced training made operational adoption part of the release, alongside the new Salesforce payment workflow.
£72k
Reported annual saving
The figure accounts for continuing Stripe and transaction fees against the former platform's annual operating cost.
Legacy software modernisation FAQ.
Q/01
What is legacy software modernisation?
Legacy software modernisation improves or replaces a system that still matters to the business but has become difficult, costly or risky to run and change. The work may recover source and deployment control, stabilise unsupported components, add APIs, move infrastructure, refactor code or replace selected capabilities. It does not automatically mean rewriting the whole application.
Q/02
Can you modernise a legacy system without a full rewrite?
Yes. A stable capability can remain behind a controlled interface while its user experience, integrations or surrounding workflow changes. Other systems suit replatforming, selective refactoring or gradual replacement. The right boundary depends on business fit, recovery, dependencies, data ownership and how well the existing behaviour can be checked. ORBN tests the strategy against the real system before committing to a wider change.
Q/03
Is application modernisation the same as cloud migration?
No. Cloud migration changes where or how a workload is hosted. Modernisation changes how well it meets current operating, security, integration and delivery needs. Rehosting may remove an infrastructure problem without changing the application. Modernisation can also stabilise an on-premise system, add an API or replace one capability with a supported product.
Q/04
How do you choose between wrapping, refactoring and replacing?
Choose per capability instead of forcing one answer across the whole estate. Wrap behaviour that still works but is hard to access. Refactor code that fits the operation but is costly to change. Replace a commodity capability, or a system whose process, data model or platform no longer serves the business. Include operating, migration and retirement costs in the decision.
Q/05
How much does legacy software modernisation cost in the UK?
Cost depends on the evidence available, system boundary, source and deployment access, dependencies, data quality, security exposure and transition plan. A useful proposal separates assessment and containment, the hardest technical proof, production migration stages and continuing operation. Recovering an unsupported application and replacing a business-critical platform have very different scope and risk, so ORBN does not quote one generic price.
Q/06
How long does a legacy modernisation project take?
A focused assessment and technical proof can establish a useful direction in weeks when the source, users and representative data are available. Production takes longer when behaviour is undocumented, integrations are hidden, data must be reconciled or several teams and suppliers need to coordinate. The first engagement should expose those conditions and define the sequence.
Q/07
Can legacy software be modernised without downtime?
Many changes can use wrappers, parallel running, synchronisation and staged cutover to reduce planned interruption. Nobody should promise zero downtime before understanding the architecture, consistency needs and failure modes. Each migration stage needs an agreed window, recovery point, rollback route, reconciliation checks and a named decision owner.
Q/08
Who owns and supports the modernised software?
ORBN builds for client ownership and makes the source, environments, documentation and operating responsibilities explicit. Support can sit with your internal team, ORBN or both. Before launch, the service needs named owners, monitoring and recovery procedures, supplier access and a plan to remove old jobs, infrastructure, contracts and credentials.
Start with one systemA controlled route
A controlled route
out of legacy risk.
Show us the system your team is afraid to touch, the deadline or risk forcing the decision and the people who know how it really behaves.