Cloud Migration Checklist for Growing Teams
Moving from on-premise servers or a single VPS to AWS does not have to mean a weekend outage and a surprise ₹2 lakh bill. This checklist is what we run before every migration for Bangalore teams outgrowing their first infrastructure.
Cloud migration is less about lifting servers and more about deciding what your team is willing to operate afterward. We have migrated Laravel monoliths from Chennai co-location facilities, containerised Node.js apps off DigitalOcean droplets, and helped Series B startups tame AWS bills that doubled after Diwali traffic — the pattern is always the same: discovery saves you, cutover planning saves you again.
Before you migrate: discovery essentials
Start with a complete inventory: every server, cron job, background worker, database, file store, DNS record, SSL certificate, and third-party integration. Use automated discovery tools (AWS Application Discovery Service, manual scripts) but verify with the engineers who built the system — tribal knowledge catches what scanners miss.
Map dependencies as a directed graph. Your checkout flow might depend on Redis, a PostgreSQL primary, an S3-compatible object store, and a Celery worker that emails via SES. Migrating the web servers without the workers produces silent failures that are harder to debug than a hard outage.
Define RPO (Recovery Point Objective) and RTO (Recovery Time Objective) per service tier. Payment processing might need RPO of zero and RTO under 15 minutes; internal admin tools might tolerate four hours. These numbers drive architecture decisions and budget — zero-RPO requires synchronous replication, which costs more.
- Server and service inventory with owners
- Dependency graph between applications and data stores
- RPO/RTO targets per service tier
- Data residency requirements (India region, DPDP compliance)
- Traffic patterns: daily peaks, seasonal spikes (Diwali, IPL, financial year-end)
- Secrets audit: API keys, database passwords, certificate locations
- Current monthly infrastructure cost as baseline
Choosing your cloud target architecture
Not every app needs Kubernetes on day one. The migration spectrum runs from "move VMs to EC2" (fastest, least benefit) to "replatform on managed services" (RDS instead of self-managed Postgres, ElastiCache instead of self-hosted Redis) to "refactor into containers/microservices" (most effort, most flexibility).
For most Bangalore growth-stage teams (10–50 engineers), we recommend managed services on AWS ap-south-1 (Mumbai) or Azure Central India: ECS Fargate or Elastic Beanstalk for apps, RDS for databases, S3 for files, CloudFront for static assets. Kubernetes (EKS) earns its complexity above ~50 microservices or when you need portable workloads across clouds.
Cost estimate before migration: use AWS Pricing Calculator with realistic instance sizes. A common mistake is over-provisioning "just in case" — start with rightsized instances and autoscaling policies based on actual traffic data, not peak × 3.
Data migration without tears
Database migration is the highest-risk phase. For PostgreSQL and MySQL, use logical replication or AWS DMS (Database Migration Service) to sync data continuously while the old system remains live. Verify row counts, checksums, and application-level consistency — not just "replication lag is zero."
File storage migration (local disks → S3) should use parallel upload tools (aws s3 sync, rclone) during a maintenance window or with dual-write logic if zero downtime is required. Update application config to read from S3 only after verifying all files transferred and checksums match.
Plan for rollback at every stage. Snapshot the source database before cutover. Keep the old environment running (but isolated) for 48–72 hours post-migration. DNS TTL reduction to 60 seconds, starting 24 hours before cutover, makes rollback a DNS flip rather than a panic.
- Full database backup with verified restore test
- Replication setup with lag monitoring alerts
- Row-count and checksum validation scripts
- File migration with integrity verification
- DNS TTL lowered 24 hours before cutover
- Rollback runbook tested in staging
Cutover: phased traffic shifting
Never do a big-bang cutover on a Friday evening — or the night before a sale. Schedule migrations during low-traffic windows with the full team available for 48 hours post-cutover. For Indian e-commerce, Tuesday–Wednesday 2–6 AM IST is often the quietest slot outside of sale seasons.
Use phased traffic shifting: 5% → 25% → 50% → 100% over hours or days, monitoring error rates, latency percentiles, and business metrics (orders, signups) at each step. AWS ALB weighted target groups or Cloudflare load balancing make this straightforward.
Run synthetic monitoring and real-user monitoring in parallel on old and new environments during the shift. Tools like Checkly, Datadog Synthetics, or a simple cron hitting critical endpoints every minute catch regressions before users report them.
Observability and security from day one
If you cannot see it, you cannot fix it at 3 AM. Minimum viable observability stack: structured application logs (CloudWatch or a log aggregator), metrics (CPU, memory, request rate, error rate, p95 latency), distributed tracing for request flows, and alerting with escalation policies.
Security baselines: VPC with private subnets for databases, security groups with least-privilege rules, IAM roles instead of long-lived access keys, secrets in AWS Secrets Manager or Parameter Store, WAF on public endpoints, and automated SSL via ACM. Enable CloudTrail and VPC Flow Logs from launch — retrofitting audit trails after an incident is too late.
Indian compliance note: if you handle personal data, ensure your cloud region choice aligns with DPDP Act data residency expectations. ap-south-1 keeps data in India; us-east-1 does not. Document your data flow diagram for legal review.
Post-migration: the first 60 days
Week 1: war-room monitoring. Daily standups reviewing error rates, latency, cost, and user-reported issues. Freeze non-critical deployments. Keep the rollback environment warm.
Weeks 2–4: optimise. Rightsize instances based on actual utilisation data. Enable autoscaling policies tuned to your traffic curves. Identify and delete orphaned resources from the migration (old snapshots, unused EIPs, test instances).
Weeks 5–8: stabilise and document. Update runbooks, on-call playbooks, and architecture diagrams. Conduct a blameless postmortem documenting what went well and what to improve. Decommission the old environment only after a full billing cycle confirms the new setup is stable and cost-predictable.
Schedule monthly FinOps reviews. Cloud costs creep through unused resources, over-provisioned databases, and data transfer patterns that nobody watches after launch. A quarterly architecture review keeps infrastructure aligned with product growth.
Key takeaways
- Complete discovery — inventory, dependencies, RPO/RTO — before touching any production system.
- Managed services (RDS, ECS Fargate, S3) beat self-managed infra for most growth-stage Indian teams.
- Database migration with replication and verified rollback is the highest-risk phase — plan it meticulously.
- Phased traffic shifting with synthetic monitoring beats big-bang cutover every time.
- Set billing alerts and FinOps reviews from day one — cloud costs creep silently.
Want help implementing this?
We work with founders and teams across Bangalore and globally — from scoping and architecture to launch and growth. Start with a free consultation; we will respond within two business days with an honest read on fit, timeline, and budget.