Phase Patterns¶

Common phase groupings for remediation plans. Use these as starting templates and adapt to the specific situation.

Production Readiness (Prototype → Production)¶

Use when a prototype needs operational hardening without significant code changes.

Phase	Focus	Typical Effort	Dependencies
0. Containerisation	Dockerfile, docker-compose, .dockerignore, local validation	1–2 days	None
1. Infrastructure	Terraform/IaC for compute, database, registry, networking	3–5 days	Phase 0
2. CI/CD Pipeline	Build → push → deploy workflow, coverage gates, environment promotion	2–3 days	Phases 0, 1
3. Authentication	Replace placeholder auth with production identity provider	3–5 days	Phase 2
4. Observability	Telemetry SDK, structured logging, tracing, custom metrics	2–3 days	Phase 2 (parallel with 3)
5. Production Database	Replace dev storage with durable backend, migration tooling	3–5 days	Phases 1, 3
6. Security Hardening	CORS, secrets management, network security, rate limiting	2–3 days	Phases 3, 4, 5
7. Testing Gaps	Coverage thresholds, integration tests, load tests, e2e automation	2–3 days	Phases 2, 5
8. Operational Readiness	Runbooks, alerting, change management, handover docs	3–5 days	All prior

Critical path: 0 → 1 → 2 → 3 → 5 → 6 Parallelisable: 3 & 4, 7 starts after 2

Use when extracting shared code from monoliths or replacing direct package dependencies with API calls.

Phase	Focus	Dependencies
0. Repo Setup	New repo, project structure, CI pipeline, health endpoint	None
1. Copy Source Code	Vendor upstream modules into new repo, rewrite import paths	Phase 0
2. Copy Dependent Code	Vendor transitive dependencies (DB layers, utilities, config)	Phase 1
3. Wire API Routes	Create HTTP endpoints wrapping vendored business logic	Phases 1, 2
4. Migrate Consumer A	Replace direct imports with HTTP calls in first consumer app	Phase 3
5. Migrate Consumer B	Same for second consumer (can parallel with Phase 4 if independent)	Phase 3
6. Validation & Cleanup	Parity tests, dead code removal, dependency removal from consumers	Phases 4, 5

Key pattern: Each vendored module needs unit tests + parity tests comparing vendored vs original output.

Use when upgrading frameworks, patterns, or infrastructure across an existing production service.

Phase	Focus	Dependencies
0. Assessment	Inventory current state, identify migration targets	None
1. Foundation	Update runtime (Python version, framework), fix breaking changes	Phase 0
2. Architecture	Introduce new patterns (DDD, event sourcing, storage boundary) incrementally	Phase 1
3. Infrastructure	Modernise deployment (containers, IaC, new CI pipeline)	Phase 1
4. Migration	Move business logic to new patterns, migrate data	Phases 2, 3
5. Cutover	Switch traffic, validate, rollback plan	Phase 4
6. Cleanup	Remove legacy code paths, update docs, archive old infra	Phase 5

Key pattern: Run old and new in parallel during Phase 5. Never big-bang cutover.

Use when converting security, design, or operational audit findings into work.

Phase	Focus	Dependencies
0. Critical Fixes	Address any findings with active exploitation risk	None
1. High-Priority Fixes	Findings that block compliance or deployment	Phase 0
2. Medium-Priority Fixes	Findings that improve posture but don't block	Phase 1
3. Process Improvements	New gates, policies, or automation to prevent recurrence	Phase 2
4. Validation	Rescan, regression test, document residual risks	Phase 3

Key pattern: Fix root causes, not symptoms. If a finding recurs, the fix was wrong.

Merge phases if total plan would exceed 8 phases
Split phases if any single phase exceeds 5 days effort
Add a "Decision Gate" pseudo-phase if blocked decisions affect multiple downstream phases
Always include a final validation/cleanup phase — migration debt compounds fast