| name | app-modernization-operations |
| description | OPERATIONS & CUTOVER phase of the optional application-modernization module: plan how the converted application deploys together with the database cutover — artifact + configuration, ordering against the DB cutover runbook, rollback, and post-cutover checks. Engine-agnostic. Invoked by app-modernization-orchestrator after Validation is approved. Produces migrations/<project>/05-application/04-operations/app-cutover.md.
|
Application Modernization — Operations & Cutover
The application and the database must cut over together: the DB cutover runbook
(migrations/<project>/04-operations/cutover-runbook.md) already treats the converted app build
as a precondition (its step 0.1) and switches connections mid-runbook. This phase produces the
app-side half of that contract.
Inputs
- The approved Validation results (
03-validation/build-report.md), including the open
behavioural risks and anything UNVERIFIED.
- The conversion log (
02-construction/conversion-log.md) — especially config/credential changes.
- The database cutover runbook and rollback plan under
migrations/<project>/04-operations/.
Write 04-operations/app-cutover.md covering
- Deploy artifact + configuration — which build/tag carries the converted code, and the
target connection configuration. Secrets by reference (environment variable / secrets manager),
never inline; name the variable the config now expects (e.g.
DB_PASSWORD).
- Ordering against the DB runbook — cite the exact runbook step that deploys the app, and
state the hard constraint: the app must not start against the target before the post-data
objects (FKs, triggers) and identity resets are applied.
- Rollback — redeploying the previous build and repointing at the source database, plus the
point after which that stops being clean (the DB rollback plan's point of no return). If the
old build is gone, say so — that is itself a finding.
- Feature flags / dual-run, if the app supports running against either engine; otherwise say
plainly that the switch is atomic with the deploy.
- Post-cutover checks — the app-level signals that prove the converted code paths work,
not just that the app is up: the rewritten search returns hits, a converted routine call
succeeds, an insert allocates an identity. Cross-reference the DB monitoring checklist rather
than duplicating it.
- Open behavioural risks carried into production, each with a named owner — these survive a
green build by definition (search ranking differences, limit-vs-rownum semantics, date
approximations).
- Deferred/blocked items that ship unresolved (with the recorded decision), so the runbook
reader knows what is intentionally incomplete.
Gate
Present the plan and stop: "Approve the application cutover plan?" Cutover execution itself
is a production action — only proceed under explicit user direction, step by step, never
unattended.
Safety
- This phase writes documentation only; it deploys nothing.
- Never echo secret values when describing configuration.
- If the DB migration has not itself passed its Operations gate, say so — the app cutover plan
cannot be approved ahead of the database's.
