Case study · Platform engineering
Modernizing a legacy AWX platform.
An AWX deployment that had become difficult to upgrade, audit and operate, rebuilt on an operator-based architecture with configuration held in Git and a rehearsed upgrade path.
- Focus
- Legacy AWX to operator-based architecture
- Platform
- Kubernetes / OpenShift
- Configuration
- Kustomize + GitOps
- Testing
- Molecule and pytest
- Role
- Senior Ansible automation engineer
- AWX Operator
- Kubernetes
- OpenShift
- Kustomize
- GitOps
- Execution Environments
- Private registry
- RBAC
- CI/CD
- Molecule
- pytest
The legacy platform
The platform had been installed years earlier and then changed incrementally through the web interface. It worked day to day, but nobody could reconstruct it: configuration lived only in the running instance, execution environments had been built by hand, and the upgrade path had been deferred long enough that it now looked like a risk rather than maintenance.
- —Configuration existed only in the running instance
- —Execution environments hand-built and drifting between teams
- —Upgrades deferred, so the version gap kept growing
- —Access control accumulated rather than designed
- —No test coverage for platform changes
Constraints
- —The platform had to stay available — teams depended on it daily
- —No loss of job history or existing credentials
- —Cutover had to be reversible
- —Existing job templates had to keep working without per-team rework
Target architecture
AWX Operator
Lifecycle managed by the operator, so upgrades follow a supported path rather than a bespoke procedure.
Declared in Kustomize
Environment differences expressed as overlays over a common base, held in Git.
GitOps reconciliation
The cluster converges on the declared state; drift is visible instead of silent.
Execution Environment pipeline
Images built in CI from declared dependencies and published to a private registry.
RBAC by design
Roles mapped to identity groups, scoped per team and per target.
Configuration as code
Projects, inventories, credentials and templates synchronised from source.
Migration plan and testing
Plan
- —Stand up the operator-based platform alongside the legacy one
- —Reconstruct configuration as code, verifying against the live instance
- —Rebuild execution environments through the image pipeline
- —Run representative job templates on both platforms and compare
- —Cut over per team, with rollback available at each step
- —Decommission the legacy platform once cycles ran clean
Testing
- ✓ Molecule scenarios for roles running on the platform
- ✓ pytest for synchronisation and platform tooling
- ✓ Lint and validation gates in CI
- ✓ Upgrade rehearsed on a non-production platform first
- ✓ Rollback exercised, not documented and hoped for
Results
- —Platform state reconstructable from Git rather than only from the running instance
- —Upgrades became a rehearsed, routine operation
- —Execution environments versioned and reproducible
- —Access control readable and reviewable per team
- —Platform changes covered by tests before they reach production
Related case studies
UN Automation Platform
Multi-team AWX platform serving United Nations organizations.
Read case study →BigFix to Ansible Migration
20,000+ endpoints across 10+ countries moved to Ansible Tower.
Read case study →AI-Enabled Operations
Governed AI integration with scoped tools and human approval.
Read case study →
Is your AWX upgrade the thing nobody wants to schedule?
That is usually a sign the platform is not described anywhere. Rebuilding it as code is what makes the upgrade boring.