Toggling the entitlements during the upgrade
Learn about the effects of toggling the entitlements during an upgrade.
Whether a changed entitlement takes effect on retry depends on how the retry is triggered:
| Retry type | Entitlement reevaluated? |
|---|---|
| Automatic internal retry | No—the upgrade resumes from where it left off |
| User-triggered retry after a terminal failure | Yes —the current entitlement state applies |
Enabling the legacy entitlement after a partial migration
If an upgrade partially migrates some node pools to the new instance type before failing, and you then enable the legacy workload entitlement before retrying, the following applies:
- Node pools already migrated to the new instance type remain on the new instance type.
- Remaining node pools are not migrated, the entitlement suppresses further migration.
- The cluster runs in a mixed state, with some pools on the new instance type and some on the original.
This is operationally safe. Both pool types run within the same cluster and workloads are scheduled across them normally. To complete the migration, disable the entitlement and trigger a new upgrade.
