# 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.

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.

## 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

## 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

- Critical workflow and dependency map
- Change-failure and incident history
- Option comparison with transition costs
- Milestones, acceptance criteria, and stop conditions