How a B2B SaaS Platform Migrated 200 Services to GitOps with Argo CD

A 120-engineer SaaS company replaced ad-hoc kubectl and CI-push deployments with Argo CD GitOps across 200 services, cutting deployment failures by 70% and mean time to recovery from 45 minutes to under 5.

CI/CD & Delivery · intermediate · 12 min read · 2262 words · By Sandip Das · Published 3 November 2026

Composite scenario: built from common industry patterns; the figures are illustrative.

What this covers

The Situation
The Problem
Constraints
Options Considered
The Solution
Implementation
Results
What Went Wrong Along the Way
Lessons Learned
Apply It Yourself

Key numbers

Metric	Before	After
Deployment failure rate	18%	5.4%
Mean time to recovery (MTTR)	45 minutes	4 minutes
Config drift incidents per month	12	0
New service onboarding time	3–5 days	2–4 hours
Platform team deployment toil	~35% of sprint	~8% of sprint

Key components

Argo CD ApplicationSet — Generates one Argo CD Application per service per cluster from a matrix generator, eliminating hand-written Application manifests at scale.
Git config repository — Single source of truth for all Helm values; every production change requires a reviewed and approved pull request, satisfying audit requirements.
Argo Image Updater — Watches ECR for new semver-tagged images and commits the updated tag back to the config repo, keeping CI and CD cleanly separated.
App-of-Apps pattern — A root Argo CD Application that bootstraps all other Applications, giving the platform team a single entry point for cluster state.
Break-glass IAM role — Time-limited, Jira-gated cluster access for emergencies, replacing the permanent cluster-admin keys that existed before the migration.

The Situation

This is a composite scenario built from patterns observed across multiple real-world GitOps migrations; the organisation, team structure, and numbers are illustrative but internally consistent.

The organisation in question is a 120-engineer B2B SaaS company running a multi-tenant analytics platform. Their engineering organisation is split into 14 product squads and a 6-person platform team. The platform team owns three EKS clusters (management, staging, production) running on AWS, with roughly 200 Kubernetes workloads spanning microservices, batch jobs, and internal tooling. The stack includes GitHub for source control, GitHub Actions for CI, Amazon ECR for container images, Helm charts for packaging, and Datadog plus Prometheus/Grafana for observability. At the time of the migration, the platform team was also responsible for a Terraform-managed AWS estate and a handful of RDS PostgreSQL databases.

The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.

Topics: gitops, argo-cd, kubernetes, ci-cd, platform-engineering, deployment

Related case studies

Browse all case studies