Case study · Banking
BigFix to Ansible: an enterprise-wide endpoint migration.
Endpoint management and compliance automation moved from IBM BigFix to Ansible Tower across a multi-country European banking estate — more than 20,000 Windows and Linux endpoints in over ten countries.
- Sector
- European banking group
- Scope
- 20,000+ endpoints · 10+ countries
- Duration
- 2017–2024
- Delivered with
- VTS — Services of UniCredit, later Kyndryl
- Platforms
- Windows and Linux
- Ansible Tower
- IBM BigFix
- ServiceNow
- Splunk
- CyberArk
- OpenShift
- Windows
- Linux
- Python
Migration context
The bank ran endpoint management on IBM BigFix: patching, software distribution, configuration baselines and compliance reporting for a Windows and Linux estate spread across more than ten countries. It worked, but it had become a silo — an operating model separate from the automation the rest of the organization was standardising on, with compliance evidence that had to be assembled by hand.
The objective was not a like-for-like replacement. It was to bring endpoint operations into the same Ansible-based automation platform used elsewhere, so that endpoint work, infrastructure work and compliance evidence lived under one model.
Role. Endpoint automation and security engineer at VTS — Services of UniCredit (2017–2021), then senior Ansible automation engineer at Kyndryl (2021–2024): migration planning, automation development and delivery leadership. The bank was the environment served, not the employer.
The legacy environment
How it worked
- —A BigFix root server with regional relays distributing content
- —Fixlets, tasks and baselines maintained per platform and region
- —Operator-driven compliance runs, scheduled and supervised
- —Reporting exported and consolidated manually for audit
Where it hurt
- —Compliance execution took 2–5 hours per cycle
- —Content was hard to version, review or test
- —Endpoint automation could not be reused elsewhere
- —Evidence for auditors required manual assembly
- —Platform expertise concentrated in very few people
Migration strategy
A phased migration, country by country and platform by platform, with both systems running in parallel until each scope was proven. Nothing was switched off before its Ansible equivalent had produced identical results on the same hosts.
1 · Inventory and mapping
Catalogue every BigFix fixlet, baseline and task in use, and map each to a target Ansible role — discarding what had stopped being used.
2 · Role development
Build tested Ansible roles for patching, configuration baselines, software distribution and compliance checks, for both Windows and Linux.
3 · Parallel validation
Run both systems against the same hosts and compare results until output matched, per platform and per country.
4 · Phased cutover
Move scope by scope, with a documented rollback to BigFix at every step.
5 · Decommission
Retire BigFix content only once its replacement had operated cleanly through full cycles.
Architecture, before and after
Validation and operational visibility
Validation
- ✓ Idempotency verified — repeat runs produce no changes
- ✓ Results compared against BigFix on identical hosts
- ✓ Pilot groups per country before wider rollout
- ✓ Rollback rehearsed, not assumed
- ✓ Windows and Linux validated separately
Integrations and visibility
- ✓ CyberArk for privileged credentials — none stored in playbooks
- ✓ CMDB as the inventory source of truth
- ✓ ServiceNow change records raised from automation
- ✓ Splunk for job output and compliance evidence
- ✓ OpenShift and networking systems integrated where in scope
Results
- Compliance execution
- 2–5h → 10–15m
- Endpoints migrated
- 20,000+
- Countries in scope
- 10+
- Credentials in source
- none
Beyond execution time, the durable outcome was operational: endpoint automation became versioned, reviewable and testable content that the wider platform team could read and maintain — and compliance evidence became a by-product of running the automation rather than a separate exercise before an audit.
Lessons learned
- —Map what is actually in use before migrating. A significant share of legacy content had quietly stopped mattering.
- —Parallel running is not optional at this scale. Comparable output on identical hosts is the only credible proof.
- —Idempotency is the migration acceptance criterion, not a nice-to-have.
- —Windows endpoint automation deserves its own validation path — assumptions from Linux do not transfer.
- —Credential handling has to be solved before rollout, not retrofitted after it.
- —A rollback nobody has rehearsed is not a rollback.
Related case studies
UN Automation Platform
Multi-team AWX platform on Kubernetes across United Nations organizations.
Read case study →AWX Platform Modernization
Legacy AWX rebuilt on the operator with GitOps configuration-as-code.
Read case study →Real-Time Compliance Monitoring
Continuous compliance visibility for operations teams.
Write-up in progress
Facing a migration like this one?
Bring the estate and the constraints. The first useful step is usually establishing what is genuinely still in use.