Legacy Infra →
Cloud Migration
End-to-end migration from on-prem or legacy cloud infrastructure to a modern, cloud-native Kubernetes environment. Everything as code. GitOps from day one. Zero-downtime cutover.
Migration phases
A migration is only as safe as its plan. I work in clear phases so you know exactly what's happening and why at every step.
Assessment & Roadmap
Before touching anything, I map your current state — every service, dependency, data flow, and pain point. You get a migration roadmap with phases, risks, and timelines before any work begins.
- Full inventory of existing services and dependencies
- Network topology and data flow mapping
- Identify stateful vs stateless workloads
- Risk and complexity scoring per service
- Phased migration plan with milestones
- Cost model for target cloud architecture
Target Architecture Design
I design the target Kubernetes architecture on your chosen cloud provider — node groups, networking, storage, IAM, and multi-environment strategy — before writing a single line of Terraform.
- Cloud provider selection (AWS EKS / GKE / AKS)
- VPC / network architecture design
- Node group strategy (spot, on-demand, GPU)
- Storage class and persistent volume planning
- Multi-environment topology (dev / staging / prod)
- HA and disaster recovery design
Infrastructure as Code
Everything in Terraform. VPC, subnets, EKS cluster, node groups, IAM roles, S3, RDS, load balancers — all reproducible, version-controlled, and documented. No click-ops.
- Modular Terraform for all cloud resources
- Remote state with locking (S3 + DynamoDB)
- Terraform workspaces per environment
- Terragrunt for DRY multi-env configs (optional)
- CI plan/apply pipeline with Atlantis or GitHub Actions
- Full variable documentation
Containerization & Helm Charts
Every service gets containerized with production-grade Dockerfiles and packaged into Helm charts. Resource limits, health probes, HPA, and PodDisruptionBudgets included from day one.
- Multi-stage Dockerfiles (minimal image sizes)
- Helm chart authoring per service
- ConfigMaps / Secrets externalization
- Resource requests and limits tuning
- Horizontal Pod Autoscaler configuration
- Liveness, readiness, and startup probes
GitOps & CI/CD
I set up ArgoCD or FluxCD as the deployment engine — your Git repo is the source of truth, and the cluster self-reconciles. No more manual kubectl apply.
- ArgoCD or FluxCD setup and configuration
- App of Apps pattern for multi-service management
- Environment promotion (dev → staging → prod)
- Rollback strategy with one-click recovery
- CI pipeline migration (GitHub Actions / GitLab CI)
- Build, test, scan, and push automation
Zero-Downtime Cutover
The final migration is the riskiest part. I plan and execute a phased cutover — traffic shifting, DNS TTL management, and a tested rollback path — so your users don't notice a thing.
- Pre-migration checklist and smoke test plan
- Blue-green or canary traffic shifting
- DNS cutover with low TTL strategy
- Database migration and sync validation
- Rollback runbook tested before cutover
- Post-migration monitoring and stabilization
Common questions
How long does a full migration take?
It depends heavily on the number of services and their complexity. A typical startup with 5–15 services can migrate in 4–8 weeks. More complex environments with legacy databases, compliance requirements, or many dependencies take longer. I give a specific estimate after the assessment phase.
What if we have stateful services like databases?
Stateful services need extra care. I typically keep managed databases (RDS, Cloud SQL) outside the cluster and migrate only stateless workloads to Kubernetes. For truly stateful K8s workloads, I use operators (e.g. CloudNativePG, Strimzi for Kafka). We design this together based on your requirements.
Can we migrate one service at a time without downtime?
Yes — this is actually the recommended approach. A strangler-fig pattern lets you migrate incrementally, running old and new infrastructure in parallel with a load balancer routing traffic. It reduces risk significantly versus a big-bang cutover.
What cloud providers do you work with?
AWS EKS is my primary environment (most client work). I've also done GKE and AKS. The Kubernetes layer is largely provider-agnostic, but the surrounding infrastructure (VPC, IAM, storage) is provider-specific. I can work with any of the three major clouds.
What does your team need to know to maintain this after?
I write runbooks for every piece of infrastructure I build. I also do a knowledge transfer session where I walk your team through the architecture, the IaC, and common operational tasks. The goal is that your team owns it confidently when I hand it over.
Ready to leave legacy infra behind?
Book a free 30-minute call. I'll ask about your current setup and give you an honest picture of what a migration would look like.
Book a Free Call