Enabling GitOps at Scale at Adobe with Argo
Executive Summary
Adobe modernized software delivery by moving from its legacy internal platform, Moonbeam (CaaS), to Flex, a GitOps-based delivery platform built on Kubernetes and the Argo Project ecosystem. The shift replaced a legacy model that had become increasingly difficult to scale, secure, and operate reliably in an enterprise environment.
This was a large-scale effort, touching 10,400 pipelines across hundreds of teams. What makes Flex notable from a CNCF perspective is not only the scale of adoption, but the way multiple CNCF technologies were operationalized together to support governed software delivery at enterprise scale.
We migrated the majority of active services to a modern GitOps platform built on Kubernetes and the Argo project ecosystem. At Adobe, that meant more than adopting Argo for deployment automation: we operationalized Argo CD, Argo Workflows, and related technologies within a governed delivery platform that integrates onboarding, service registration, secrets management, change workflows, and deployment controls for secure self-service at scale. The migration also helped us retire thousands of stale or duplicate services, improving platform hygiene and reducing operational burden. The result is an enterprise delivery platform built around Argo-based GitOps in production.
Adobe’s Flex platform stands out not just for adopting Argo, but for operationalizing multiple CNCF technologies together as a cohesive enterprise software delivery system. Kubernetes provides the platform foundation. Argo CD enables continuous reconciliation and Git-based delivery. Argo Workflows powers workflow orchestration across CI and CD pipelines. Beyond pipeline execution, it also supports long-running automation for migration workflows and platform operations. Argo Events supports event-driven automation across delivery workflows, and Argo Rollouts enables progressive delivery patterns for safer production change management.
Together, these projects form a GitOps operating model that combines declarative delivery with governance, auditability, and self-service. At Adobe, they are not used as isolated tools, but as integrated building blocks within a governed delivery platform that also incorporates onboarding, service registration, secrets management, change workflows, and deployment guardrails. The result is a large-scale enterprise delivery platform built around Argo-based GitOps in production.
Today, Flex powers service deployment at substantial enterprise scale, managing over 6,000 services across nearly 50,000 environments, including nearly 19,000 production environments supporting more than 3,300 production services. Beyond service deployment, the platform also supports a broader range of operational and platform workflows.
Projects used
By the numbers
10,400
pipelines migrated or deleted
100+
engineering teams involved
3,000+
developers operating on the platform
The challenge
Flex CI & CD transformed software delivery at Adobe by making GitOps the foundation of how teams deploy and manage applications. We established Git as the source of truth, adopted declarative infrastructure and application definitions, and used automated reconciliation to continuously align running environments with approved state in source control. In doing so, we reduced manual intervention, prevented configuration drift, and moved teams away from fragile, queue-based deployment workflows.
This shift eliminated persistent deployment pain points while improving security, compliance, and artifact verification. It also gave teams real-time visibility, faster rollback paths, and end-to-end auditability through GitOps-native controls. The result was a faster, more predictable, and more reliable deployment experience for engineering teams, alongside stronger security posture and meaningful cost savings for the organization.
In 2H 2024, we launched a focused effort to retire Moonbeam. We began with a clear migration plan, strong upfront documentation, and deliberate execution. But as with any enterprise-scale transformation, the real lessons emerged once execution began. The hurdles we encountered along the way became valuable inputs into how we will approach future platform migrations & upgrades at Adobe.
Solution: Implementation and migration approach
Build the Tooling First
Our biggest lesson and biggest regret was migration tooling. Although we started with standalone automation scripts, too much of the migration burden still fell on early adopters. Teams had to work through significant manual effort, and the overall experience lacked the end-to-end cohesion needed for a migration program at this scale. We created real friction for our customers, and we own that.
The feedback made it clear that scripts alone were not sufficient. Teams needed a structured, self-service migration workflow with clear lifecycle controls. In response, we built a Node.js- and React-based migration interface backed by workflow-driven automation. We introduced explicit start, pause, continue, and end controls, used Argo Workflows to orchestrate long-running migration steps, implemented state management to support reliable resumption across stages, and added reporting, tracking, and notifications to improve transparency for both service owners and platform operators. This was an important lesson in operationalizing CNCF projects at enterprise scale: adopting the technology was only part of the challenge; building the workflow experience and governance model around it was what made large-scale migration practical. This mattered not only for efficiency, but for scale: migration at Adobe’s footprint required workflow orchestration that could reliably coordinate thousands of changes across hundreds of teams.
The impact was significant: migration time dropped, errors decreased, and the process became far more repeatable and scalable. The lesson for us was clear: in any large-scale migration, invest in end-to-end automation from the beginning. We should have done that from day one.
Value Over Mandates
We initially relied too heavily on CaaS end-of-life timelines and migration mandates to drive adoption. While that created urgency, it did not build lasting trust. We learned that mandates alone are not an effective adoption strategy, especially when they are not paired with a clear and compelling value proposition.
What ultimately motivated teams to migrate was the value Flex delivered through GitOps: declarative delivery, Git-based change control, automated reconciliation, and a more predictable and auditable path to production. These benefits improved both onboarding and day-to-day operations. Automated service registration, deployment scaffolding, secrets integration, and change workflows reduced onboarding time, while continuously reconciled deployment workflows improved speed, rollback agility, and operational consistency.
In the end, our most effective conversations were not about deadlines, but about helping teams solve real engineering pain. The strongest adoption driver was not mandate, but the measurable gains GitOps and the supporting CNCF technologies delivered in speed, reliability, security, and developer experience. For developers, that translated into faster onboarding, more predictable delivery, stronger auditability, and less operational friction. Looking back, the mandate created urgency, but value should have led from the start.
The Hidden Value of Platform Hygiene
One unexpected benefit of the migration was the opportunity to identify and retire stale, abandoned, and unused services. Through systematic engagement with teams, we uncovered thousands of services and pipelines that were no longer needed, had been forgotten, or had simply been duplicated over time. We ultimately removed roughly 80% of previously identified services, and that cleanup alone contributed meaningfully to cost savings.
This kind of buildup is common in large enterprises. Teams move quickly to prototype, experiment, and demo ideas, but not every effort becomes a long-lived product capability. Over time, dormant services and orphaned pipelines accumulate especially when legacy platforms lack strong lifecycle-management and cleanup mechanisms.
The migration gave us a forcing function to review inventory, separate active workloads from abandoned ones, and safely decommission what no longer provided value. That made the effort more than a platform upgrade; it became an opportunity to reduce technical debt, improve platform hygiene, and optimize resource utilization at scale. It also reinforced an important platform lesson: large-scale GitOps adoption is not just about deploying with modern tooling, but also about creating the lifecycle controls needed to keep platform inventory healthy over time.
Impact: Partner with Your Customers
This migration required exceptional responsiveness and genuine partnership with demanding customers. We learned that success was not just about technology, but about trust especially when teams had already felt the pain of migration. In large-scale platform change, relationships and credibility matter as much as architecture.
That trust matters even more in a world where the bottleneck to generating code is shrinking, but the need for confidence in shipping software is rising. Software supply chains are becoming a critical differentiator, and modern platforms must provide not just automation, but also governance, provenance, auditability, policy controls, and operational consistency.
Our platform and SRE teams worked closely with customer engineering teams and cross-functional partners to understand requirements, address concerns, and evolve the approach in real time. Together, we used the migration to build a stronger foundation on Kubernetes, GitOps, Argo-based workflows, and enterprise controls.
In the end, that partnership turned what could have been a forced migration into a shared transformation and positioned Adobe for a future where software supply chains increasingly define speed, safety, and delivery success.
Taken together, these outcomes reflect not just a successful modernization effort, but one of the larger publicly described enterprise uses of Argo-based GitOps as an operating model for software delivery.
Measurable outcomes
- 10,400 pipelines either migrated or decommissioned
- Substantial infrastructure cost savings
- Hundreds of teams transitioned to GitOps workflows
- Significant reduction in deployment queue times
- Improved security posture across all migrated services
- GitOps practices are now standard across Adobe’s deployment infrastructure, supporting 3,000+ developers and 3,000+ production services.
What’s next
Unified CI & CD
Building on the new platform and the lessons from that journey, we are now taking on the next challenge: unifying CI and CD, starting with CI. While containers were our first major focus area, Unified CI is being designed as a common platform for a much wider range of workloads, including libraries, packages, functions, desktop, mobile, containers, MCPs, agents, and more.
The goal is simple: make CI dramatically easier for developers. Instead of expecting teams to piece together workflows from low-level tooling, the platform should provide secure defaults, reusable patterns, automated provisioning, and best practices by default, while pushing underlying complexity into the background.
Unified CI also enables important new capabilities, including remote caching, stronger dependency management for multi-repo development, and cross-repo CI to validate changes across service boundaries before merge. With Bazel as a key part of this evolution, we are building a stronger foundation for reproducible builds, scalable caching, and faster engineering iteration.
For teams, that means a faster path from zero to staging with minimal setup and immediate value. And unlike our earlier transition, we want this to feel like an upgrade, not a migration: incremental, guided, and clearly value-driven from the start. That means investing early in upgrade tooling, leading with concrete technical benefits, and partnering closely with early adopters to shape the experience.
Conclusion
More broadly, this journey showed that CNCF technologies can do far more than support isolated platform use cases. When Kubernetes, Argo CD, Argo Workflows, Argo Events, and Argo Rollouts are operationalized together with the right platform controls, they can form the backbone of a governed internal developer platform for software delivery at enterprise scale.
As we celebrate the milestone and begin our journey towards Unifying CI & CD, we’re just getting started. There’s a long way to go, but we know what to focus on: investing in tooling from day one, demonstrating concrete value through capabilities like remote caching, cross-repo CI, and automated dependency management, and building genuine partnerships rather than mandating change.
To everyone who contributed to this multi-year effort: the platform engineers who built Flex, the automation teams who created the migration tooling, the customer engagement teams, and our partners who trusted us with their critical services, thank you. As we move forward with Unified CI & CD, we’re building on this foundation with commitment to delivering real value that solves actual problems.