CloudStack migration to Cozystack — the modernization path for established service providers

Apache CloudStack remains established with service providers in several EU, MENA, and APAC markets. It has a mature multi-tenancy model, broad community support, and well-understood operational patterns. So why are operators evaluating modernization in 2026?

Three pressures stand out:

1. Engineer scarcity — CloudStack expertise pool is smaller than it was, and newer engineers are trained on Kubernetes, not on CloudStack’s component model.
2. Service-catalog ceiling — CloudStack’s primary scope is VMs, networks, and storage. Managed databases, S3-compatible object storage, container-native workloads, and GPU-as-a-service either bolt on awkwardly or live outside the platform entirely.
3. Kubernetes-native customer demand — customers increasingly want tenant Kubernetes clusters, container workloads, and Kubernetes-native networking. CloudStack handles this via integration; Cozystack handles it natively.

Where CloudStack still wins

Before discussing modernization, let’s be honest about where CloudStack remains the right answer:

• Established expertise + stable customer base — operators with deep CloudStack ops experience and stable customer count where migration cost might exceed the value of modernisation
• VMware-on-CloudStack deployments — where CloudStack is the orchestration layer over an existing VMware estate, the modernisation question is “do we leave VMware?” first, then “do we change the orchestrator?” second
• Specific CloudStack features without direct Kubernetes equivalents — deep network configuration patterns, specific load-balancer integrations, regional procurement-tied features

Where modernization fits is somewhere else: providers with growing customer demand for Kubernetes-native services, providers facing operational complexity that compounds with team turnover, providers launching managed databases / S3 / GPU services that don’t fit CloudStack natively.

Architectural mapping: CloudStack → Cozystack

Two areas need substantial redesign rather than 1:1 mapping: networking (Cilium’s eBPF model is fundamentally different from CloudStack’s L2/L3 virtual router) and service catalog (CloudStack service offerings vs Cozystack package + ApplicationDefinition).

Migration phases

Phase 0 — Assessment (3-6 weeks)

Workload inventory: VM count, OS mix, vCPU/RAM/disk profiles, criticality tier. Network inventory: VPC count, public IP allocation, load-balancer configurations, security-group rules. Storage inventory: primary/secondary capacity, snapshot retention, volume types. Multi-tenancy inventory: account count, domain hierarchy, project structure.

Customer-facing inventory: ARPU per customer, service consumption, contractual obligations, SLA tiers, billing integration touchpoints.

Output: a migration plan with workload buckets (migrate-now / migrate-later / stay / re-architect), risk flags, timing.

Phase 1 — Cozystack foundation (2-4 months)

Hardware procurement (or repurpose). Cozystack platform deployed on new infrastructure alongside the existing CloudStack estate. Cilium networking validated. LINSTOR storage operationalised. Identity integration (Keycloak or whatever IdP the provider operates).

Tenant CRD model designed to map cleanly from CloudStack’s account / domain hierarchy — typically each top-level CloudStack account becomes a Cozystack Tenant; nested CloudStack domains become nested Tenants.

End state: working Cozystack platform, internal validation complete, not yet customer-facing.

Phase 2 — Service catalog and customer-facing portal (2-4 months)

Cozystack Dashboard customisation to match the provider’s brand. WHMCS integration if the provider uses WHMCS (most CloudStack-on-WHMCS providers do). Service-catalog rollout — start with foundational services (VMs, volumes, S3 buckets, basic networking), layer in managed services that didn’t exist in the CloudStack era.

Phase 3 — VM migration (3-9 months)

Workload migration in cohorts of 50-200 customers at a time. Per cohort:

1. Image conversion — CloudStack templates and customer images converted to KubeVirt-compatible format. Most CloudStack KVM images convert with qemu-img conversion + minor metadata adjustment. Customer Windows VMs get virtio driver injection (standard pattern).
2. Network mapping — VLAN-to-Cilium policy translation, security group rules to NetworkPolicies, VPC routing to ClusterPool + Cilium L3.
3. Storage migration — volume data migrated from CloudStack primary storage to LINSTOR. Snapshot history preserved or pruned per retention policy.
4. Cutover — workload runs in parallel on Cozystack for a validation window (typically 7-14 days). Customer notified of cutover; final cutover during scheduled window.

Phase 4 — CloudStack decommission (2-6 months)

Hardware repurposed into Cozystack cluster as migration cohorts complete. CloudStack management server retired. Operational tooling (monitoring, ticketing integrations) consolidated to the Cozystack stack.

Where CloudStack-to-Cozystack migrations stumble

1. Network model translation

CloudStack’s network model has historically been more configurable than most cloud-orchestration platforms — Advanced networking, Basic networking, Isolated networks, VPC, public IPs, hairpin routing, elaborate security group configurations. Translating all of this to Cilium + MetalLB + standard Kubernetes NetworkPolicies requires careful architecture work. Skipping this in Phase 0-1 produces production incidents in Phase 3.

2. Customer billing integration

CloudStack’s billing hooks differ from Cozystack’s. Providers running WHMCS-integrated CloudStack billing usually need WHMCS-integration work on the Cozystack side — Ænix provides this as part of the engagement but it’s specific per provider.

3. Customer self-service-API divergence

CloudStack offers a comprehensive customer-facing API (cmdkit / SDK). Customers who built tooling against the CloudStack API need a migration path: either CloudStack-API-compatible shim on Cozystack (possible for a subset of operations), or customer-facing API migration to Cozystack-native patterns. Plan for this.

When CloudStack-to-Cozystack migration is the right answer

Strong fit:

• Service provider running KVM-based CloudStack with growing customer demand for managed databases, S3, container-native, or GPU services
• Engineer scarcity is starting to hurt operational quality
• Customer base is growing or stable; not declining
• Operator has budget for a 9-24 month modernisation programme

Marginal fit:

• VMware-on-CloudStack providers — solve VMware migration first
• Stable, slow-growing operators with deep CloudStack expertise who aren’t feeling the operational pain — modernisation is a deferrable capital project

Poor fit:

• Operators in declining-customer-count territory — modernisation cost is hard to justify
• Very small operators (<200 customers) — Cozystack Public Cloud Platform fixed cost overshoots the savings

Engagement structure

• Discovery call (30 min, free)
• Migration assessment (3-6 weeks, fixed-price) — inventory, workload buckets, timing
• Pilot deployment (3-6 months) — Cozystack platform stood up, 5-10 friendly customers migrated, billing workflows validated
• Customer-cohort migration (6-18 months) — workload migration in cohorts, decommission of CloudStack in parallel
• Managed retainer (optional, ongoing) — Ænix Tier-3 SLA

Total elapsed time: 12-24 months from project start to CloudStack fully retired.

Where to dig deeper

• CloudStack migration hub — high-level migration entry point
• Public Cloud Platform product page — the most common target product for CloudStack migrations
• Hosting providers industry page — hosting-provider-specific positioning
• Hosting provider platform modernization — related modernization pattern article