Migrate from Waterfall to ForgeSDLC

Waterfall’s phase gates often encode real risk and governance. Forge preserves that intent with decision checkpoints and evidence in the repo, while breaking work into small, traceable Sparks instead of monolithic phase dumps. High-level comparison: Forge vs traditional methodologies.

Principles

• Map gates → decisions — each legacy gate asks “what must be true to proceed?”; answer with Versona-backed reviews where discipline knowledge applies
• WBS stays — phases and deliverables become Milestones / Epics / Stories / Sparks without duplicating IDs
• Documentation moves next to code — Blueprints submodule + ADRs + Ember Log for directional choices
• Continuous assurance — replace “big binder at phase end” with incremental checks tied to Sparks and releases where safety allows

Phase gate translation

Rollout

1. Pick one pilot stream; keep external compliance artifacts if regulators expect them—add Forge links and IDs as the bridge (governance pack)
2. Introduce Blueprints for SDLC + the discipline that matches your current phase (e.g. Software Architecture during design-heavy work)
3. Decompose the next phase’s WBS into Sparks with clear done definitions; avoid “one Spark equals the whole phase”

Cadence

• You may still use calendar milestones for portfolio reporting; team-level work uses daily sync + Charge for execution transparency (meetings model)
• Milestone Versonas (scaling pattern) can align with your steering rhythm (scaling)

Risks to manage

• Hybrid confusion — name which artifacts are legal/compliance vs team operating defaults
• Over-correction — do not remove gates that law or customers require; encode them in blueprint checks instead

Next: Sponsors hub · Adoption playbook