Azure / Entra ID migration — issue index

Source documents: docs/AzureMove/, docs/entraId/, docs/Postgres/, docs/storage/, docs/infra/

All issues are AFK (no human approval gate required between them). Work streams can run in parallel where the dependency graph allows.

Current deployment state — 2026-05-05

Infrastructure track (001–006): COMPLETE.
All Azure resources provisioned in rg-mike-dev (uksouth). Schema migrated. All Container Apps healthy.

CI/CD track (007): IN PROGRESS — workflow + OIDC helper landed, awaiting first run against rg-mike-dev.
.github/workflows/deploy.yml builds the backend image via az acr build, runs the db-migrate Container Apps Job to completion, then promotes the backend Container App. OIDC federation is provisioned by scripts/setup-github-oidc.sh. See 007-implementation-plan.md.

Local validation stack: the backend runs against Docker (Postgres 16 + PostgREST v12.2.3 + Caddy + Azurite) with AUTH_PROVIDER=local for the fastest local loop — see docs/runbook-local-stack.md and 008.0-local-auth-provider.md. The frontend and backend also now support AUTH_PROVIDER=entra / NEXT_PUBLIC_AUTH_PROVIDER=entra for local Microsoft login validation — see docs/runbook-entra-local-auth.md.

Auth/code track (008–014): IN PROGRESS.
The app now has provider-dispatched backend auth validation (supabase, local, entra), local frontend auth/token storage, and a backend-owned Microsoft Entra login flow based on the MatterAI provider-selection pattern. Local Microsoft authentication was validated on 2026-05-05. Authenticated data flows still need broader validation with the current local PostgREST/Azurite stack, and the remaining Supabase/PostgREST compatibility boundaries should be isolated before deletion.

Next issue: 016-marketplace-listing.md.

Dependency graph

001 ──► 002 ──► 006 ──► 007
001 ──► 003 ──► 004 ──► 006
001 ──► 005 ──► 006

008 ──► 009 ──► 010 ──► 011 ──► 012 ──► 013 ──► 014
              004 ──┘
         009 ──────────────────────────────────────► 014

006 ──► 007
006 ──► 015 ◄── 010

Parallel starting points

These can begin immediately with no blockers:

• 001-bicep-infra-foundation.md — infra track root
• 008-backend-auth-provider-abstraction.md — auth code track root

Issue list

Suggested work order (two engineers in parallel)

Engineer A — infra track: 001 → 002 → 003 → 004 → 005 → 006 → 007 → 015

Engineer B — auth/code track: 008 → 009 are done; next validate 010–012 against the current local-first frontend/backend path, then decide whether 013 remains MSAL-based or stays backend-owned as implemented.

006 is the handoff point: B's work can be deployed and tested end-to-end once A completes 006.

Acceptance definition of done (full migration)

• 100 % of auth flows on Entra workforce tenant.
• Zero Supabase calls in any backend or frontend request path.
• All document operations succeed on Azure Blob Storage.
• Postgres queries and migrations stable on Azure Flexible Server.
• No secrets (DB password, JWT HMAC, storage keys) in Key Vault — MI is the only credential primitive.
• CI/CD pipeline deploys from main to Azure without manual steps.