This is the Operations phase. Validation has proven equivalence; now plan the move to production safely, with a way back. Mirrors AI-DLC Operations: deploy and monitor from accumulated context, human signs off.
Inputs
- Approved validation results (
03-validation/equivalence-report.md+03-validation/reconcile_report.yaml) - Conversion log and migration plan (for scope and known caveats)
connections.yaml,migration-config.yaml
Required disclaimer on every generated artifact
Every document produced in this phase — the cutover runbook, rollback plan, monitoring checklist, and any other operational guide — MUST begin with the disclaimer block below, verbatim, as the first content in the file. Do not omit or summarize it. These are AI-generated operational plans for high-risk, production-facing actions; the human operator owns validating them.
> ⚠️ **AI-GENERATED — VALIDATE BEFORE USE.** This document was generated by the dbmig-aidlc
> AI-DLC framework from this migration's context. It is a **starting point, not an
> authoritative runbook.** Every step — commands, ordering, timings, rollback triggers,
> capacity and monitoring thresholds — must be **reviewed, adapted to your environment, and
> rehearsed in a non-production environment** before any production use. **You are responsible
> for validating the correctness, completeness, and safety of this plan before executing it.**
> This toolkit is intended for **non-production use**; production cutovers should be run by
> qualified personnel using your organization's change-management process.
Step 1 — Cutover strategy
Pick and document the approach with the user:
- Big-bang (downtime): quiesce source, final data sync, switch app, validate, open. Simplest; needs a maintenance window.
- Minimal-downtime (CDC): bulk load + AWS DMS change data capture to keep the target in
sync, then a short switchover. For large/24x7 systems. See the playbook
<pair>-playbook/references/tools/aws-dms.mdfor CDC setup (substitute the active engine pair).
Framework one-time loads (dbmig migrate-data) are for dev/test only — production data movement
should use AWS DMS.
Step 2 — Cutover runbook
Write 04-operations/cutover-runbook.md as an ordered, time-estimated checklist:
- Pre-cutover: final schema diff, target capacity check, backups/snapshots, freeze changes.
- Data: final sync / DMS cutover, sequence/identity reset to current source max values.
- Application: connection-string / driver switch (note JDBC/ODBC differences), feature flags.
- Smoke tests: run the validation suite's critical queries against production target.
- Open to traffic; monitor. Include owner and rollback trigger for each step.
Step 3 — Rollback plan
Write 04-operations/rollback-plan.md (required if migration-config.yaml cutover.require_rollback_plan is true):
- Point of no return and the decision criteria to roll back.
- How to revert app connections to the source.
- Data divergence handling (writes that landed on the target after cutover).
- Keep the source intact and reachable until a defined soak period passes.
Step 4 — Monitoring
Write 04-operations/monitoring.md: post-cutover checks for the first hours/days —
error rates, slow queries (PG pg_stat_statements), connection counts, replication/CDC lag,
autovacuum/bloat, and the app-level KPIs that prove correctness. Reference the playbook
monitoring and performance-tuning chapters.
Gate
Present the runbook, rollback plan, and monitoring checklist. Stop at the gate: "Approve the cutover & rollback plan?" Cutover execution itself is a high-risk, production action — only proceed under explicit user direction, step by step, never unattended.
Safety
- Production cutover and data movement are high-risk. Confirm each destructive/irreversible step. Never drop or truncate source data. Verify backups exist before the point of no return.