Cloud Migration & FinOps
Cloud Migration & FinOps
Cloud migration projects are rarely just about moving infrastructure from one provider to another. The most impactful migrations also include a FinOps lens: auditing what is actually running, right-sizing what needs to move, and eliminating what should not be carried forward.
What This Work Looks Like in Practice
Discovery and Inventory
Before planning a migration, I query live infrastructure directly – not just code repositories. Source code alone often does not reflect what is actually running: abandoned resources, stale configurations, and over-provisioned services tend to accumulate silently. A live inventory captures actual instance counts, real utilization metrics, volume attachment status, container image sizes, and package counts.
Typical findings from this kind of discovery:
- Compute instances running at 1–6% average CPU utilization
- Unattached storage volumes sitting idle for years, accumulating cost
- Container registries storing images that are no longer referenced by any running workload
- Lambda functions or equivalent serverless resources with zero invocations over a 30–90 day observation window
Cloud-Agnostic Infrastructure Design
A common anti-pattern in long-lived cloud environments is infrastructure code that mixes cloud-provider-specific concerns with workload orchestration. Helm charts and Kubernetes manifests whose purpose is to abstract the underlying cloud end up tightly coupled to AWS-specific services and patterns – making every migration step more difficult than it needs to be.
My approach separates cloud-provider Terraform (for the cluster and foundational networking) from workload configurations (Helm values files, ArgoCD applications, Kubernetes manifests). This separation pays dividends when something forces a change – a CIDR overlap requiring a cluster rebuild, a cloud provider switch, or a cost-driven right-sizing effort.
FinOps: Cost Reduction Through Right-Sizing
Migration is an opportunity to correct over-provisioning decisions that accumulated under the previous architecture. Examples from recent engagements:
| Scope | Before | After | Reduction |
|---|---|---|---|
| Management infrastructure cluster | Heavily over-provisioned | Right-sized node pool | ~80% monthly cost reduction |
| Compute (EC2-equivalent workloads) | Multiple underutilized instances | GCP equivalent, right-sized | ~35% monthly reduction |
| Storage (object + block) | Legacy provisioning | Matched to actual usage | ~31% monthly reduction |
| VPN infrastructure | Dedicated EC2 instance (8 GB RAM) | Lightweight Kubernetes operator | Eliminated dedicated instance cost |
Kubernetes and GitOps Migrations
Migrating Kubernetes workloads across clusters or cloud providers involves more than re-applying manifests. Key areas that require deliberate attention:
ArgoCD / GitOps topology – A centralized ArgoCD instance managing clusters over the network carries cross-VPC networking requirements. A locality-based approach (ArgoCD runs in the same cluster and VPC it manages) eliminates this complexity and simplifies certificate and authentication configuration.
VPN and network access – Replacing a legacy OpenVPN EC2 instance with the Tailscale Kubernetes Operator reduces operational overhead, eliminates dedicated compute cost, and provides per-user access controls via standard identity providers (Google Workspace, OIDC, JumpCloud, etc.).
ApplicationSet-based deployment pipelines – Replacing custom scripts or Jenkins jobs that generate and apply ArgoCD Application manifests with native ArgoCD ApplicationSets removes Jenkins as a hard dependency for application deployment.
TLS and DNS automation – cert-manager with Let’s Encrypt and external-dns with Route53 provide fully automated certificate issuance and DNS record management across clusters.
Identifying Work That Should Not Be Migrated
A well-scoped migration includes explicit recommendations for what not to carry forward:
- Serverless functions with zero usage over a meaningful observation period are candidates for deletion, not migration
- Legacy VPN infrastructure that has been replaced operationally can be decommissioned rather than reprovisioned
- Package repository caches that are 99%+ public packages may be better served by pulling from upstream registries directly
Services Offered
- Pre-migration AWS and GCP infrastructure inventory and assessment
- AWS-to-GCP (and GCP-to-AWS) resource mapping with cost modeling
- Kubernetes cluster migrations (EKS to GKE, and reverse)
- ArgoCD and GitOps pipeline modernization
- FinOps auditing: utilization analysis, right-sizing recommendations, waste identification
- Cloud-agnostic Helm and IaC refactoring
- VPN modernization (Tailscale Kubernetes Operator deployment)
- DNS, TLS, and certificate automation
All services available on a contract basis. Contact me to discuss your situation.