Legacy application assessment: a worksheet before you modernize

A legacy application assessment should establish what the system does, what depends on it, and how safely it can change. Its output is a defensible decision about the next work package, with evidence and unresolved questions beside it. An inventory of old technologies alone is not enough to choose a rewrite.

This guide is for engineering leaders and prime contractors preparing to fund or subcontract a change to an existing application. Use it to decide whether the immediate need is discovery, stabilization, a bounded improvement, a hosting change or replacement. The worksheet and decision gates below are Rainier's proposed engineering review aids, not a certification or a mandated acquisition method.

What decision should the assessment support?

Start with the business problem and the consequence of leaving it unresolved. “Move to the cloud” describes a possible implementation. “Remove the unsupported runtime without interrupting the monthly reporting process” identifies a constraint that options can be tested against.

Write down:

The workflow that needs to improve and the people who depend on it.
The observed problem, its evidence and the date observed.
The required outcome and how it will be checked.
The constraints: outage tolerance, data handling, integration access, budget and deadline.
The person authorized to decide which behavior can change.

For example, “reduce the time operators spend correcting duplicate submissions” needs a baseline from the actual workflow. Record the current correction steps and frequency before promising an improvement. If no measurement exists, make collecting one part of discovery.

AWS's modernization readiness process starts with business priorities, stakeholder interviews and application information, then presents findings for a roadmap. Its cloud context is useful, but an assessment does not have to lead to a cloud migration.

A legacy application assessment worksheet

Use one worksheet for a proposed change boundary: a workflow, integration or deployable application. Expand the boundary when a shared dependency makes that separation unrealistic. Ask the application owner, an operator, a receiving engineer and the relevant data and security owners to supply evidence.

Area	Question to resolve	Evidence to collect
Business behavior	Which normal paths, exceptions and manual workarounds must survive?	Operator walkthrough, representative scenarios, reports and observed failure examples
Source and build	Can an authorized engineer build the deployed revision from a clean checkout?	Repository revision, runtime versions, dependency lockfile, build command and missing setup steps
Runtime support	Which components are unsupported or approaching a required upgrade?	Actual deployed versions and the vendor's support policy for each affected component
Dependencies	Who calls this application, and what does it call or share?	Interface map, observed traffic, scheduled jobs, file exchanges and direct database consumers
Data ownership	Which component is allowed to write each important record?	Schema, triggers, stored procedures, writer inventory and named data owner
Identity and access	Where are permissions enforced, including background jobs?	Role map, service authorization checks and representative permitted and denied actions
Release and recovery	Can the receiving team deploy, diagnose and recover a failed change?	Release instructions, recent deployment record, monitoring and a demonstrated recovery procedure
Constraints	Which security, accessibility, retention or hosting requirements apply to this scope?	Governing requirements, current findings, review owners and evidence required for approval
Change capacity	Who can explain the behavior and maintain the result?	Named maintainers, availability, operational training needs and handover responsibilities

The worksheet asks for artifacts because a confident answer can still be wrong. A diagram naming an integration is useful; a dated trace or job configuration helps establish whether it is active. Trace representative business cycles, including infrequent jobs, before declaring a dependency unused.

AWS's application modernization questionnaire is a broader inventory reference. It explicitly includes inbound and outbound interfaces, database consumers, batch jobs, data classification and recovery objectives. Use it when the scope needs a wider portfolio inventory; the worksheet here focuses on evidence needed for a bounded delivery decision.

Record confidence separately from severity

A severe problem and an uncertain claim are different things. An unsupported runtime may be confirmed and urgent. A report believed to be unused may have weak evidence and still be essential at quarter end.

For every finding, add a short record in this format:

Finding ID:
Workflow or component:
Observed condition and business consequence:
Evidence location, revision or environment, and date:
Confidence: demonstrated / documented / reported / unknown
Unresolved question:
Owner and next verification action:
Decision affected if the answer changes:

“Demonstrated” means the team observed the relevant behavior in the stated environment. “Documented” means an artifact describes it but the assessment has not reproduced it. “Reported” records a stakeholder's account. “Unknown” is an open question. These labels describe the assessment's evidence, not a universal reliability scale. Evidence from a test environment may still need production validation by authorized staff.

Keep critical unknowns visible. A weighted readiness score can help compare a portfolio, but an average should not hide an unresolved data writer or an untested recovery path.

How do you choose retain, rehost, refactor or replace?

Choose the option that addresses the observed problem within the constraints. The table below is an engineering decision aid. It is not a cost estimate, and more than one option can apply to different parts of the same application.

Option	A reason to consider it	Evidence needed before committing
Retain and stabilize	The workflow still fits, and a targeted support or reliability fix addresses the immediate risk	Supported operating path, maintenance owner and a dated review trigger
Retire	The function is no longer needed or is genuinely duplicated elsewhere	Business-owner agreement, downstream dependency review and an approved data disposition
Rehost	Infrastructure location is the constraint; the application's behavior can remain substantially unchanged	Platform compatibility, network and identity requirements, operational readiness and a rehearsed move
Replatform	A hosting or managed-service change can reduce a specific operational burden	Compatibility test, changed configuration, service limits and recovery responsibilities
Refactor a bounded area	A defined code or workflow problem blocks change while the surrounding application remains useful	Behavioral checks, a workable boundary and a release path for that area
Rearchitect	Coupling or component ownership prevents the required operational or scaling behavior	Domain boundaries, interface contracts, data ownership and a coexistence plan
Replace or rebuild	The current product cannot meet the required behavior economically or practically	Fit-gap review, migration and exception handling, user transition and total operating responsibilities

Microsoft's migration strategy guidance distinguishes changes to hosting, code, architecture and the product itself. It also cautions that rehosting carries existing application problems forward. Treat these categories as option names, then test them against your own evidence rather than assuming a cloud move repairs the workflow.

Compare options over an agreed planning period. Include discovery, implementation, data reconciliation, temporary coexistence, infrastructure, licenses, support and training. Identify which costs are known, estimated or excluded. Two quotes are not comparable if one assumes the old system disappears immediately and the other funds a year of parallel operation.

Three decision gates before pricing implementation

These gates turn the findings into a next action. They are proposed project controls, not legal acceptance terms or substitutes for your organization's approvals.

1. Is the behavior clear enough to preserve?

Identify the workflows and exceptions affected by the proposed increment. Agree representative scenarios with the business owner, including denied actions and failures at integration boundaries. If essential behavior exists only in one person's memory, commission discovery before treating a replacement price as firm.

2. Is there a controlled boundary for the change?

Locate the code, callers, records and release steps involved. Name the authoritative writer for each changed record. If both systems will run together, specify which one handles each operation and how downstream readers receive consistent data.

AWS's strangler fig pattern describes replacing functionality incrementally through routing between the existing and new systems. It also identifies routing-layer failure and data consistency as concerns. Incremental replacement is an option when the boundary is workable; it adds coexistence responsibilities rather than making migration risk disappear.

3. Can the team verify and recover the increment?

Require a representative test environment, controlled data, observable acceptance scenarios and a recovery approach. A routing switch can restore the old interface, but it cannot necessarily undo new writes. For a schema or data change, specify how records are reconciled, who authorizes recovery and which operations must pause.

An unresolved gate should change the scope: fund the evidence needed to resolve it, choose a smaller boundary or defer the affected change. Record the decision and owner. Do not turn “unknown” into an optimistic assumption buried in a fixed-price proposal.

Worked example: modernizing a request dashboard

The following is hypothetical. It is not a Rainier client assessment, estimate or outcome.

Assume an organization has a request dashboard backed by a shared SQL database. Operators create and update requests; a nightly import also writes them. A reporting tool reads the database directly. The immediate problem is duplicate requests during import retries, and management has proposed replacing the entire dashboard.

Finding	Evidence status	Effect on the decision
Duplicate records follow a repeated import batch	Demonstrated with a controlled fixture	Investigate retry behavior and record identity before changing the interface
Operators use an undocumented correction action	Reported in a walkthrough	Document the correction's rules and permission boundary before replacing it
Reporting reads tables directly	Documented in connection configuration	Changing the schema requires coordination with the reporting owner
Recovery instructions are out of date	Demonstrated when a test restore could not be completed	Resolve recovery before a destructive migration

The first work package could establish repeatable import fixtures, document the correction workflow, define the record identity rule with the data owner and rehearse recovery in a representative environment. A subsequent increment could address retry handling with agreed checks for duplicate prevention and existing reporting compatibility. That sequence is an assessment recommendation under the stated assumptions, not a claim that the defect has been diagnosed or fixed.

The whole-dashboard replacement remains an option. The available evidence simply does not yet show that it is necessary to solve the reported problem. If discovery reveals that the data model cannot represent required request states, the next package changes accordingly.

What actual delivery evidence can establish

Rainier's published Ever engagement describes extending reservation and sell-your-car flows within an existing product, with a typed PostgreSQL data layer. That is evidence of work inside an existing application. It does not establish that Ever used this worksheet, had the hypothetical import defect, or achieved a quantified modernization saving.

When evaluating a delivery partner, ask for similarly specific scope evidence: what changed, what remained, what dependencies the team owned and what another engineer can inspect. Our software subcontractor evaluation scorecard helps organize that conversation.

What should you request from an assessment engagement?

Ask for a decision package that your team can use even if a different supplier implements the change:

A defined assessment boundary and the business decision it supports.
The completed worksheet, evidence references and explicit limitations.
A dependency and data-writer map with named owners.
Options compared against the same outcomes and constraints.
A recommended first increment, unresolved gates and verification tasks.
Assumptions behind any estimate, including access and external-team dependencies.
Acceptance and handover requirements for the next scope.

Specify access arrangements before the engagement starts. Discovery should use authorized environments and appropriately controlled data. Record what could not be inspected; missing source access or unavailable operators limits the conclusions an assessment can support.

Once the decision is made, use the software acceptance checklist to define evidence for the delivered increment. That checklist answers whether agreed work is acceptable; this assessment answers which work should be agreed in the first place.

Rainier's software subcontracting scopes include bounded modernization work packages. Bring the affected workflow, current stack, known dependencies and decision deadline to a scoping conversation. A list of critical unknowns is a useful starting point when the replacement plan is not ready yet.

Discuss a modernization work package