Refactor vs rebuild

Yes, a boundary exists: A staged refactor or replacement of one capability may be possible.

Check: Name the first boundary and run one thin end-to-end change through it.

Not yet: A rewrite claim is premature until the coupled paths are mapped.

Check: Trace one customer journey and the data it changes before choosing a migration strategy.

We have not tested this: The migration boundary is the key unknown.

Check: Run a two-week dependency and data-flow assessment.

Yes: Parallel operation can reduce cutover risk.

Check: Define a reversible release and reconciliation check.

No: Cutover risk could dominate the technical choice.

Check: Model downtime, rollback, and data migration as explicit acceptance criteria.

Unclear: Operational constraints need evidence.

Check: Review deployment and rollback history with operators.

Yes, supported by evidence: The repair has an observed target rather than a general dislike of the stack.

Check: Keep a before-and-after acceptance measure for the affected journey.

Partly, with known gaps: Some symptoms are measured, but their causes may lie outside the proposed replacement.

Check: Trace a recent failed or delayed change and separate code, dependency and decision causes.

No, the check is not met: A broad rebuild could spend money without addressing the actual constraint.

Check: Trace a recent failed or delayed change and separate code, dependency and decision causes.

Unknown, not verified: Missing evidence prevents a conclusion. Use incident records, change lead times and failing customer journeys. Code age alone is not evidence for replacement.

Check: Trace a recent failed or delayed change and separate code, dependency and decision causes.

Yes, supported by evidence: A replacement can be compared with the behavior customers still require.

Check: Version the behavior baseline and explicitly approve any intended changes.

Partly, with known gaps: Covered journeys reduce uncertainty, but uncovered exceptions remain migration risks. Resolve the prerequisite's remaining gaps before making the stated commitment.

Check: Have product and operations review representative inputs, outputs and exception cases.

No, the check is not met: Feature parity cannot be judged reliably from a list of screens.

Check: Have product and operations review representative inputs, outputs and exception cases.

Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Include exceptions, integrations and undocumented business rules, not just happy-path screens.

Check: Have product and operations review representative inputs, outputs and exception cases.

Yes, supported by evidence: The proposed transition distinguishes code rollout from data correctness.

Check: Rehearse a representative data transition and retain reconciliation evidence.

Partly, with known gaps: A migration map exists, but unresolved writers or historical records can still prevent cutover. Resolve the prerequisite's remaining gaps before making the stated commitment.

Check: Document phase-specific writers, comparison checks and the disposition of mismatches.

No, the check is not met: Running two implementations without clear data authority can create conflicting state.

Check: Document phase-specific writers, comparison checks and the disposition of mismatches.

Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Identify the writer, schema compatibility, historical records and a mismatch-handling owner for each phase.

Check: Document phase-specific writers, comparison checks and the disposition of mismatches.

Yes, supported by evidence: Recovery considers irreversible effects, not only deployment reversal.

Check: Retain the last safe reversal point and the separate post-write recovery procedure.

Partly, with known gaps: Pre-write rollback is known, but post-write reconciliation or recovery remains untested. Resolve the prerequisite's remaining gaps before making the stated commitment.

Check: Walk through a failed cutover after a new write, including downstream effects and recovery ownership.

No, the check is not met: A cutover plan could promise a reversal that no longer preserves data.

Check: Walk through a failed cutover after a new write, including downstream effects and recovery ownership.

Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. A binary rollback is not enough when the new version changes data or emits external effects.

Check: Walk through a failed cutover after a new write, including downstream effects and recovery ownership.

Yes, supported by evidence: Parallel operation has explicit people and support capacity.

Check: Review overlap load at each migration milestone and reduce it when a path is retired.

Partly, with known gaps: Some ownership exists, but overlap may crowd out delivery or incident response.

Check: Assign support and transition owners, estimate overlap work and agree which other work can move.

No, the check is not met: The migration depends on support work that has no available owner.

Check: Assign support and transition owners, estimate overlap work and agree which other work can move.

Unknown, not verified: Missing evidence prevents a conclusion. Check on-call load, incident response and maintenance capacity rather than assuming the old product stops needing care.

Check: Assign support and transition owners, estimate overlap work and agree which other work can move.

Yes, supported by evidence: The choice considers lifecycle burden for comparable accepted outcomes.

Check: Retain assumptions and revisit the comparison when scope or overlap changes.

Partly, with known gaps: Implementation estimates exist, but missing transition or residual costs can reverse the choice.

Check: Compare one thin repair with one replacement slice using identical acceptance criteria and explicit exclusions.

No, the check is not met: Comparing build effort alone can hide the expensive part of replacement.

Check: Compare one thin repair with one replacement slice using identical acceptance criteria and explicit exclusions.

Unknown, not verified: Missing evidence prevents a conclusion. Include transition, residual contracts, support, testing and retirement. A sunk payment is not automatically avoidable savings.

Check: Compare one thin repair with one replacement slice using identical acceptance criteria and explicit exclusions.