You are migrating from CloudHub 1.0 to CloudHub 2.0 using the MuleSoft-provided upgrade tool and would like clarification on the migration timelines, specifically the two 30-day periods and the six-month VPC/DLB decommissioning window.
1. First 30-day window (stop the CH1 application)
- Trigger: Starts when 100% of traffic has been redirected to the CloudHub 2.0 application.
- Scope: Per application (not VPC-level).
- Enforcement: NOT technically enforced. The platform does not automatically stop or disable the CH1 app after 30 days. No traffic switching/rollback is disabled, no deployments are blocked, and no network changes are prevented.
2. Second 30-day window (delete the CH1 application)
- Trigger: Starts when the CloudHub 1.0 application is stopped.
- Scope: Per application.
- Enforcement: NOT technically enforced. Applications are not automatically deleted after this period.
3. Six-month infrastructure decommissioning window (VPCs + DLBs)
- Trigger: Starts when the VPC upgrade is marked complete ("Mark Upgrade Complete").
- Scope: VPC-level — covers the old VPC and all associated DLBs.
- Enforcement: NOT technically enforced. However, if exceeded, entitlement usage continues to be consumed by both old and new infrastructure simultaneously, potentially causing the org to exceed its purchased quota.
- Additional risk: Failing to decommission within 6 months can cause interruptions when trying to create or edit VPCs, Private Spaces, or network connections.
4. Does “Mark Upgrade as Complete” mean app-level or VPC-level completion?
There are two levels of completion:
App-level: "Mark Complete" is performed individually for each application during its migration.
VPC-level: The final, irreversible "Mark Upgrade Complete" completes the migration for the entire VPC.
Deleting the upgraded VPC after all apps and DLBs are removed does not affect CH2 Private Spaces or CH2 applications.
Quota / Entitlement Impact During Migration
- After completing the VPC upgrade and migrating TGW/VPN connections, old and new infrastructure count separately against quota.
- If the org uses its full purchased quota, usage can exceed the allowed quota during the migration window until old CH1 resources are decommissioned.
- MuleSoft does not provide out-of-the-box entitlement relief during the upgrade process.
- Work with your MuleSoft Account Representative to remain compliant and finish the upgrade on time.
Extension Requests
- There is no platform feature to extend migration timeframes.
- Extension requests must go through the MuleSoft Account Representative / CSM (not Support).
- For questions on entitlement, billing, compliance, written confirmation of extensions, and scope of extensions (per app / per VPC / org-level), contact your Account Representative.
Reference Links
- CloudHub to CloudHub 2.0 Application Migration (https://docs.mulesoft.com/cloudhub/app-migration)
- CloudHub to CloudHub 2.0 Migration Completion (https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion)
005389730

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.