What is application modernisation, and when is it needed?
Application modernisation adapts existing software to current business needs, supported technology and reliable operating conditions. Reducing the apparent age of the code is not an outcome by itself. A three-week release process, an unsupported database threatening continuity, or customers unable to complete a transaction at peak time provides a concrete reason to intervene. Record a baseline and an acceptable result for each problem. If an important outcome will not improve, retaining the application while reducing its risk can be a suitable near-term decision.
Cloud migration and application improvement are related but separate choices. AWS describes seven migration strategies, including retain, retire, rehost, replatform and refactor. Microsoft's modernisation planning guidance distinguishes replatforming, refactoring and rearchitecting. The scope of a term can vary between frameworks. Write your team's definition and do not allow a strategy label to substitute for a costed implementation and validation plan.
You do not need one strategy for an entire portfolio. You can retain an order ledger, change its hosting platform, improve pricing code and retire an unused report. Rebuilding is also an option, assessed with the cost of preserving business behaviour, moving data and retraining users. The strongest decision criterion is whether the intervention removes the measured constraint. The choice of a newer language or hosting product does not demonstrate that result.
Retain, replatform, refactor or rebuild?
Apply the following decision matrix to an application component. First establish whether its business purpose remains valid, then examine code and operating constraints. Record support life, change cost, data dependencies and the recovery path alongside the selected option. Retaining a component is a managed decision with an owner and a review date. It should not leave a dependency unexamined merely because no new implementation is planned.
| Option | Suitable situation | Main check |
|---|---|---|
| Retain | Supported system still meets the need | Owner and review date |
| Replatform | Operations are the main burden | Compatibility and capacity tests |
| Refactor | Useful behaviour, difficult code changes | Tests preserving existing behaviour |
| Rebuild or replace | Workflow no longer fits the goal | Data and feature equivalence |
| Retire | Unused function without remaining dependencies | Caller and retention checks |
Rehosting moves an application to different infrastructure without a major behavioural redesign. Replatforming changes how it operates, for example by adopting a managed database. Refactoring improves code structure while retaining behaviour. Rearchitecting changes boundaries and communication; it is not necessarily a complete rewrite. Replacing the application with an existing product may also be appropriate, but identity integration, data migration and operational fit still need assessment. Put these distinctions into the estimate and acceptance scope so every participant understands what the chosen intervention is meant to deliver.
How to prepare a modernisation plan
Start with an application inventory and a dependency map. Include databases, identity providers, file transfers, vendors, mobile clients, scheduled jobs and undocumented manual work. For each component, record the business owner, technical owner, users, runtime, version, support status, data owner and callers. Confirm statements such as “nobody uses this report” through user interviews and activity records. A month-end job may never appear during a working-day observation window, yet still depend on data that seems safe to remove.
Gather the baseline next. On the business side, describe the affected task, how often it fails and the effect of delay. For delivery, record release preparation time, change-related failures and recovery time. For operations, include peak latency, availability, support incidents and infrastructure cost. Compare equivalent observation periods rather than combining unrelated figures. Data volume, retention needs, validation rules and historical records also determine scope. Make uncertainty visible when instrumentation is incomplete instead of turning estimates into a promised performance result.
Create a decision record for each candidate: selected path, alternatives, reason, prerequisites, acceptance criteria, estimated effort and uncertainty. Include discovery, data cleaning, parallel operation, training, testing, transition support and legacy retirement in the cost. Where data or dependencies remain unknown, plan a limited measurement phase before fixing the price of an entire transformation. Avoid promising a percentage saving or delivery improvement without a trustworthy baseline. Separating observed costs from hypothetical future benefits makes the investment decision easier to review.
Choose a first phase with a small but meaningful business boundary: one report, an API or a customer workflow. Resolve its prerequisites first; an unstable system may need in-place repairs before it can be migrated safely. Define the initial scope and assess new features separately. Combining behaviour changes, data migration and infrastructure replacement in one step can make failures difficult to diagnose. The first component's measured result should influence the plan for the next component, rather than assuming the original estimate remains correct throughout the project.
Reversible delivery and data reconciliation
Describe acceptance through business examples rather than technology names: correcting an old order, checking the total after a refund, rejecting an unauthorised report request and resuming an interrupted transaction. Microsoft's Strangler Fig pattern provides incremental routing between old and new implementations behind a shared entry point. Its suitability depends on access to the old system and usable functionality boundaries. Include the cost of running both environments when selecting this transition approach.
For every phase, identify who can stop the rollout, which signal triggers recovery and how data written during the trial is handled. Returning traffic to the old path does not automatically translate records created under a new schema. Name the authoritative writer and the synchronisation path. In parallel operation, compare identical inputs, approve intentional differences and assign someone to resolve disagreements. Test the time and result of restoration as well as the existence of a backup. The ability to restore infrastructure and the ability to continue the business transaction are separate pieces of evidence.
Hypothetical example: a distributor's order portal
Suppose 120 employees use a portal processing 3,000 orders a day. Delivering a new pricing rule takes fifteen working days, while checkout p95 latency reaches 2.4 seconds when reporting load is high. Infrastructure and maintenance have a monthly budget of TRY 90,000. There is also a spreadsheet export believed to have been unused for a year. These figures are hypothetical, intended to compare interventions against the same business constraint rather than report a customer outcome.
The inventory shows that the order ledger still meets the business need, while pricing changes depend on a shared release. An initial plan retains the ledger for a defined period, refactors pricing behind a tested interface, moves reports to a separate reading path and retires the export after checking with users. A new checkout interface is deferred to a later phase. Each component gets a reason and a bounded recovery procedure instead of placing the entire portal under one rewrite decision. Historical order corrections remain in the behaviour inventory even though they are rarely used.
For a six-week pilot, assume the targets are to deliver a pricing change within five working days and keep checkout p95 below 1.5 seconds during reporting load. No unexplained differences in order or payment totals are acceptable. If a temporary second environment adds TRY 12,000 per month, record that cost explicitly rather than immediately claiming savings against the TRY 90,000 baseline. At the end, assess operating work and measured improvement together. If the target is missed, revisit the first constraint and approach before authorising a wider rebuild. The figures are local acceptance targets, not industry benchmarks.
A modernisation test and measurement plan
- Behaviour: Run representative user tasks on old and new paths. Ask the business owner to confirm expected outcomes for historical records, cancellations and edge cases, including rarely used correction workflows.
- Data: Reconcile counts, identifiers, amounts and states. Completion of a file transfer is not enough. Put unresolved differences into the cutover gate rather than postponing them as support work.
- Authorisation: Repeat the same tasks under different roles. A new platform or interface must not widen access to business data merely because authentication has moved.
- Load: Exercise normal traffic, peak reporting and scheduled jobs. Compare p95 latency and errors with the baseline from an equivalent business period, using the same definitions.
- Recovery: Practise application, configuration and data steps together. Record the responsible person, time required and post-recovery checks, including transactions already in progress.
- Business outcome: Review delivery time, support incidents and total maintenance cost after the first phase. Approve the next phase from that evidence and update assumptions where the trial disagrees with the estimate.
Common mistakes
- Choosing one full rewrite for the application solely because its code is old.
- Assuming a cloud move will improve the business workflow automatically without behavioural changes.
- Leaving undocumented rules, monthly jobs and manual corrections out of the inventory.
- Omitting testing, data cleaning, training and parallel operating costs from the estimate.
- Retaining components without review dates, or retiring functions without checking their remaining callers.
How Hatson Tech builds this
In our custom software development work, discovery begins with an application inventory, business constraints and baseline measurements. We turn component decisions into acceptance tests and a transition plan. Evaluate service extraction through the boundary exercise in when to split a monolith, and plan the selected function's move with the Strangler Fig migration plan. Sharing the user task that fails most often, its dependencies and one current measurement helps identify the first intervention to trial and gives the project a concrete basis for comparing its outcome.