Existing platform
- Two AWS Lambda workloads for user and batch processing
- Amazon API Gateway as the public API layer
- Amazon RDS for PostgreSQL
- Existing consumers that could not be moved in a single cutover
Case study / Cloud migration
AWS to Azure API migration with private networking and staged cutover.
A business-critical serverless API was moved from AWS to Azure while preserving service continuity, tightening network boundaries and keeping the legacy endpoint available during migration.
Context
Move the API platform without treating the migration as a simple lift-and-shift.
The existing service used AWS-managed serverless components. The target had to fit an Azure platform model with private ingress, private database connectivity, managed identities and enterprise security controls.
Target platform
- Azure Application Gateway WAF in front of internal API Management
- Two Linux Azure Function Apps with VNet integration
- Azure Database for PostgreSQL Flexible Server on private networking
- Azure Key Vault, Container Registry and managed identities
Constraints
The difficult part was connectivity, deployment and rollout behavior around a private target platform.
The application code was only one part of the migration. The platform had to be deployable by CI/CD, reachable through the approved ingress path and isolated from unnecessary public access.
Private ingress
API Management operated internally behind Application Gateway WAF rather than as an unrestricted public endpoint.
Private data plane
PostgreSQL and supporting services used private connectivity, which changed how workloads and deployment tooling reached dependencies.
Two deployment models
The interactive Function was packaged directly while the batch workload used a container image pulled from Azure Container Registry.
CI/CD network access
Build and deployment runners needed explicit network paths to private services instead of relying on public management endpoints.
Security validation
The target endpoint had to pass security testing before it could be treated as production-ready.
Controlled cutover
The legacy endpoint remained available while consumers and pipelines moved to the Azure endpoint incrementally.
Approach
Build the target as an operable platform, then migrate traffic and delivery paths in stages.
The migration sequence reduced the number of simultaneous changes and made failures easier to isolate.
Map current behavior
Separate API behavior, batch processing, persistence and deployment requirements before designing the Azure equivalent.
Build private foundations
Provision networking, internal APIM, WAF ingress, private PostgreSQL, identity and secret-management dependencies.
Deploy both workloads
Use the appropriate Function deployment model for the interactive and batch execution paths.
Validate security and health
Exercise health endpoints, application paths and security controls before directing production consumers to the new platform.
Cut over incrementally
Bring the Azure endpoint live, retain the legacy endpoint temporarily and migrate deployment pipelines and consumers progressively.
Outcome
A production Azure endpoint went live without forcing a high-risk one-shot migration.
No synthetic performance or cost claims are used here. The outcome is described only in terms of delivered platform state and rollout capability.
Azure endpoint live
The new API endpoint was made available on the target Azure platform and validated through production health paths.
Security testing completed
The target architecture passed the required security validation before wider rollout.
Private database architecture
Application workloads connected to Azure PostgreSQL through the intended private network design.
Both execution paths supported
Interactive and batch workloads were deployed using packaging appropriate to each workload.
Rollback path preserved
The previous endpoint remained available during transition rather than being removed at the moment the Azure endpoint went live.
Pipeline migration staged
Deployment workflows could be moved independently after the target runtime was proven operational.
Technology
Cross-cloud migration across application, network and delivery layers.
The engagement required more than mapping AWS product names to Azure product names. Runtime packaging, identity, network reachability and deployment architecture all changed.
Target stack
- Azure API Management
- Azure Functions
- Application Gateway WAF_v2
- Azure PostgreSQL Flexible Server
- Azure Container Registry
- Azure Key Vault and managed identity
- VNet integration and private DNS
Source stack
- AWS Lambda
- Amazon API Gateway
- Amazon RDS for PostgreSQL
- Existing CI/CD and consumer integrations
Planning a cloud migration with private networking or staged cutover constraints?
Describe the existing platform, target environment and the risk you need to control.