Define the forcing constraint
Name what must become possible.
- Required business outcome and deadline
- Current failure or change-cost evidence
- Constraints that cannot be negotiated
Resource 14 · Decision guide
Rebuild or refactor guide
Decide whether to repair the current system, replace a core, or rebuild—using constraints, transition cost, and evidence instead of frustration.
The working guide
Follow the evidence across the whole system.
A rebuild is not automatically cleaner, and a refactor is not automatically safer. The right answer preserves working business behavior while removing the constraint that actually blocks the roadmap.
Measure what still works
Protect valuable behavior and knowledge.
- Stable workflows and proven domain rules
- Data that must remain authoritative
- Integrations and edge cases already learned
Compare three options
Use the same acceptance criteria.
- Incremental refactor around the critical path
- Replace one bounded core while preserving the rest
- Parallel rebuild with an explicit migration path
Price the transition
Count more than implementation.
- Dual-running and data migration cost
- Regression, retraining, and operational disruption
- Rollback and customer-communication requirements
Choose reversible milestones
Keep evidence ahead of commitment.
- First milestone tests the highest-risk assumption
- Old and new behavior are compared
- Stop conditions are defined before work begins
Evidence to keep
Leave a record another person can verify.
- 01Critical workflow and dependency map
- 02Change-failure and incident history
- 03Option comparison with transition costs
- 04Milestones, acceptance criteria, and stop conditions
Choose the next useful step
Use the guide to define the first accountable decision.
We can review the evidence with your team and turn the gaps into a scoped plan without taking ownership away from you.