Practical delivery guide
How to Modernise a Legacy Business Application
Modernise a legacy application by changing one useful workflow at a time, while proving that essential behaviour and data remain correct. Agree the cutover, recovery and ownership evidence before moving users.
Record what the application actually does
Start with a real transaction, not a technology wish list. Follow it from capture through decisions, system updates, reports and corrections. Ask experienced staff where the documented process differs from daily work. Record scheduled jobs, exports, shared accounts and manual workarounds that may not appear in the interface.
This guide covers executing a change to an existing application. If the decision is still whether to extend or replace it, first use the modernisation strategy guide. A new framework is not by itself a business outcome.
Choose a measurable result, such as a request completing without duplicate capture, and identify the existing behaviour that must remain. Record known defects separately so a test does not accidentally turn an old mistake into a permanent requirement.
Build evidence before changing behaviour
Create representative, sanitised examples for successful transactions, rejected actions, exceptional values and recovery. Capture expected outputs with a business owner. These baseline tests describe observable behaviour; they are especially useful when the original intent is poorly documented.
- Check calculations, record relationships and permissions, not only screen appearance.
- Include interrupted work, duplicate submissions and delayed integrations.
- Identify reports or downstream consumers that depend on the current format.
- Separate an intentional rule change from a regression and have the owner approve it.
AI tools can assist with understanding code and proposing tests. Review their interpretation against working examples. Generated tests that simply repeat generated implementation are not independent evidence of correctness.
Choose a reversible delivery slice
Pick a workflow with a clear entry, accountable owner and observable completion. Define which component reads and writes each record during coexistence. Avoid two applications independently updating the same business state without an explicit conflict policy.
The AWS strangler fig pattern describes progressive replacement through controlled routing. It is one option, not a requirement to adopt microservices. A contained change within the existing application may be simpler.
Document what stays unchanged, how users reach the changed function and how failures are routed to support. Use the legacy integration guide for interface boundaries rather than treating direct database access as automatically safe.
Rehearse the data move and cutover
Run the proposed migration in a controlled environment using an appropriately protected dataset. Check record counts, relationships, key totals and representative business cases. A completed import command does not prove the data is usable.
Agree how changes made during the migration window will be captured. The cutover plan should name the person who can pause the release, the checks they will inspect and the expected user communication. Define acceptable downtime and recovery requirements with the operator instead of promising a generic duration.
Hypothetical example: a request queue moves to a revised application. The team reconciles open requests, preserves their identifiers and verifies attachments before inviting one authorised user group. Requests arriving during the move are recorded and reconciled before normal processing resumes.
Make rollback a data decision, not only a code switch
Restoring the previous code may be insufficient once the new application has accepted writes or changed a schema. Define whether recovery means restoring a backup, replaying approved transactions, applying a corrective migration or continuing forward with a fix. Rehearse the chosen path and protect work submitted after cutover.
Monitor failed transactions, queue age and reconciliation differences alongside uptime. Give staff a clear route to report incorrect outcomes. Expand the release only when the agreed evidence is available.
Retire the old path deliberately
Remove obsolete jobs, access and integrations only after their dependencies are resolved. Confirm which records must remain accessible, who owns retention decisions and how historical reports can be reproduced. Keep a support runbook and an accountable application owner.
Estimate implementation with the team after reviewing the baseline, migration and recovery work. The business-system modernisation page explains the service context; ongoing product engineering explains how continued roadmap work can be owned within agreed capacity; and the project scoping guide helps turn the selected change into an agreed delivery boundary.
Sources and review date
Sources reviewed on 8 September 2026 are linked beside the guidance they support. Workflow designs and measures are planning recommendations, not measured client results. Examples are hypothetical. Confirm scope, integration access and any specialist-review requirements with the responsible team before implementation.
Questions
Frequently asked questions
Do we need to rewrite the entire application?
Not necessarily. Choose a contained change if it produces the required outcome and can be operated safely. Assess the existing constraints before deciding.
Can we roll back by restoring the old code?
Only if the data and interfaces remain compatible. Define recovery for transactions accepted after the change and rehearse it before cutover.
Plan your next step
Bring the workflow you want to improve.
Discuss the current process, systems and first useful release with LCR Technologies.