01 · The migration
UPI: physical data centre → AWS, with zero downtime
12 weeks · 50+ microservices · 160M+ transactions/day · Paytm Payments Bank
The entire UPI stack at PPBL (Paytm Payments Bank) had to move from on-premises data centres to AWS. I owned the architecture and the cutover: networking, security, data synchronisation, deployment orchestration and compliance certification (PCI-DSS, ISO 27001, SOC 2) — with no acceptable customer impact at any point.
Technical constraints
- Entire UPI stack running on legacy on-prem infrastructure.
- Complex networking: VPC, subnets, peering, NAT/IGW, PrivateLink and DirectConnect for NPCI and bank connectivity.
- Large-scale data migration with strict consistency requirements.
- Multi-service dependencies and tight coupling between services.
Business requirements
- Zero downtime tolerance for UPI transactions.
- Strict regulatory compliance and audit requirements.
- Minimal customer impact throughout the migration.
- Rollback capability at every phase.
- Obsolete tooling replaced with modern, supported alternatives.
- Architecture designed for maximum automation, minimum manual intervention.
The plan, phase by phase — and what could have gone wrong
01 · Weeks 1–3
Foundation
- AWS account setup following landing-zone best practices.
- VPC design: multi-AZ architecture with public/private subnets.
- Network connectivity: VPN, Direct Connect, peering configurations.
- Security groups, NACLs, and IAM roles/policies.
- EKS cluster provisioning with Istio service mesh.
02 · Weeks 4–6
Data migration
- Database replication setup (Aerospike and others).
- Kafka topic migration and consumer-group synchronisation.
- S3 buckets with lifecycle policies.
- Data validation and consistency checks.
- Performance baselines established.
03 · Weeks 7–10
Application deployment
- Containerisation of all UPI microservices.
- Helm charts and GitOps setup with Argo CD.
- Blue/green deployment preparation.
- Service mesh configuration (Istio routing rules).
- Observability stack deployment (Prometheus, Grafana).
04 · Weeks 11–12
Cutover & validation
- Progressive traffic shift using Argo Rollouts canaries, gated on automated metric analysis.
- Real-time monitoring of latency, error rates and throughput.
- DR runbook execution and failover testing against the automated path.
- Final cutover during a low-traffic window.
- Post-migration optimisation and tuning.
Risks & mitigations
- Data inconsistency during replication
- Dual-write pattern with reconciliation jobs; automated consistency checks before cutover.
- Network latency increase
- Direct Connect for low-latency connectivity; performance benchmarking at each phase.
- Service dependency failure
- Circuit breakers, retries with exponential backoff, and comprehensive monitoring dashboards.
- Security compliance gaps
- IRSA for pod-level IAM, encryption at rest and in transit, audit logging, CIS benchmarks.
- Rollback complexity
- Automated rollback scripts and fine-grained traffic shifting with Argo Rollouts, rehearsed in drills — with the decision to revert driven by an automated metric comparison rather than a human call mid-incident.
Outcome
100%
Services migrated, zero downtime
-30%
P95 latency
+200%
Autoscaling efficiency
12 wks
End to end
- Migrated 100% of UPI services with no customer-facing incidents.
- Established GitOps with Argo CD for declarative infrastructure.
- Regulatory compliance with full audit trails and security controls.
- Infrastructure cost reduced through right-sizing and resource efficiency.
- Comprehensive observability with SLO/SLA dashboards and alerting.