Staging Migration Execution Prerequisites

Area: migration / deployment / infrastructure / staging Raised during: Session 2026-07-07 (Sprint 1 1a.9) Jira: (add when available) Priority: High — blocks the end-of-Sprint-1 staging acceptance run

Deferral decision (2026-07-08): The staging acceptance run has been deferred from 1a.9 close to end of Sprint 1 (after Step 1b). Rationale: (1) the security acceptance criterion is already 1b-gated, so a complete run cannot happen until after 1b.3 anyway; (2) the local MySQL 8.4 rehearsal has already de-risked migration quality (ADR 012); (3) these prerequisites need to be resolved for 1b staging work regardless, so resolving them once for a combined 1a+1b acceptance run is more efficient. These prerequisites remain blocking — they just target the post-1b run, not 1a close.

The 1a.9 migrate → validate → rollback cycle (scripts/migration-cycle.sh) works locally in DDEV, but two pieces of staging plumbing do not yet exist. Both must be resolved before the cycle can run in staging. See the 1a.9 Staging Acceptance Checklist §A for where these sit in the run sequence.

1. Migrate source DB in staging

The Migrate API reads the D7 source through Drupal's migrate DB connection. That connection is defined only inside the DDEV block of settings.php ($databases['migrate']['default'] → the local d7_images DB). In staging there is no DDEV, so the block is skipped and the connection does not exist — migrate:import has nothing to read from.

Two sub-parts: - Where the D7 dump is loaded so the staging D11 container can reach it — a secondary schema on the staging RDS instance, or a separate throwaway RDS. Cost / isolation / production-data-in-staging-infra decision. - An env-driven migrate connection for staging — defined outside the DDEV conditional, reading host/db/user/password from environment/secrets the way the rest of the staging config does. No such wiring exists yet.

Owner: Xiaoming (the app-side connection code) + Yuji / Dave (RDS provisioning + the production-data-handling decision). Related: Images prod packaging.

2. Drush execution path in staging

The whole cycle is driven by drush (migrate:import, kmassets:index-all, kmassets:audit, and the script's DRUSH override). The CodePipeline (pipeline/buildspec.yml, deployspec.yml) runs no migrate/drush steps — deployment only builds and ships the image; migrations are manual. So the open question is how a drush command is invoked against the running staging container (ECS execute-command / one-off ECS task / Ansible), and that whoever runs the acceptance test has that access.

Owner: DevOps / Yuji (deployment + AWS/IAM plumbing).

Why tracked here

Both are pre-cutover infrastructure gaps, not application bugs. Resolving them in parallel with the DDEV rehearsal is what keeps the local→staging promotion from stalling. When Jira is live, each becomes a ticket.