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.
Quick Answer
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.
TL;DR
- CloudHub 2.0 is a re-platform, not an upgrade. Containers replace Workers; Mule 4.3.0+ is required.
- The tool does the easy ~60%. Custom queues, networking, and connector swaps are the hands-on ~40%.
- VPCs, VPNs, and load balancers do not migrate automatically. They are rebuilt as Private Spaces with new ingress and transit gateway attachments.
- Persistent VM queues and the CloudHub Connector are gone. Plan for Anypoint MQ and connector replacement.
- Mule 3.9 reached end of life in March 2025. Teams still on 3.x carry a runtime upgrade and security exposure on top of the platform move.
- Vantage Point runs CloudHub 1.0 → 2.0 migrations as part of MuleSoft integration work, scoping each estate by app count, runtime, queues, and network complexity.
What Is CloudHub 2.0?
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.
Why CloudHub 2.0 Migration Matters in 2026
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.
How CloudHub 1.0 to 2.0 Migration Works
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:
- Runtime: Only Mule 4.3.0 and later are supported. Apps on Mule 3.x need a runtime upgrade first.
- Compute model: Fixed-VM Workers become Kubernetes-based container replicas with fractional vCore options.
- Networking: VPCs become Private Spaces with auto-assigned private networks and auto-scaling ingress load balancers.
- Connectivity: VPC peering and direct connect are deprecated; transit gateway attachments replace them. You cannot create a VPN between a 1.0 VPC and a 2.0 Private Space.
- Queues: Persistent VM queues are not supported. Use Anypoint MQ instead.
- Connectors: The CloudHub Connector is not supported and must be replaced.
- CI/CD: The Mule Maven plugin must be 3.7.1 or later, with a publish-to-Exchange-then-deploy flow.
- Security: TLS 1.0 is gone; use 1.2 or 1.3. Custom JVM truststores and JVM parameter overrides are not supported.
What Drives Migration Complexity?
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.
What Businesses Should Do Next
A practical CloudHub 2.0 migration follows a clear sequence:
- Inventory the estate. List every CloudHub 1.0 app, its Mule runtime, and its dependencies.
- Flag the rework. Identify apps using persistent VM queues, the CloudHub Connector, or custom networking.
- Map the network. Document VPCs, VPNs, dedicated load balancers, vanity domains, and mTLS so they can be rebuilt as Private Spaces.
- Plan the runtime path. If any app is on Mule 3.x, scope the 3.x → 4.x upgrade alongside the platform move.
- Migrate incrementally. Individual APIs can move to CloudHub 2.0 independently, enabling a gradual, low-risk transition.
- Update CI/CD. Bump the Maven plugin and adopt the publish-to-Exchange-then-deploy flow.
- Validate and cut over. Test in a Private Space, confirm networking and queues, then redirect traffic.
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.
How Vantage Point Helps
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.
FAQ
What is the difference between CloudHub 1.0 and CloudHub 2.0?
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.
How long does a CloudHub 1.0 to 2.0 migration take?
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.
Does the MuleSoft upgrade tool do everything?
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.
Do I have to upgrade my Mule runtime to migrate?
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.
What happens to my VPCs, VPNs, and load balancers?
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.
What replaces persistent VM queues and the CloudHub Connector?
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.
Can I migrate one application at a time?
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.
