In-place upgrade behaviour
Learn about the in-place upgrade behaviour when the workload and database entitlements are enabled or disabled.
Workload entitlement disabled (default)
Cloudera Data Engineering scans all instance groups for v3 or v4 SKUs using the internal unsupported instance type replacement list. For each affected node pool, it emits a migration component. A pre-flight SKU availability check runs against each target v5 SKU before any destructive operation begins.
Migration order: comp → app → app2 → cmp2 → base
The base node pool is migrated last, because it hosts cluster-level infrastructure.
Each migration uses a two-phase delete-then-create operation:
- Deletes the existing v4 node pool using the delete operation. This operation is irreversible once started.
- Creates a new v5 node pool using the create operation.
Workload entitlement enabled
Cloudera Data Engineering detects the entitlement as soon as the upgrade is triggered and no migration is performed. All node pools remain on their existing legacy instance types. All other upgrade operations, including K8s version, Helm charts, and database version upgrades, proceed normally.
Log message includes: "Skipping Azure workload instance group type migration per
entitlement DE_AZURE_LEGACY_WORKLOAD_INSTANCE_TYPE"
Database entitlement disabled (default)
When the database entitlement is disabled, the upgrade process performs an in-place update of the database instance. The system identifies the equivalent next-generation SKU for your current database and updates the instance directly — no deletion or recreation is required. Your database remains available throughout the operation.
Database entitlement enabled
When the database entitlement is enabled, the instance type (SKU) upgrade is skipped. The database is still upgraded if a new engine version is available (for example, MySQL 8.0 → 8.4), but the underlying instance size and type remain unchanged. If neither an engine version upgrade nor an instance type change is needed, the database is considered up to date and no upgrade is performed.
Log message includes: "Skipping Azure DB instance type migration to <type> per
entitlement DE_AZURE_LEGACY_DB_INSTANCE_TYPE"
Restore
When restoring a cluster, the instance types are automatically updated to their current equivalents. If the legacy instance type entitlement is enabled, this substitution is skipped and the cluster is restored using its original instance type.
Summary table
| Operation | Workload entitlement disabled | Workload entitlement enabled | Database entitlement disabled | Database entitlement enabled |
|---|---|---|---|---|
| Creating new node pools | v5 SKU defaults (D8s_v5, E8s_v5) | v4 SKU defaults (D8s_v4, E8s_v4) | — | — |
| Creating new database | — | — | v5 SKU (D2ads_v5 / D8ads_v5) | v4 SKU (D2ds_v4 / D8ds_v4) |
| In-place upgrade of node pools | Migrates v4 SKU→v5 SKU (pre-flight checked) | Skips migration, keeps current types | — | — |
| In-place upgrade of database SKU | — | — | Migrates to v5 SKU (in-place) | Skips SKU migration |
| In-place upgrade of database version | — | — | Upgrades version (if needed) | Upgrades version (still proceeds) |
| Restore | Replaces retired types with v5 SKU equivalents | Skips replacement, keeps original types | — | — |
| UI instance picker | v5 SKU selectable, v4 SKU hidden | v4 SKU selectable, v5 SKU hidden | — | — |
