--- title: Release deferral description: Ping Identity lets you defer regular channel releases to your production tenant environments for up to 7 days. This gives you the opportunity to test and validate new regular channel releases in your lower environments (development, UAT[1], and staging) using your most up-to-date configuration. component: pingoneaic page_id: pingoneaic:release-notes:release-deferral canonical_url: https://docs.pingidentity.com/pingoneaic/release-notes/release-deferral.html section_ids: release-upgrade-options: Release upgrade options additional-considerations: Additional considerations release-upgrade-schedule: Release upgrade schedule single-region-deployment: Single-region deployment example-upgrade-scenario-for-a-single-region-deployment: Example upgrade scenario for a single-region deployment multi-region-deployment: Multi-region deployment example-upgrade-scenario-for-a-multi-region-deployment: Example upgrade scenario for a multi-region deployment --- # Release deferral Ping Identity lets you defer regular channel releases to your production tenant environments for up to 7 days. This gives you the opportunity to test and validate new regular channel releases in your lower environments (development, UAT\[[1](#_footnotedef_1 "View footnote.")], and staging) using your most up-to-date configuration. Each scheduled major release is eligible for deferral. The deferral period has the following characteristics: * It begins when the major release is deployed to your lower environments. * It ends 7 days later, or sooner if you choose. * It isn't extended for minor version updates (for example, `15158.1` to `15158.2`). These incremental updates are part of the same scheduled major release and don't restart the deferral period. As part of your Advanced Identity Cloud onboarding, you can specify a preferred upgrade time in UTC. This is the exact time of day that the release upgrade is deployed to your production environment at the end of the 7-day deferral period, allowing alignment with your preferred maintenance or change window. You can change the automatic upgrade time for future releases by creating a support case in the [Ping Identity Support Portal](https://support.pingidentity.com). ## Release upgrade options During this 7-day deferral period, you have several options for managing the release upgrade to production: * **Default option**: At the end of the 7-day deferral period, at your UTC preferred upgrade time, the release upgrade is automatically deployed to your production environment. * **Self-service option:** Trigger the deployment of the release upgrade to your production environment at any time by [running a promotion](../tenants/self-service-promotions.html) from your staging environment to your production environment. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | The deployment of the release upgrade to your production environment is triggered by the first promotion to that environment during the 7-day deferral period. This means that you must pause promotions to your production environment until you have validated the new release in your lower environments. | * **Support-assisted options**: * **Upgrade without a promotion**: Apply the release upgrade to your production environment without promoting any changes from staging. To do this, create a support case in the [Ping Identity Support Portal](https://support.pingidentity.com) to request an upgrade. * **Promote without an upgrade**: Promote configuration changes to production but wait to apply the release upgrade. To do this, create a support case in the [Ping Identity Support Portal](https://support.pingidentity.com) to request the configuration promotion. This option is only available if the configuration changes you're promoting are compatible with the release version currently in your production environment. > **Collapse: Learn more about configuration promotion and version compatibility** > > If your changes were made after your staging environment was upgraded, they might depend on the new release and can't be promoted without also upgrading production. > > Scenario 1: Compatible changes > > You made configuration changes **before** your staging environment was upgraded to the new release. > > [icon: check, set=fa]The changes can be promoted to production without the release upgrade because they're compatible with the older version. > > Scenario 2: Incompatible changes > > You made configuration changes **after** your staging environment was upgraded. > > [icon: times, set=fa]The changes can't be promoted to production without the release upgrade because they could depend on features only available in the new version. ## Additional considerations * If you've recently promoted an upgrade to production on a deferred release, you can roll back both the upgrade and the promotion by creating a support case in the [Ping Identity Support Portal](https://support.pingidentity.com). * In the rare event that Ping Identity applies a [hotfix](release-process.html#hotfixes) to the major release while you're testing it in the lower environments, only the minor version changes, so the 7-day deferral period in your production environment isn't extended. This ensures that Ping Identity can apply security updates quickly and effectively, without impacting the cadence of scheduled regular channel releases. * You can use the [release information](../tenants/environments-release-information.html#view-release-information-using-the-api) from your production environment to track the 7-day deferral period. ## Release upgrade schedule Release deferral changes the schedule that release upgrades follow when they are deployed to your tenant environments. The schedule is also influenced by whether it's a [single-region deployment](../tenants/environments-architecture-availability-disaster-recovery.html#single-region) or a [multi-region deployment](../tenants/environments-architecture-availability-disaster-recovery.html#multi-region-high-availability)\[[2](#_footnotedef_2 "View footnote.")]. ### Single-region deployment [Single-region deployment](../tenants/environments-architecture-availability-disaster-recovery.html#single-region) is the default deployment option for Advanced Identity Cloud. For this deployment option, the release upgrade schedule is determined only by the 7-day deferral period. #### Example upgrade scenario for a single-region deployment The following example illustrates the upgrade sequence. It assumes the following: * A 7-day deferred release period. * The current version is 12300.1 and the new version to be deployed is 12345.1. * Version 12345.1 becomes available on May 1. * You choose not to promote the release manually to production during the deferral period. | Date | Main region | | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | May 1 | - Staging environment [icon: refresh, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1 immediately. - Production environment [icon: more_time, set=material, size=inline] **Version 12300.1** Scheduled to upgrade to 12345.1 after a 7-day deferral period. | | May 8 | * Staging environment **Version 12345.1** * Production environment [icon: update, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1, 7 days after the staging environment at your UTC preferred upgrade time. | ### Multi-region deployment If your tenant instance has a [multi-region deployment](../tenants/environments-architecture-availability-disaster-recovery.html#multi-region-high-availability)\[[2](#_footnotedef_2 "View footnote.")], the release upgrade schedule is determined by both the 7-day deferral period and an additional multi-region delay period. The primary region environments are upgraded first, according to the deferral period. The secondary region environments are upgraded only after the primary region has successfully completed its upgrade and a multi-region delay period has passed. This ensures that the secondary region only upgrades after the primary region has completed its upgrade, maintaining stability and minimizing risk. #### Example upgrade scenario for a multi-region deployment The following example illustrates the upgrade sequence. It assumes the following: * A 7-day deferred release period. * A 3-day multi-region delay period between regional upgrades. * The current version is 12300.1 and the new version to be deployed is 12345.1. * Version 12345.1 becomes available on May 1. * You choose not to promote the release manually to the primary region's production environment during the deferral period. If you did manually promote, it would cause the secondary region's production upgrade to be scheduled for 3 days after the promotion. | Date | Primary region | Secondary region | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | May 1 | - Staging environment [icon: refresh, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1 immediately. - Production environment [icon: more_time, set=material, size=inline] **Version 12300.1** Scheduled to upgrade to 12345.1 after a 7-day deferral period. | * Staging environment [icon: more_time, set=material, size=inline] **Version 12300.1** Scheduled to upgrade to 12345.1 after a 3-day multi-region delay period. * Production environment **Version 12300.1** | | May 4 | - Staging environment **Version 12345.1** - Production environment [icon: pending, set=material, size=inline] **Version 12300.1** Pending upgrade to 12345.1, waiting for the 7-day deferral period to complete. | * Staging environment [icon: update, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1, 3 days after the primary region. * Production environment **Version 12300.1** | | May 8 | - Staging environment **Version 12345.1** - Production environment [icon: update, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1, 7 days after the staging environment at your UTC preferred upgrade time. | * Staging environment **Version 12345.1** * Production environment [icon: more_time, set=material, size=inline] **Version 12300.1** Scheduled to upgrade to 12345.1 after a 3-day multi-region delay period. | | May 11 | - Staging environment **Version 12345.1** - Production environment **Version 12345.1** | * Staging environment **Version 12345.1** * Production environment [icon: update, set=material, size=inline] **Version 12345.1** Upgrades to 12345.1, 3 days after the primary region at your UTC preferred upgrade time. | *** [1](#_footnoteref_1). A [user acceptance testing (UAT) environment](../tenants/environments-uat.html) is an [add-on capability](../product-information/add-on-capabilities.html).[2](#_footnoteref_2). Multi-region deployment is an [add-on capability](../product-information/add-on-capabilities.html).