Should you rescue legacy software, rebuild it, or take a hybrid path?
The wrong answer is expensive. Rebuild too eagerly and you throw away years of quiet business logic. Rescue too long and every change stays fragile.
The decision should not start with how much everyone dislikes the old code. It should start with five factors:
- Business fit: does the system still match how the business works?
- Change safety: can the team change it without breaking unrelated things?
- Platform support: is the runtime, framework, and database still supported?
- Ownership: does anyone still understand the system?
- Scope: how large is the business change now required?
If most factors are healthy, rescue and modernize in place. If most are broken, rebuild the affected capability. If the answer is mixed, take the hybrid path: put a stable interface around the painful capability, rebuild that slice, cut over, and repeat.
I wrote the full guide with a free browser-only scorecard here:
https://care.omniai.one/blog/rescue-or-rebuild-legacy-software/
The scorecard returns a Rescue, Hybrid, or Rebuild read in about two minutes. It does not send data anywhere.
The useful first step is usually not a year-long rewrite plan. It is one honest slice: the capability that causes the most pain, the interface that protects the rest of the business, and the smallest modernization move that proves the cost.
답글 남기기