phoenix
phoenixPhoenix - Your AI Assistant
Inactive session will be ended in 24 hours
End Session

Azure Migration Specialist - Full details in attachment.

  • Posted:
  • Proposals: 31
  • Remote
  • #4508615
  • OPPORTUNITY
  • Open for Proposals
Majid Ali K.Adnan M.KreativMetaPankaj K.Nika S. + 26 others have already sent a proposal.
  • 5

Description

Experience Level: Expert
## Azure specialist to deliver a UK-sovereign production migration (Container Apps · PostgreSQL Flexible Server · Azure OpenAI)

The project

We run a multi-tenant ready single-tenant B2B SaaS platform (project delivery / PMO software) used in production by enterprise customers. The stack is a TypeScript modular monolith — Fastify API, React SPA, PostgreSQL 17 — currently hosted on Supabase Cloud, Fly.io, and Vercel. An enterprise customer requires **UK sovereign data hosting**, and we are migrating the platform onto Azure in the UK, with sovereignty technically enforced (region-locked policy, private networking, customer-managed keys) rather than promised on paper.

**The design work is done.** You will not be starting from a blank page: there is a complete, independently reviewed document set — a High-Level Design, a code-verified Low-Level Design, and a step-by-step migration plan with exit gates, a cutover runbook, and a rollback model. Your job is to **execute and manage the Azure side of that plan**, challenge it where your experience says it's wrong, and get production cut over safely.

### The target architecture (summary)

- **Compute**: Azure Container Apps, internal-only environment in a VNet, four containerised services plus a one-off migration Job; Application Gateway WAF_v2 as the single public entry.
- **Data**: Azure Database for PostgreSQL Flexible Server (PG17), PITR, customer-managed keys, geo-redundant backup to a second UK region; Blob Storage with user-delegation SAS.
- **Identity & secrets**: managed identities end-to-end (goal: no static credentials anywhere in production), Key Vault, GitHub Actions OIDC federation for CI/CD.
- **AI**: Azure OpenAI, UK South, regional Standard deployments only (data residency enforced by policy).
- **Email**: Azure Communication Services (SMTP relay).
- **Observability**: Azure Monitor / Log Analytics with an alerting path into our existing external paging service; always-on audit baseline (Activity Log, Azure Policy, Defender for Cloud).
- **Auth**: the platform's existing open-source auth server (Supabase GoTrue) is re-hosted as a container — sessions and passwords survive the migration by design. You don't need prior GoTrue experience, but you do need to be comfortable running a third-party container against Postgres.

Full details in attachment




New Proposal

Login to your account and send a proposal now to get this project.

Log in

Clarification Board Ask a Question

  • CYTNHIA W.

    Your migration plan mentions exit gates and rollback criteria—have these already been validated through a full dress rehearsal, or would you expect the successful developer to execute and refine the rehearsal before production cutover?
    How are you planning to enforce UK sovereignty operationally after go-live? For example, are Azure Policy, resource locks and management groups already in place, or is implementing those controls part of this engagement?
    Has the networking design already been validated for private connectivity between Container Apps, PostgreSQL Flexible Server, Key Vault and Azure OpenAI, or do you anticipate refinements during implementation?
    Will the existing GitHub Actions pipeline be migrated to Azure using workload identity federation (OIDC) from day one, or is there an interim deployment strategy planned during the migration?
    For the PostgreSQL migration, are you expecting a logical migration with a controlled cutover window, or are you considering replication-based approaches to minimise downtime for production customers?
    Since the platform is already serving enterprise customers, what level of downtime is considered acceptable during final cutover, and what are the defined success metrics before rollback is triggered?
    How do you intend to validate Azure OpenAI's regional residency and data handling requirements as part of your compliance process—through Azure Policy alone, or are there additional customer audit requirements?
    Does the supplied Low-Level Design already define the monitoring and alert thresholds for Azure Monitor, Log Analytics and Defender for Cloud, or is tuning the observability stack expected as part of production hardening?
    Beyond executing the migration, are you looking for someone who can challenge architectural decisions where Azure best practices have evolved since the HLD/LLD were produced, or should implementation remain strictly aligned with the existing documentation?

  • Khalid H.

    A few questions before we begin:

    • Is the Azure subscription and tenant already provisioned?
    • Will Infrastructure as Code be implemented using Bicep or Terraform, or are you open to recommendations?
    • Has the Azure OpenAI quota already been approved?
    • Approximately how large is the PostgreSQL production database?
    • Is the migration expected to be zero-downtime or within a planned maintenance window?