Short answer
Migrating from MuleSoft CloudHub 1.0 to CloudHub 2.0 moves Mule applications onto MuleSoft's containerized runtime, with new networking (private spaces), deployment pipelines and configuration. Applications usually need little code change, but networking, logging and CI/CD need redesign and testing.
Why firms make this move
CloudHub 2.0 is where MuleSoft is focusing its managed runtime. The move involves designing private spaces and connectivity, updating deployment pipelines and properties, migrating applications in waves, and validating each one before cutover.
What moves
- Mule applications and APIs
- VPCs and VPNs as private spaces and connections
- DNS, certificates and load balancing
- Logging, monitoring and alerts
- CI/CD pipelines
How the data maps
| From | To |
|---|---|
| VPC | Private space |
| Dedicated load balancer | Ingress and TLS context |
| Worker | Replica |
| Runtime Manager deployment | CloudHub 2.0 deployment |
What to watch out for
- Network and firewall changes on connected systems
- DNS cutover timing
- Logging integrations
- Application properties and secrets
How Vantage Point runs the migration
- Inventory applications and dependencies
- Design private spaces and networking
- Update CI/CD and properties
- Migrate in waves with testing
- Cut over DNS and decommission
Typical timeline
Typically 4 to 12 weeks, depending on the number of applications.
Frequently asked questions
Does CloudHub 2.0 need code changes?
Usually only minor ones; networking, logging and deployment configuration are where most effort goes.
Can we migrate gradually?
Yes. Applications are usually migrated in waves, starting with lower-risk APIs.