Modernization and Migration

Modernization is a change to an existing system and the practices around it so that they better meet current business, technical, and operational needs: supportability, fewer recurring failures, a required integration, or easier operation. Migration is the act of moving something from one place to another. The two overlap often, but neither implies the other.

The extent of application change and the rollout sequence are separate decisions. Lift and shift preserves the application design while changing its hosting environment. Replatforming makes selected platform changes, while refactoring or re-architecting changes the application more substantially. Any of these may be organized into waves; phased modernization describes a sequence, not the opposite of rehosting. Limiting simultaneous changes can make diagnosis easier, but environment, configuration, and input timing still affect results. Even a redesign can preserve approved behavior. Define the comparison point, expected meaning, and approved differences rather than assuming that rehosting makes verification trivial or that redesign prevents equality checks.

Choose the strategy and sequence against the unmet need, dependencies, supportability, risk, cost, and deadline. AWS’s large-migration guidance generally favors rehosting, relocating, or replatforming before further modernization, while allowing refactoring when other strategies are not acceptable. This is a conditional planning choice, not a rule based on estate size alone. If the old design causes the problem, an unchanged move may still be a useful first stage, but it does not by itself resolve that design problem. Approved later work needs ownership and resources; a system that meets its needs may require no redesign.

Migration has more than one scope

A data migration moves records and must preserve approved meaning: identifiers, types, precision, time rules, and relationships. Check those properties through reconciliation against the source at an agreed cutoff, accounting for approved transformations. The absence of copy errors is insufficient. Permissions and retention obligations also need their own access and policy tests; data equality does not prove compliance. A workload migration moves where a process runs. A system migration moves users, integrations, and operating responsibility to a different system. Each has its own risks, and a project can involve one without the others. Each also has a moment when responsibility actually transfers — the cutover — and usually a period before it when both systems run, which is coexistence. Naming the two separately is what keeps a schedule slip from turning into an unplanned switch.

In a fictional purchasing service, an unsupported morning reporting job fails often while the order database it reads works reliably. Replacing the reporting path is modernization with a small migration of the report’s logic and users; the database is retained. If the failures arise from unchanged job logic, moving it to a new server leaves that cause in place; a hosting-related failure could instead improve. Diagnose the cause before predicting the effect of the move.

Not every modernization is a cloud move or a rewrite

GOV.UK’s guidance on legacy technology lists options such as retaining, retiring, re-hosting, repurchasing, and re-platforming. Improving maintenance of a working system, retiring an unused capability, and redesigning a workflow are also modernization. The choice depends on which need is unmet and which dependencies the change must respect, not on how new the result looks. Retiring rather than moving deserves its own consideration, with the obligations that outlive the system — records to keep, access to preserve — treated as part of the work: see system retirement. And the comparison between options is a total cost of ownership question, in which the operating burden of the old system is a cost that continues if nothing is done.

Judge a modernization by measured outcomes after the change, such as fewer failed mornings and recovery by more than one operator, not by deployment alone. Judge a migration against approved requirements at an agreed comparison point: preserve the intended meaning and behavior, and document deliberately approved differences rather than reproducing old defects. Decide in advance what happens if the comparison fails after the switch — repairing forward on the new system, as in forward recovery, and returning to the old one are different plans, and the difference is hard to work out during the incident.

References:

• GOV.UK, Managing legacy technology.
• AWS Prescriptive Guidance, About the migration strategies.