Frequently asked questions on migrating to v5 Virtual Machine families

Does enabling the workload entitlement affect existing clusters that are already on v5?

Yes, partially. Cloudera Data Engineering returns legacy v4 type SKUs as selectable and v5 SKU types as non-selectable or hidden instances when the entitlement is active. Existing clusters that already use v5 SKU types still display their instance type correctly in the UI, and all cluster operations continue to work. New cluster creation defaults to v4 SKU types.

Does the database version upgrade still happen if the database entitlement is enabled?

Yes. The database entitlement only skips the SKU migration from v4 SKU →v5 SKU. The MySQL version upgrade, for example 8.0 → 8.4, is independent and proceeds regardless of the database entitlement state. To skip both, the database version has to be already up-to-date.

Can I enable the entitlement mid-upgrade to stop a migration that has already started?

No. Entitlements are evaluated once when the upgrade is triggered. An already running upgrade completes or fails regardless of entitlement changes. The entitlement only takes effect on the next upgrade workflow.

What happens if the pre-flight check fails for one pool but not for others?

The pre-flight checks run sequentially in migration order. The first failure returns a NonRetriableError and the entire upgrade workflow is rejected — no pool is deleted. The error message identifies the specific pool and SKU that failed. All pools are preserved.

How do I know if a tenant has these entitlements enabled?

Check the tenant's entitlement list by using the entitlements API or the internal entitlement store. Upgrade logs indicate Skipping Azure workload instance group type migration per entitlement or Skipping Azure DB instance type migration when the migration is skipped.

Does this affect AWS customers?

No. Every entitlement check is guarded by Azure cloud platform check. AWS and on premises environment providers are not affected by the entitlements.

Is there a risk of the pre-flight check being stale?

No. Entitlements are evaluated only when the upgrade process begins. If an upgrade is currently in progress, any changes to your entitlement settings do not affect the active operation. These changes only take effect when you initiate a new upgrade workflow.

What does "mixed-type state" mean and is it dangerous?

If an upgrade partially migrates some node pools to v5 instance types and then fails, and the workload entitlement is enabled before the next retry. In this state some node pools run on v5 instance types, while others remain on v4. This is operationally safe, both pool types run in the same AKS cluster and workloads schedule across them normally. The condition is self-healing: disable the entitlement and trigger a new upgrade to migrate the remaining v4 pools.

Will new clusters always be on legacy types if the workload entitlement is enabled?

For base/app/app2 node pools, yes, they default to the system-selected general or small legacy SKU, when the entitlement is enabled, using Standard_D8s_v4.

For comp/cmp2, the user-selected type from the UI is used.