Contact Us 1-800-596-4880
  1. Homepage
  2. CloudHub 2.0
  3. Migrate from CloudHub to CloudHub 2.0
  4. Step 4. Validate and Switch Traffic

  5. Switch Traffic and Monitor the Migration

Switch Traffic and Monitor the Migration

Identify your traffic source, switch traffic from CloudHub to CloudHub 2.0 in stages, monitor application health against rollback thresholds, and account for how API policies behave during the split.

Understand Your Traffic Source

Your traffic source determines which DNS record CloudHub updates to manage traffic flow between your CloudHub and CloudHub 2.0 applications during migration.

CloudHub receives traffic from two main sources.

  • Shared Load Balancer (SLB): Associated with the default endpoints of your CloudHub app. The SLB handles traffic switching if the ingress configuration includes the default CloudHub app endpoint in the format <app_name>.<region>.cloudhub.io.

  • Dedicated Load Balancer (DLB): Associated with vanity domains configured for your CloudHub app. If the default CloudHub endpoint is missing and you configured a vanity domain or an anypointdns.net endpoint, the DLB switches the traffic.

If your CloudHub 1.0 application has the default endpoint configured, traffic switches at the SLB. To switch traffic from the DLB instead, remove the CloudHub 1.0 default endpoint, apply changes, and then change the traffic switch percentage.

DLB with HTTPS Traffic Switching

For applications using a DLB and expecting HTTPS traffic.

  1. Enable the Last-Mile Security setting in the Ingress tab of the deployment settings for the CloudHub 2.0 application.

  2. Enable Upstream TLS 1.2 or higher in your DLB settings.

  3. Verify that vanity domains on CloudHub 2.0 match those on the CloudHub application to prevent dropped traffic.

DLB with HTTP Traffic Switching

For applications using a DLB and expecting HTTP traffic.

  1. Add a firewall rule allowing HTTP from the local private network.

The CloudHub DLB routes requests from clients to Mule applications deployed within the VPC. The DLB sends requests to a Mule application and uses the HTTP Host header to find the certificate endpoint that matches the request. Then, the DLB uses the URL mapping rules for that endpoint to send the request to the Mule application. If the request doesn’t match any certificate configured on the DLB, then the DLB uses the "default" certificate endpoint to match the request against its URL mapping rules. During traffic switching, CloudHub 2.0 doesn’t contain mapping rules for this unmatched host within the default certificate.

SLB with HTTPS Traffic Switching

For applications using an SLB and expecting HTTPS traffic.

  • Enable the Last-Mile Security setting in the Ingress tab of the deployment settings for the CloudHub 2.0 application.

SLB with HTTP Traffic Switching

For applications using an SLB and expecting HTTP traffic.

  1. Enable the Accept HTTP option within the Advanced tab of your private space settings.

  2. Add a firewall rule allowing HTTP from any source.

Switch Traffic to CloudHub 2.0

After you deploy your CloudHub 2.0 application, test it by directing traffic to it and verifying network connectivity and application behavior.

To avoid updating client applications, use the same domains in CloudHub 2.0. Choose one of these options.

  • Customer-managed: Switch the app’s DNS to point to CloudHub 2.0.

  • MuleSoft-managed: Carry over vanity URLs while incrementally switching a percentage of traffic from CloudHub to CloudHub 2.0.

You can also use APIs for application linking using the upgradeData object while creating CloudHub 2.0 deployments, and for traffic switching using the newly introduced endpoint.

Gradually Switch Traffic

Shift a percentage of traffic from CloudHub to CloudHub 2.0 in Runtime Manager, or automate the shift with the REST API.

Restart your DLB before initiating traffic switching.
Switching application traffic requires the CloudHub Network Administrator permission. Without this permission, the traffic switching fails. For more information about assigning permissions, see Permissions by Product in Anypoint Platform.
Keep the CloudHub application in the STARTED state until the link between CloudHub and CloudHub 2.0 is successfully established. Stopping the CloudHub application before the link is established can cause traffic disruptions.

To gradually switch traffic from CloudHub to CloudHub 2.0.

  1. In Runtime Manager, go to Finish Upgrade.

  2. Select the percentage of traffic to direct from CloudHub to CloudHub 2.0, and click Save Changes.

If failures occur during this stage, roll back to CloudHub.

Automate Traffic Switching via REST API

Use the AMC Application Manager API to automate traffic switching.

  1. Get an access token.

    curl -X POST https://anypoint.mulesoft.com/accounts/login \
  -H "Content-Type: application/json" \
  -d '{
    "username": "YOUR_USERNAME",
    "password": "YOUR_PASSWORD"
  }'

  2. Switch traffic percentage

    Use the traffic switching endpoint to set the percentage of traffic directed to CloudHub 2.0.

curl -X PUT \
  https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/upgradedata/trafficswitching \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "switchedTraffic": 25
  }'
Find the current endpoint path and request body in the AMC Application Manager API reference. Verify the endpoint path and parameters against the latest API documentation before using them in automation scripts.

Example automation script: The increments and durations are illustrative. Adjust them to your risk tolerance and app type.

#!/bin/bash
# Gradual traffic switching automation
# Switches traffic in increments with validation pauses

ORG_ID="your-org-id"
ENV_ID="your-env-id"
DEPLOYMENT_ID="your-deployment-id"
TOKEN="your-access-token"
BASE_URL="https://anypoint.mulesoft.com/amc/application-manager/api/v2"

for PERCENT in 10 25 50 75 100; do
  echo "Switching to ${PERCENT}% traffic..."
  curl -X PUT \
    "${BASE_URL}/organizations/${ORG_ID}/environments/${ENV_ID}/deployments/${DEPLOYMENT_ID}/upgradedata/trafficswitching" \
    -H "Authorization: Bearer ${TOKEN}" \
    -H "Content-Type: application/json" \
    -d "{\"switchedTraffic\": ${PERCENT}}"

  echo "Traffic at ${PERCENT}%. Monitor for errors before you proceed."
  echo "Press Enter to continue to next increment..."
  read -r
done

Increase traffic in stages, and observe each stage for the recommended duration before you proceed.

Traffic Percentage Duration Purpose

10%

24 hours

Smoke test with minimal traffic. Verify basic connectivity and application behavior.

25%

48 hours

Increased load. Monitor error rates and response times.

50%

72 hours

Balanced split. Validate performance under significant load. Watch for API policy rate-limiting doubling.

75%

24 hours

Majority on CloudHub 2.0. Confirm stability before full cutover.

100%

7 days minimum

Full cutover. Monitor for any remaining issues before decommissioning.

The estimated time before cleanup is about 14 days.

Risk-Based Switching Strategies

The right switching pace depends on the application’s risk profile and workload type.

Application Type Strategy Rationale

Low-risk (low traffic, non-critical)

Fast switching (~5 days)

Lower blast radius allows faster progression through traffic percentages.

High-risk (high traffic, revenue-critical)

Slow switching (15+ days)

Extended observation at each percentage level to catch subtle issues.

Batch/scheduled jobs

All-or-nothing

Don’t use gradual traffic switching for scheduled jobs. Splitting traffic risks duplicate execution. Switch directly from 0% to 100%.

Monitor and Validate

Monitor application health and performance during the cutover, and use defined thresholds to decide when to roll back.

What to Monitor

Track the following metrics during traffic switching.

  • Error rates: Compare against the baseline from CloudHub.

  • Response times: Track latency changes.

  • CPU and memory usage: Verify that replicas are appropriately sized.

  • Request rate: Confirm that traffic is arriving at expected levels.

Threshold Guidance

Compare error rate and response time against your CloudHub baseline to decide when to warn or roll back.

Metric Warning Rollback

Error rate increase

>5% increase over baseline

>20% increase over baseline

Response time increase

>25% increase over baseline

>50% increase over baseline (critical)

Performance degradation

—

>2x degradation from baseline

When to Roll Back Immediately

Roll back to CloudHub if you see either of these conditions.

  • Sustained 5xx errors (500, 502) exceeding the baseline, not isolated occurrences. See 502 Bad Gateway During Traffic Switch for common causes to rule out before rolling back.

  • Performance degradation greater than 2x baseline

When Not to Roll Back

Some behaviors are expected during traffic switching and don’t require a rollback.

Manage API Policies During Traffic Switching

When you apply API policies to your new application, they begin with a clean internal status.

Policies Unchanged by the Migration

These policies don’t rely on internal status, and their behavior remains consistent.

  • http-basic-authentication

  • cors

  • client id enforcement

  • Header injection

  • Header removal

  • ip-allowlist

  • ip-blocklist

  • ldap-authentication

  • message-logging

  • json-threat-protection

  • xml-threat-protection

Policies Affected by Internal Status (Caching)

These policies rely on internal status to cache data.

  • external-oauth2-access-token-enforcement

  • openam-access-token-enforcement

  • openidconnect-access-token-enforcement

  • pingfederate-access-token-enforcement

  • mule-http-caching-policy

  • jwt-validation

When transitioning to the new application, these policies either trigger additional requests to the origin servers or have different cached values depending on which application receives the requests.

Policies Affected by Internal Status (Request Counting)

These policies track the number of processed requests and sometimes exhibit unexpected behavior during the transition to the new application.

  • rate-limiting

  • rate-limiting-sla-based

  • spike-control

If there’s a hard change in traffic from one application to the other, policy counters behave as if they were reset. In a balanced round-robin traffic distribution, the effective number of requests sometimes doubles because each application maintains an independent counting mechanism.

Rate-Limiting Mitigation

The effective rate limit can double during a split. Use one of these approaches to mitigate it.

Problem: The effective rate limit doubles during a 50/50 traffic split because each app (CloudHub and CloudHub 2.0) maintains independent policy counters, and each maintains per-replica counters.

Solutions.

  • Configure half the rate limit on both the CloudHub 1.0 and CloudHub 2.0 applications during the split.

  • Accept temporarily doubled limits during the transition.

  • Apply rate-limiting policies only after 100% cutover and consolidate back to full limits.

Autodiscovery

Autodiscovery connects a deployed Mule application with an API defined in API Manager. Throughout the migration, both your CloudHub and CloudHub 2.0 applications link to the same API.

During the CloudHub to CloudHub 2.0 application migration, traffic gradually shifts, and both applications are active simultaneously. To maintain consistent policy enforcement, configure equivalent policies on your CloudHub 2.0 application’s API instance during traffic switching.

See Also