All work
Research & decisionsLive

Repair, Modernize, or Replace?

The live assessment compares rewrite, strangler, in-place modernization, and hybrid approaches against business dependence, delivery safety, and team capacity.

Project
Legacy Modernization Roadmap Generator
Role
Decision framework, assessment design, and frontend engineering
Timeframe
2026 – present
Status
Live

Evidence from the work

Options compared
Rewrite, strangler, in-place modernization, and hybrid

What this is

The Legacy Modernization Roadmap Generator is an interactive decision tool for teams evaluating an aging codebase. It compares repair and migration approaches against the system’s condition, business importance, available safety net, team capacity, and tolerance for disruption.

The tool gives a team a starting strategy and phased roadmap. It does not replace inspection of the repository or operating environment.

The friction

When a feature exposes another old boundary, a clean replacement can sound easier than explaining years of accumulated constraints. The code may be slow to change, its framework may have fallen behind, and nobody wants to keep paying for the same friction.

The decision changes once the team names the system’s business role. A peripheral tool can tolerate a different migration path than the platform responsible for revenue. Test coverage, deployment automation, data coupling, and team knowledge also change which option is safe.

The framework compares those constraints before recommending a technical pattern.

The senior decision

We designed the recommendation as a sequence rather than a one-time verdict.

The assessment asks about codebase age, architecture, test coverage, deployment, team skills, budget, urgency, business dependence, and the approaches already under consideration. It then compares four strategies: a clean-slate rewrite, strangler migration, in-place modernization, and a hybrid.

Each strategy includes the situations it suits, benefits, and costs. The roadmap begins with assessment and a safety net before proposing a first migration slice. That order protects the business while the team learns whether the chosen approach works in its environment.

What became real

The live tool produces a strategy and a phased plan covering assessment, tests and observability, a bounded first slice, wider migration, and ongoing optimization. “Repair” appears as in-place modernization: improve the existing system without pretending every problem requires a replacement.

The first slice serves as evidence. The team can measure delivery, migration risk, and operational behavior before scaling the approach across the system.

Evidence

The Legacy Modernization Roadmap Generator is live. Visitors can complete the assessment and inspect the strategy descriptions, risks, and roadmap phases.

The result is directional, not an assessment of a visitor’s actual repository or operating environment. A codebase audit and stakeholder review remain necessary before a team commits budget or production traffic to a migration.

What we learned

Modernization choices depend on operational constraints as much as code structure. Business criticality and rollback ability can rule out an approach that looks attractive in a diagram.

A bounded migration slice creates better evidence than a long debate about a total rewrite. It lets the team test the architecture and the delivery process at the same time.

Current state

The assessment is live as a free planning resource. Dakic uses the same constraint-first reasoning in architecture roadmaps and codebase audits.