When Legacy Infrastructure Becomes a Roadblock
At the hosting provider where we worked, performance bottlenecks and infrastructure limitations had begun to surface.
The entire environment was running on OnApp — rigid provisioning, dated tooling, and restricted flexibility were starting to affect day-to-day operations.
We needed a better path forward.
So, we took ownership of a bold initiative: a complete OpenNebula migration involving more than 2,300 virtual machines — built, automated, and executed entirely by us. And we did it while keeping users online and happy, with average downtimes of just ~20 minutes per VM.
This is the story of how we rebuilt an entire hosting operation from the inside out.
The Challenge: Migrating While Running Production
This wasn’t a side project — it was a full production environment that powered everything the company delivered.
- 90% of VMs were Linux (CentOS, Ubuntu, Debian)
- 10% were Windows (2012 to 2019)
- Critical services included:
- VPN appliances (VyOS, Vyatta, OPNsense)
- Load balancers (HAProxy)
- Database clusters (Percona, MySQL)
- Custom workloads requiring near-zero downtime
And all of it had to be migrated without disrupting the hosting platform or its clients.
Phase 1: Designing the New Cloud with OpenNebula
The first step was to define a robust architecture that would replace the legacy platform and take the company forward.
We deployed a high-performance OpenNebula cluster integrated with StorPool, leveraging the fact that OnApp was already running on StorPool — giving us fast and reliable access to the disks for migration.
We designed:
- Two isolated environments: Public Cloud and Private Cloud
- VXLAN-based segmentation to separate tenants and traffic types
- Dedicated VPNs for secure, hybrid-ready private environments
- A full suite of custom VM templates for provisioning
- A plan to reuse or decommission hardware as hypervisors were freed
Phase 2: Automating the Migration Process
To scale the migration efficiently, we built our own tooling and automations:
- Cloned disks directly from StorPool under OnApp to OpenNebula
- Removed all traces of OnApp agents and legacy settings
- Injected OpenNebula contextualization packages and updated drivers
- Automated IP reassignment into OpenNebula’s VXLAN networks
- Ensured all Linux and Windows VMs were fully compatible after conversion
We turned what could have been a manual, error-prone process into a repeatable, controlled workflow.
Phase 3: Executing the Migration at Scale
With everything prepared, we initiated the phased migration:
- Migrated 10–15 VMs per night
- Maintained an average downtime of ~20 minutes per VM
- Handled even large VMs with 2TB+ disks
- Reformatted and repurposed hypervisors from OnApp into OpenNebula
- Retired old hardware that no longer met performance standards
For high-priority enterprise users with strict uptime requirements, we implemented failover to secondary infrastructure during conversion to maintain 100% service continuity.
Communication and Coordination
Since we were leading the project internally, we coordinated across departments to ensure alignment:
- Developed communication templates for the support team
- Created clear migration schedules and escalation procedures
- Ensured users were informed before, during, and after each migration
- Documented all steps and trained the support team on Tier 1 and 2 tasks
- Acted as the Tier 3 escalation point for technical edge cases
This internal coordination kept everything smooth — both technically and operationally.
The Results: A Fully Modernized Cloud Platform
The OpenNebula migration was a success on every front:
- ✅ 2,300+ VMs migrated successfully
- ✅ Average downtime of ~20 minutes per system
- ✅ Performance improved by 2–3x
- ✅ New Private Cloud environment with tenant isolation
- ✅ Full decommissioning of the OnApp platform
- ✅ No user loss due to migration
- ✅ Legacy hardware usage optimized or retired
- ✅ Hybrid cloud readiness with VPN integration
Users immediately noticed faster systems, improved UI responsiveness, and access to features that didn’t exist before.
Why This Project Led to Nubius Solutions
This wasn’t just another project — this was a defining moment for us.
At the time, Nubius Solutions didn’t exist. My partner led the technical side of the business, while I led operations and strategy.
We had grown together in the company — starting as technicians and evolving into leaders who could take full ownership of critical initiatives like this one.
Through this project, we saw something that stuck with us:
Companies needed this kind of transformation.
But very few had the team to do it right.
And most service providers were either too generic — or too detached — to deliver.
So we made a decision:
Let’s build our own company — one focused on execution, not buzzwords.
That’s how Nubius Solutions was born:
A team built by doers, engineers, and strategists who know what it takes to modernize infrastructure the right way — because we’ve done it from the inside.
Planning an OpenNebula Migration?
If you’re running on OnApp, VMware, Proxmox, or another legacy platform, and looking to modernize with OpenNebula — we can help.
We’ve done the work.
We’ve built the automations.
We know the risks — and how to prevent them.
Let’s help you move forward.
Need expert help for your next infrastructure project?
🔧 See our Custom Projects & Migrations
👉 Talk to us about your OpenNebula migration