Old software is often treated as a liability to replace. Sometimes it is. Just as often it is the only place where years of operational knowledge still live in an executable form.
When a business depends on an inherited system—aging framework, thin documentation, one person who “knows how it works”—the instinct is familiar: rewrite it. Clean stack. Fresh schema. Modern UI. The promise sounds like relief.
The risk is quieter. The system may be ugly, but it still encodes decisions the operation learned the hard way: exceptions, sequencing, pricing quirks, check-in variants, inventory rules that never made it into a wiki. Throw the code away before you recover that knowledge, and you inherit a clean architecture that is wrong in the places that matter.
Behavior vs. code
Engineers naturally see legacy as a code problem: unsupported language, brittle modules, inaccessible data layer, tests that never existed. Those are real problems. They are not the whole problem.
The harder problem is behavioral. What must remain true for the business to keep running? Which “bugs” are actually policy? Which edge cases happen every Tuesday? Which rules live only in the heads of the people who run the floor?
Code can be reconstructed. Business knowledge discarded by accident is expensive to rediscover—especially after the people who held it have moved on, or after the old system is no longer available as a reference.
Where knowledge hides
In long-running operational systems, knowledge typically sits in several places at once:
In the code — conditionals, state machines, validations, batch jobs, and integrations that implemented real rules whether or not anyone named them.
In the data — historical records, status codes, and relationships that reveal how the operation actually evolved.
Around the system — spreadsheets, checklists, and informal protocols that filled gaps the software never modeled.
In people — institutional memory that never became documentation.
A rewrite that only interviews for “requirements” often captures the happy path. The exceptions surface later, in production, as gaps—exactly the pattern that made the old system feel indispensable.
Why rewrite-first is risky
Rewrite-first assumes the hard part is construction. On important operational software, construction is often the easier part. The hard part is knowing what can safely change.
Starting with a blank system before recovering behavior tends to:
— optimize for a simplified model of the operation
— discard encoded rules that looked like mess
— underestimate continuity constraints (the business still has to run)
— discover load-bearing edge cases after cutover pressure is already high
None of that means you should never rebuild. It means rebuild is a decision that should follow evidence—not a default reaction to technical debt.
Understand before modernization
A safer sequence looks like the first half of the Stax Method:
Understand — recover how the operation and current system actually work.
Model — make workflows, states, rules, data, and dependencies explicit.
Decide — maintain, stabilize, extend, modernize, rebuild, replace—or leave it alone.
That first stretch is what Stax calls Groundwork. It is not a ceremony that always leads to a build. Sometimes the recommendation is to stabilize what you have. Sometimes an off-the-shelf platform is the better answer. Sometimes rebuild is correct—but only after you know what you are rebuilding.
What recovery looks like in practice
On an active warehousing engagement, Stax worked with a decade-old ColdFusion inventory platform that had little usable documentation, a fragile data layer, and critical knowledge concentrated in one person—while the business still depended on the system day to day. The technology problems were solvable. The more interesting constraint was recovering workflow and business rules before changing the system, and capturing architecture, data relationships, and operational logic so the work would not depend solely on undocumented institutional knowledge. Measured progress includes migration of 1M+ records to date; the rebuild is designed around 20 operational roles. A reduction of more than 50% in manual work remains a goal, not a claimed result.
That is the difference between modernization as fashion and modernization as controlled change.
A practical test
Before approving a rewrite, ask:
Do we know which behaviors are load-bearing?
Do we know which “quirks” are actually business rules?
Can we explain the exceptions without the person who “just knows”?
Do we have a path that keeps the operation running while change lands?
If the answers are vague, you do not have a rewrite plan yet. You have a hope that construction will invent clarity. Sometimes it does. On important software, that is a bet you should make deliberately—or not at all.