Name the constraint
An application being old is not a complete diagnosis. Perhaps its runtime is unsupported, deployments are fragile or a new feature is blocked by one tightly coupled module. Record the concrete problem, the affected users and the cost of leaving it unresolved. Different constraints justify different interventions. A runtime upgrade does not automatically need a new interface, and a slow report does not by itself justify rebuilding the whole platform.
Use upgrade when the contract can stay
An upgrade keeps the main business behavior while changing supported versions and compatibility work. Inventory dependencies and test their interactions before selecting a target. Record the runtime used by web requests, background jobs and command-line tasks; an application can fail when those differ. Preserve a known baseline and a way to return to it without overwriting data created after the deployment.
Refactor the boundary that prevents change
A pricing function embedded in several screens may make updates inconsistent. Extracting a single business operation can solve that problem without replacing the rest of the software. Protect the old behavior with approved scenarios, then introduce the new internal boundary. Keep technical restructuring separate from a new pricing policy, because combining them makes unexpected differences harder to explain.
Rewrite only with a migration argument
Replacement may be justified when the old structure cannot support the intended outcome. That still leaves data migration, URLs, permissions and external integrations to resolve. Compare delivery risk and transition cost, not just the appeal of a new stack. Forge’s modernization path keeps this choice inside an approved plan, followed by evidence and a separately authorized deployment.
Choose the smallest change that solves the real constraint
An older application is not automatically a candidate for replacement. Identify the actual pressure: an unsupported runtime, painful maintenance, a data model that cannot support a new workflow or an inaccessible interface. The intervention should match the constraint rather than the appeal of a new stack.
For a portal with stable behavior and an aging framework, first investigate compatibility upgrades and targeted refactoring. For one obsolete integration, replace the adapter behind a stable business interface. A rebuild is more defensible when the current architecture prevents the required behavior and a narrower change cannot provide it economically.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Upgrade | Keep behavior; update supported components. | Compatibility and regression checks. |
| Refactor | Improve structure behind a stable contract. | Equivalent business outcomes. |
| Rebuild | Replace a boundary that blocks the goal. | Migration plan and independent acceptance. |
Where this goes wrong
The old system is evidence, not unquestionable authority. Preserve required behavior but document known defects. Otherwise, a parity test may force the new implementation to reproduce a bug, while a clean rewrite may accidentally remove a crucial exception known only to an operator.
Modernization is a decision about continuity, not a contest for the newest stack.
Turn it into a working checklist
- Identify the concrete constraint.
- Separate business change from technical change.
- Map data, URLs and integrations.
- Test a reversible transition.
A concrete next step
Write a decision record with the goal, options considered, migration boundary and evidence needed for success. Review it before implementation. The decision should remain understandable even after the original agent is replaced.
Watch a related case
The video could not be loaded. Try again later.