Build an evidence-based legacy app modernization plan

Modernize for an evidenced constraint

Start with the business and operating problem, not the age of the technology. Useful triggers can include unsupported dependencies, security exposure, fragile releases, inaccessible interfaces, costly manual reconciliation, missing observability or an integration that blocks a required workflow. Record who is affected, what evidence demonstrates the constraint and which behavior must remain stable. A legacy label alone is not a reason to rewrite. Some mature components may be understandable, secure and economical enough to retain while a narrower boundary changes.

Pause irreversible work when the team cannot identify the accountable product owner, source repository, production environment, authoritative data, critical integrations or a credible recovery path. Do not use a new cloud account or codebase to hide an unknown system. First recover access, observe real behavior and document the current state. Stop a migration slice when reconciliation fails, security controls regress, operators cannot diagnose it or rollback is no longer available. A stop rule protects service continuity and prevents sunk cost from becoming the acceptance criterion.

Inventory behavior, dependencies and ownership

Map critical user journeys, administrative tasks, scheduled jobs, reports, interfaces, data stores, file exchanges, identity, infrastructure, deployment, monitoring, support and vendor contracts. Name the owner and recovery contact for each account. Trace data from input through transformations to exports and deletion, including manual corrections that code may not reveal. Review licences, runtime support and regulatory constraints with qualified owners. Microsoft, AWS and Google Cloud all frame assessment as a prerequisite to selecting a modernization path; their platform guidance should inform questions rather than preselect a vendor.

Create a dated baseline from current evidence. Record representative transaction results, incident patterns, deployment steps, restore evidence, response times for critical journeys, accessibility findings, known vulnerabilities and operational effort where those measurements are available. State gaps as unknown instead of manufacturing metrics. Capture golden test cases and data samples that can be used without exposing sensitive information. The baseline is not a promise of improvement. It is the comparison contract used to detect regression and decide whether a modernization slice is safer and more operable than the component it changes.

Choose a path per component and sequence it

Evaluate retain, remediate, rehost, replatform, refactor, replace and retire for each bounded component. Rehosting may change infrastructure while preserving application behavior. Replatforming changes selected managed services or runtime assumptions. Refactoring changes code structure. Replacement adopts another product or rebuilds a capability. Retirement removes a verified nonessential path. Compare each option by business fit, data risk, security, portability, operating capability, provider dependence and exit. Avoid declaring microservices, containers, serverless or cloud universally modern; architecture should follow the evidence and team that will operate it.

Prefer slices that preserve a working path and make rollback observable. Introduce compatibility at a stable boundary, copy or transform data with explicit provenance, compare results and move authority only after reconciliation passes. If parallel operation is necessary, define which system is authoritative for every write and how conflicts are resolved. Keep changes to data model, interface, infrastructure and user workflow separable where practical so failures remain diagnosable. Retire the old path only after traffic, jobs, support procedures, exports, retention and recovery have been verified against the agreed scope.

Accept modernization against the baseline

Define acceptance for functional behavior, data integrity, access control, accessibility, performance, observability, deployment and recovery. Run golden cases through old and new paths, explain intentional differences and reconcile records before transferring authority. Test failure modes, rollback, backup restoration and operator intervention outside production. Apply NIST secure-development practices to both changed code and the delivery system. A successful deployment proves that an artifact reached an environment; it does not prove that the migration is complete, cheaper, more reliable or adopted by users.

Define acceptance as observable evidence. Examples include a tested user journey, an approved build, reproducible checks, an incident runbook and a verified handover. None of those proves retention, revenue or product-market fit. Keep delivery proof, external provider approval and business results as separate claims.

Transfer the modernized system and retire deliberately

Give the receiving owner an architecture map, repository and provider access, build and deployment instructions, data contracts, monitoring, runbooks, known risks, licence inventory and decision history. Require that person to deploy, diagnose and recover the new path without hidden assistance. Keep the legacy path available only for the explicit rollback or retention period defined by the project, not indefinitely by inertia. When retiring components, remove obsolete access, jobs, DNS, secrets and data according to approved retention rules, and preserve the evidence needed to explain what changed and who accepted it.

Keep source control, domains, stores, analytics, cloud organisations and production credentials under explicit organisational ownership. Grant scoped, revocable access and rehearse handover before the final invoice. The supplier label matters less than whether another authorised person can inspect, deploy, recover and continue the product.

Decision criteria

Use the same questions for every option before choosing.