Migration from legacy automation tools to modern platforms is one of the most challenging undertakings in enterprise IT. Having led the transition of over 20,000 endpoints from IBM BigFix to Ansible at a major European bank, I have learned that success depends less on technical prowess and more on methodical execution and organizational alignment.
This article shares practical lessons from that experience, applicable to organizations considering similar migrations regardless of the specific tools involved.
Why Organizations Migrate
Before discussing how to migrate, it is worth examining why organizations undertake these challenging projects. In my experience, the drivers fall into several categories:
- Performance limitations: Legacy tools may struggle with scale, resulting in long execution times that delay security patching and compliance operations.
- Integration requirements: Modern DevOps practices require automation tools that integrate with CI/CD pipelines, container platforms, and cloud APIs. Older tools often lack these capabilities.
- Talent availability: Finding engineers experienced with legacy tools becomes increasingly difficult as the industry moves toward newer platforms.
- Licensing costs: Commercial automation platforms can represent significant ongoing costs that open-source alternatives may reduce.
In our case, all four factors applied. BigFix was performing adequately for basic tasks, but complex operations took hours where minutes would be acceptable. The bank was adopting containerization and needed automation that could operate in those environments. And the team wanted to invest in skills that would serve them long-term.
The Assessment Phase
Every successful migration begins with thorough assessment. This is not merely a technical inventory; it is an understanding of how automation fits into organizational operations and what dependencies exist.
Inventory Your Automation
Document everything your current platform does. In our BigFix environment, this meant cataloging every Fixlet, action script, and scheduled task. For each item, we recorded:
- What the automation accomplishes
- How frequently it runs
- What systems it affects
- Who owns and maintains it
- What dependencies it has on other systems
This inventory revealed automation we did not know existed, created by teams years ago and still running. Some of it was critical; some was obsolete. You cannot migrate what you do not know about.
Categorize by Complexity
Not all automation is equal. We categorized our inventory into tiers:
- Simple: Basic operations like file deployment, service management, or package installation. These translate directly to Ansible equivalents.
- Moderate: Operations with conditional logic, multiple steps, or integration with other systems. These require careful design but are straightforward to implement.
- Complex: Operations with intricate dependencies, custom code, or unique requirements. These need individual attention and often benefit from redesign rather than direct translation.
This categorization informed our migration sequence. Starting with simple automations built momentum and confidence while the team developed Ansible expertise.
Architecture Decisions
Migration is an opportunity to improve, not just replicate. We made several architectural decisions that shaped the new platform:
Centralized vs. Distributed
BigFix uses a relay architecture with agents on every endpoint. Ansible operates differently, typically running from central controllers. We chose Ansible Tower (now AWX) for enterprise features including role-based access, audit logging, and credential management.
This architectural difference means migration is not just about translating scripts; it is about rethinking how automation reaches endpoints. SSH access, privilege escalation, and network segmentation all require attention.
Credential Management
Legacy systems often have credentials embedded in scripts or stored locally. Modern security requirements demand centralized credential management. We integrated with CyberArk from day one, ensuring no credentials would exist in our playbooks or repositories.
Change Management Integration
In a regulated banking environment, automation must integrate with change management processes. We designed ServiceNow integration so that significant automations could be approved through standard change workflows, and all executions would be tracked.
The Migration Strategy
Our migration followed a progressive approach across multiple phases:
Phase 1: Parallel Operation
We built equivalent Ansible playbooks for our simple automations and ran them alongside BigFix. Outputs were compared to validate correctness. This parallel period lasted several months, allowing us to identify discrepancies and build confidence.
Phase 2: Progressive Cutover
Country by country, we migrated operations from BigFix to Ansible. Starting with smaller operations in Poland and Czech Republic before tackling the Italian environment where most endpoints resided.
Each cutover followed a pattern:
- Enable Ansible for a subset of endpoints
- Run parallel operations for one week
- Disable BigFix operations for validated endpoints
- Expand to remaining endpoints in that country
Phase 3: Decommissioning
Only after confirming stable Ansible operations did we begin removing BigFix infrastructure. This happened gradually, ensuring we had validated coverage before eliminating the safety net.
Key Lessons Learned
Invest in Training
Technical migration is only half the challenge. Your team needs to develop proficiency with new tools. We invested significantly in training, both formal courses and hands-on practice. This investment paid dividends in adoption and quality.
Document Everything
Migration is an opportunity to establish good documentation practices. Every playbook we created included purpose statements, dependency notes, and operational procedures. This documentation became valuable long after the migration completed.
Plan for the Unknown
Despite thorough assessment, we discovered automations during migration that were not in our inventory. Build slack into your timeline for these discoveries. They will happen.
Celebrate Progress
Multi-year migrations are exhausting. Recognizing milestones keeps the team motivated. When we completed Italy, the largest country in our scope, we took time to acknowledge the achievement before pressing forward.
Results
The migration delivered substantial improvements:
- 95% reduction in execution time: Operations that took hours in BigFix completed in minutes with Ansible.
- Improved security posture: Faster patching meant vulnerabilities were remediated more quickly.
- Better auditability: Tower provided comprehensive logging that satisfied regulatory requirements.
- Team capability: The team emerged with valuable skills applicable to modern infrastructure.
The project earned consecutive customer recognition awards and positioned the organization for future automation initiatives.
Conclusion
Migrating legacy automation is challenging but achievable with proper planning and execution. The key is treating migration as an organizational change project, not just a technical exercise. Invest in assessment, build incrementally, and maintain focus on business outcomes rather than just technology replacement.
If you are considering a similar migration, I am available to discuss your specific situation. Sometimes an outside perspective, informed by experience with these transitions, can help clarify the path forward.