# Legacy modernization planning workbook

Updated: 28 September 2026

Use this editable Markdown workbook to decide what to investigate or change in an existing application. Complete the blank sections using your own evidence. The filled cost example is fictional and is not a quotation, market benchmark or reported customer result.

## 1. Decision to make

- Application and business owner: [name / role]
- Workflow and people affected: [one concrete workflow]
- Current constraint: [observed problem, frequency and evidence]
- Required outcome: [measurable behavior, without assuming a replacement]
- Options to investigate: [retain / targeted improvement / incremental replacement / buy or build a successor / retire]
- Review horizon: [same number of months for every option]
- Decision owner, review date and next evidence needed: [record]

Separate an observed failure from a proposed explanation. Age alone does not establish what must change. If the system meets its requirements, record what continued ownership, maintenance and support would require.

## 2. Inventory and unknowns

| Component or business step | Purpose and owner | Version / support source | Reads, writes and dependencies | Evidence and date | Unknown / next check |
| --- | --- | --- | --- | --- | --- |
| [web application] | [purpose / owner] | [deployed version, official support policy] | [database, files, APIs] | [configuration or observation] | [gap] |
| [scheduled job / worker] | [purpose / owner] | [runtime / library] | [trigger, inputs, outputs] | [schedule / run history] | [gap] |
| [integration] | [purpose / owner] | [vendor / contract] | [identifiers, retries, external actions] | [sandbox / documentation] | [gap] |
| [manual workaround] | [people / task] | [procedure owner] | [spreadsheet, copied records, approvals] | [sample / time record] | [gap] |

Record where the application actually runs and who supplies updates. Check the runtime, framework, database, operating system and important dependencies separately. Mark inaccessible evidence as unknown. An inventory is not a security certification.

## 3. Existing behavior and first change

- Repository and baseline revision: [reference]
- Reproducible setup and safe test data: [instructions / fixture]
- Critical journey and observed output: [request, export, report or integration]
- Required behavior that differs from today's behavior: [explicit decision]
- Characterization checks and their limits: [what is captured; what is untested]
- First bounded change and exclusions: [scope]
- Reviewer, acceptance evidence and stop condition: [record]

Preserving observed behavior does not prove that behavior is desirable or correct. Resolve a known defect as an explicit requirement instead of silently approving it because a baseline check passes.

## 4. Compare options using evidence

| Option | Constraint it addresses | What remains unchanged | Evidence still needed | Transition / operational burden | Next bounded decision |
| --- | --- | --- | --- | --- | --- |
| Continue with maintenance | [constraint or reason to retain] | [workflow / technology] | [support and recovery evidence] | [ongoing ownership] | [review point] |
| Improve a defined part | [specific problem] | [surrounding system] | [dependency and compatibility checks] | [release / data changes] | [small change or investigation] |
| Replace one capability | [specific problem] | [remaining capabilities] | [routing and data ownership] | [temporary coexistence] | [pilot boundary] |
| Buy or build a successor | [required outcome] | [data / integrations to preserve] | [fit, migration, licensing or delivery evidence] | [parallel work / adoption / retirement] | [evaluation before full commitment] |

Do not treat a platform move as proof that application defects are repaired. A replacement still needs maintenance. Record which system owns each write during a transition and which old dependencies must remain available.

## 5. Cost ledger

Choose one currency and period. Identify whether each amount is a supplier payment, an allocated internal effort cost or an uncertain business impact. A decrease in staff effort can release capacity without reducing payroll.

| Cost item | Continuing monthly | Target monthly | One-off / temporary | Cash or internal effort | Source, date and uncertainty |
| --- | ---: | ---: | ---: | --- | --- |
| Supplier maintenance | [amount] | [amount] | [if separate] | [classification] | [invoice / proposal] |
| Hosting and licenses | [amount] | [amount] | [extra parallel resources] | [classification] | [bills / contract] |
| Internal review and coordination | [amount] | [amount] | [transition effort] | [classification] | [hours × agreed costing rate] |
| Manual workarounds | [amount] | [amount] | [training or migration effort] | [classification] | [non-overlapping hours] |
| Implementation and handover | [if recurring] | [if recurring] | [amount] | [classification] | [scope and exclusions] |

If incident labor is already inside a maintenance or time-record total, do not add it again. Distinguish elapsed downtime from staff hours spent responding. Keep uncertain lost-business estimates separate from the base total and explain their basis; do not add lost revenue and lost margin as two independent losses.

### Fictional worked example

A distributor considers a targeted change to an order-approval portal. All amounts below are invented US-dollar planning inputs. The comparison assumes equivalent required functionality, constant monthly costs and no tax, inflation or discounting.

| Monthly item | Continue as-is | After the change |
| --- | ---: | ---: |
| Supplier maintenance | $2,400 | $1,500 |
| Hosting and licenses | $1,000 | $900 |
| Internal review and coordination | $1,000 | $600 |
| Manual workarounds | $1,200 | $300 |
| Total | $5,600 | $3,300 |

- One-off implementation: $36,000.
- Separate migration and handover work: $5,400; excluded from the implementation amount.
- The old monthly cost continues for months 1–6. The target monthly cost starts in month 7.
- Extra parallel resources cost $900 per month for three months within that transition: $2,700 total. This is additional transition infrastructure, not another charge for the full target operating model.
- The cost categories use distinct invoices or staff time. No benefits from faster sales, fewer incidents or future features are assumed.

For a horizon `H` longer than the six-month transition:

```text
Continue = H × 5,600
Change = 36,000 + 5,400 + (6 × 5,600) + ((H − 6) × 3,300) + (3 × 900)
Difference = Change − Continue
```

| Horizon | Continue | Change | Difference |
| --- | ---: | ---: | ---: |
| 24 months | $134,400 | $137,100 | Change costs $2,700 more |
| 36 months | $201,600 | $176,700 | Change costs $24,900 less |

The target's lower monthly total does not make it cheaper over every horizon. These totals include internal effort; they are not a cash-payback or investment-return forecast.

### Delay sensitivity

Assume the old monthly cost lasts nine months and the target starts in month 10. Keep the two one-off amounts and the three months of extra parallel resources unchanged solely to isolate the operating-cost effect of delay. If delay also increases implementation, overlap or staff effort, add those costs separately.

```text
Delayed change = 36,000 + 5,400 + (9 × 5,600) + ((H − 9) × 3,300) + (3 × 900)
```

| Horizon | Continue | Delayed change | Difference |
| --- | ---: | ---: | ---: |
| 24 months | $134,400 | $144,000 | Change costs $9,600 more |
| 36 months | $201,600 | $183,600 | Change costs $18,000 less |

Replace these inputs with your own records and proposals. Keep low/base/high estimates beside uncertain items rather than presenting invented precision as measured evidence.

## 6. Reconciliation and release decision

For the fictional portal, approved revisions are exported to fulfillment. Before switching an export path, define how to compare the same input population in both implementations without sending duplicate instructions to the fulfillment provider.

| Check | Expected rule | Evidence and unresolved differences | Owner |
| --- | --- | --- | --- |
| Input population | Same identified records and snapshot / cutoff | [reference] | [role] |
| Inclusion and exclusion | Each input included or rejected for a stated reason | [reconciliation] | [role] |
| Identity and relationships | Order IDs, revision IDs and ownership preserved | [record-level comparison] | [role] |
| Business values | Approved revision, status, totals and format meet the agreed contract | [comparison] | [role] |
| External effects | Only the designated writer sends each instruction | [sandbox / control evidence] | [role] |
| Exceptions | Differences resolved or explicitly accepted before release | [decision] | [role] |

Equal row counts alone do not establish that records, values or relationships match. Use a safe environment for rehearsal and record checks that could not be performed.

## 7. Cutover, recovery and ownership

- Source of truth and allowed writer before, during and after cutover: [record]
- Incoming-write controls, final synchronization and validation: [sequence]
- Go/no-go owner and stop conditions: [record]
- Last checkpoint before the target accepts new business writes: [checkpoint]
- Recovery before that checkpoint: [tested procedure and evidence]
- Recovery after new target writes: [how new data and external effects are reconciled]
- Backups, restoration evidence and expected recovery limits: [record]
- Monitoring, support owner and access handover: [record]
- Conditions for retiring old components: [dependencies, records, access and decision]

Routing traffic back or deploying an older version does not automatically recover later writes or undo an external action. Review application recovery, data recovery and third-party effects separately.

Guides:

- https://nomadicsoft.io/blog/legacy-system-modernization
- https://nomadicsoft.io/blog/cost-of-maintaining-legacy-systems
- https://nomadicsoft.io/blog/brownfield-software-development