The team proposes a complete rewrite. What evidence should we request?
Unvalidated replacement strategyCompare incremental improvement, replacement, and hybrid options against real constraints and transition risk. A rewrite must address migration and continuity, not only the appeal of cleaner code.
What to do now
- Identify the current system's actual limitations
- Compare feasible improvement options
- Test the hardest replacement assumptions
- Plan a controlled transition and decision gate
When to escalate
The proposal lacks a credible migration or continuity path.
The technical owner and authorized release decision maker
Example
A team replaces one isolated capability first to test the approach before committing to full replacement.
Mistake to avoid
Assuming new code automatically removes old business complexity.
Prevent a repeat
Review real execution evidence and maintainability alongside feature completion; do not treat an unrun test as passed.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Approvals
Track delivery tasks and attach engineering evidence; keep source control, build execution and technical controls in their actual engineering systems. See the platform
Related cases
- We discover integration problems only before release. How can we improve?Late integration feedback
- Developers keep adding new libraries. What should we control?Unmanaged software dependencies
- How do we distinguish an issue from a change request?Resolution-versus-baseline decision
- The team marks tasks complete without evidence. What should change?Evidence-free completion