CloudHub 2.0 is not a version bump. It is a new runtime, a new container model, and a new networking layer. If your integrations still run on CloudHub 1.0, the platform shift is already underway — and the parts the upgrade tool cannot handle are the parts that need planning now.
The good news: business users will not notice the change. The work lives entirely in the plumbing — runtime, containers, queues, and networking. Your integration team feels all of it, and that is exactly where a clear migration plan pays off.
Migrating from CloudHub 1.0 to CloudHub 2.0 means moving from fixed-VM "Workers" to Kubernetes-based containers, upgrading to Mule 4.3.0 or later, and rebuilding networking as Private Spaces. MuleSoft's in-app tool handles simple lift-and-shift apps, but persistent queues, the deprecated CloudHub Connector, and custom networking need hands-on rework. MuleSoft's own benchmark for a typical migration is 8–14 weeks.
CloudHub 2.0 is MuleSoft's current iPaaS runtime plane, built on Kubernetes-based containers instead of the fixed-VM "Workers" model used in CloudHub 1.0. Applications run as containerized replicas, which improves clustering, scaling, and resource allocation.
The shift changes how integrations are deployed, networked, and managed — not what they do. A working integration delivers the same business outcome on both platforms. The difference is the infrastructure underneath it.
A useful analogy: think of it like the Salesforce Classic-to-Lightning move. Same pattern — a forced platform shift, an in-app tool that handles the simple cases, and custom work that still needs human hands. The key difference is where the rebuild lives. Classic-to-Lightning was UI and Visualforce. This one is runtime, container model, networking, and queues.
The clock is loudest on the runtime side. Mule 3.9 reached end of life in March 2025, which means no more bug fixes or security patches for teams still running 3.x. CloudHub 2.0 only supports Mule 4.3.0 and later, so a runtime upgrade is often bundled into the migration.
For regulated and security-conscious organizations, running an unsupported runtime is a compliance and risk problem, not just a technical one. End-of-life software is a common audit finding and a real exposure when a vulnerability surfaces.
There is also an architecture upside. CloudHub 2.0 brings seamless Mule clustering, more granular vCore allocation, outbound firewall rules, self-service ingress logs, and auto-scaling private ingress load balancers. Teams that plan the move capture those gains instead of scrambling under an EOL deadline.
MuleSoft provides an in-app migration tool that handles the straightforward cases — simple lift-and-shift applications move with minimal rework. The tool covers roughly 60% of a typical estate. The remaining 40% is where experienced hands matter: custom queues, networking rewrites, and connector swaps.
Here is what changes under the hood:
Two questions answer most of the scoping conversation: what Mule runtime are you on, and roughly how many CloudHub 1.0 apps are in scope. From there, complexity scales with the details.
| Factor | Lower Effort | Higher Effort |
|---|---|---|
| Mule runtime | Already on 4.3.0+ | Still on 3.x (runtime upgrade bundled in) |
| App count | Small estate (a few apps) | Large estate (dozens of apps) |
| Queues | No persistent VM queues | Heavy use of persistent VM queues → Anypoint MQ |
| Connectors | No CloudHub Connector | Relies on CloudHub Connector (must be replaced) |
| Networking | Simple, shared space | VPC peering, VPNs, dedicated load balancers, vanity domains, mTLS |
| Environments | Few (dev/prod) | Many (dev/test/stage/prod) |
The platform move itself is rarely the cost driver. The per-app rework is — re-pointing persistent queues to Anypoint MQ, rebuilding networking as Private Spaces, and swapping the deprecated connector.
A practical CloudHub 2.0 migration follows a clear sequence:
If a stakeholder asks "why use a partner when MuleSoft has an upgrade tool?" the answer is simple: the tool handles the clean lift-and-shift apps. Partners handle the custom queues, networking rewrites, and connector swaps — the part that breaks if it is rushed.
Vantage Point is a MuleSoft partner, and integration work is a core part of what our professional services team runs. CloudHub 1.0 → 2.0 migration sits squarely in that practice, led by senior consultants who have done the runtime upgrades, queue migrations, and network rebuilds before.
We scope each migration by the factors that actually move the needle — app count, current runtime, queue and connector usage, and network complexity — and deliver a phased plan that keeps integrations running while the platform shifts underneath them.
If your team is evaluating how this applies to MuleSoft, Salesforce, or your broader integration estate, our system integration and data migration team can assess the right next step and build a practical migration plan. For ongoing runtime, queue, and connector support after cutover, our managed services and ongoing support practice keeps integrations healthy, and our workflow automation and process optimization work makes sure the rebuild improves the process, not just the platform.
CloudHub 1.0 runs applications on fixed-VM "Workers," while CloudHub 2.0 runs them as Kubernetes-based container replicas. CloudHub 2.0 adds seamless clustering, fractional vCore allocation, and Private Spaces, but requires Mule 4.3.0 or later and does not support persistent VM queues or the CloudHub Connector.
MuleSoft's benchmark for a typical migration is 8–14 weeks. A small, clean estate lands at the low end, while heavy custom networking, queue rework, or a bundled Mule 3.x runtime upgrade pushes the timeline higher.
No. The in-app tool handles roughly 60% of a typical estate — the simple lift-and-shift applications. The remaining 40% involves custom queues, networking rewrites, and connector replacement that need hands-on engineering. This is the gap a MuleSoft partner like Vantage Point fills.
Often, yes. CloudHub 2.0 supports only Mule 4.3.0 and later. If your applications still run on Mule 3.x, a runtime upgrade is bundled into the migration — and since Mule 3.9 reached end of life in March 2025, that upgrade also closes a security and compliance gap.
They are not migrated automatically. CloudHub 1.0 VPCs are rebuilt as CloudHub 2.0 Private Spaces with new ingress load balancers, and VPC peering and direct connect are deprecated in favor of transit gateway attachments. You cannot create a VPN between a 1.0 VPC and a 2.0 Private Space.
Persistent VM queues are not supported in CloudHub 2.0; use Anypoint MQ for persistent queues and queue management. The CloudHub Connector is also unsupported and must be replaced as part of the migration.
Yes. Individual APIs and integrations can move to CloudHub 2.0 independently of the rest of the estate, which allows a gradual, lower-risk transition rather than a single high-stakes cutover.