PingOne Advanced Services

Platform and product upgrades

Why upgrade

PingOne Advanced Services platform and product upgrades are required on a regular basis to ensure that the platform is secure, resilient, and remains reliable. These upgrades often include security fixes, updated TLS and cipher configurations, and dependency updates that help you meet internal and regulatory requirements. They also contain new features, bug fixes, and disaster recovery, observability, and operational tooling improvements.

What happens if you don’t upgrade

We prefer that you take the time to perform small, low-risk upgrades on a regular basis, rather than doing large, high-risk upgrades that could be more disruptive.

If you defer upgrades for an extended period of time:

  • Older platform and product versions eventually fall outside our standard support posture and receive fewer fixes and performance improvements. Learn more about how platform and product versions are deprecated in our Support policy and the Ping Identity End-of-Life (EOL) Tracker.

  • You might miss out on resilience, disaster recovery, and observability improvements. Issues we fix in newer versions will continue to affect you.

  • Your environments might be running on unsupported infrastructure, such as older Amazon Elastic Kubernetes Service (EKS) versions, which increases your operational and security risk.

    AWS manages Amazon EKS support timelines independently of Ping Identity. AWS might force those running Amazon EKS versions beyond their supported window to upgrade. When this happens, the upgrade does not follow our controlled rolling process, and your environments could experience significant unplanned downtime.

In cases where a critical security vulnerability is identified, we might need to schedule an out-of-cycle security upgrade outside the normal cadence. In those situations, scheduling flexibility can be limited by urgency. Learn more in Out-of-cycle or emergency upgrades.

Release notes

The PingOne Advanced Services release notes use Semantic Versioning (SemVer), in which version numbers are structured as Major.Minor.Patch to communicate the scope of changes:

  • The Major.Minor format identifies the platform version, a tested bundle of the PingOne Advanced Services infrastructure, EKS, cluster tooling, and minimum required product versions, such as PingFederate, PingAccess, and PingDirectory.

  • The patch identifies add-on or targeted updates built on top of a specific Major.Minor platform, such as a PingFederate security patch applied to 2.1 customers, or a targeted fix that does not require a full platform release.

Items to keep in mind include:

  • Patch releases aren’t always sequential across all products. A PingDirectory patch does not automatically mean PingFederate is also updated to the same patch number.

  • Upgrading to a specific platform version could require catch-up product upgrades. If your current product versions are below the minimums required for the target platform, those catch-up upgrades will be included in the same campaign.

  • If upgrades introduce changes that are not backward compatible with existing integrations, operational patterns, or with an underlying Ping Identity product, such as PingFederate or PingDirectory, we’ll explain the change in the release notes and in your upgrade communications and provide recommended mitigation or validation steps.

  • As we complete the migration to microservices, we plan to release frequent product-level updates, such as a new PingFederate version, without requiring a new platform campaign for every change.

Learn more about our version support policies and deprecation timelines in the PingOne Advanced Services Support policy.

What’s included in an upgrade

You’ll be informed of which environments, versions, and components are in scope for a given upgrade. Upgrades can include:

  • Platform and orchestration layer updates, which can include updates to Kubernetes, Amazon EKS, cluster tools, such as Argo CD and monitoring agents, or the orchestration logic that manages your environments.

  • Ping Identity product updates, such as PingFederate, PingAccess, PingDirectory, PingDataSync, PingCentral, Delegated Admin, and components related to current, supported versions.

    PingDirectory is deployed in all PingOne Advanced Services environments, even if it is not a visible part of your identity solution design. PingDirectory serves as the datastore for PingFederate and other platform components, so it must be included in your upgrade plans.

  • Security and compliance updates, which can include security patches at the product, platform, and infrastructure layers, including updates driven by AWS, Kubernetes, and Ping Identity security bulletins.

Some upgrades also change security controls, such as TLS versions, cipher configurations, certificate handling, or logging hardening, to keep you aligned with current security standards. When that happens, it will be described in the PingOne Advanced Services release notes and in your upgrade communications so that you can determine whether changes to your configurations are needed.

The items included in a release, and the timing of the release, depend on the severity of the issues the release addresses, and the number of customers affected.

  • Patch or targeted releases: Include fixes as a patch on top of the current platform version. This approach is typically used to address security issues or high-impact defects.

  • Next platform release: Includes enhancements and improvements, and addresses lower-severity issues.

Issues and defects are initially identified by:

  • Our support and engineering teams, who discover the issues when monitoring platforms, performing routine platform maintenance, or upgrading clients to new versions.

  • Our professional services teams when working on partner implementations.

  • Users like you. If you discover an issue, open a service request through the Support Portal.

After an issue is confirmed as a platform or product defect, our engineering team creates an internal tracking ticket (a TRIAGE ticket) to investigate the root cause of the issue, determine how we will fix it, and establish its priority.

From there, the engineering teams determine which updates, fixes, and enhancements will be included in each release and when the release will be available.

How upgrades are scheduled

To continually improve the platform and keep it secure, we work to release new versions every quarter. However, your upgrades are scheduled around your availability, and the upgrade campaign sequence.

Upgrades are coordinated between you, your account team, and the PingOne Advanced Services support and operations teams. Your account team might consist of a support account manager or a technical support manager who will serve as the coordinator between you and the support and operations teams. They will help you establish dates and times for the upgrade and communicate with you throughout the process.

To initiate an upgrade:

  • You can contact your account team or open a service request through the Support Portal requesting the upgrade.

  • Your account team can initiate the upgrade and reach out to you to begin planning.

  • The operations team can also initiate the upgrade and ask your account team to reach out to you to begin planning.

    If we attempt to contact you regarding your upgrade, and you do not respond, we will proceed on our proposed dates. Ping Identity has a responsibility to maintain the security and integrity of the platform, and indefinite deferral carries real risk. We will always make at least three contact attempts and communicate with you before proceeding without a response.

When you begin working with the account team, it’s helpful to provide them with the following:

  • Your preferred timeframe and any freeze periods or blackout dates.

  • Your time zone and preferred maintenance windows.

  • Any key business events to plan around, such as significant load events, large migrations, seasonal peaks, and regulatory reporting windows.

It’s also helpful if you ensure that internal approvals and CAB processes are satisfied before scheduled upgrade windows.

All of this information and all upgrade-related communication will be tracked in the service request that you or your account team will open. It will include date confirmations, schedule changes, post-upgrade validation status, and provide an audit trail for internal and external reviews.

You cannot reschedule upgrades for your development and testing environments once the dates and times are established. These environments are used to validate the upgrade campaign and must be upgraded and stable before we can upgrade your staging and production environments. Staging and production environments can be rescheduled with at least 48 hours' notice. Changing the upgrade dates and times with less than 48 hours' notice is often not possible due to staffing and scheduling constraints.

As we complete the transition to a microservice architecture, the upgrade cadence will change. Product-level upgrades, for example, a new PingFederate version, will be available independently of the broader platform, which means upgrades will become smaller, more targeted, and more frequent, with less scheduling overhead and disruption required for each one.

In the meantime, the best way to avoid a large catch-up campaign is to stay engaged with your account team and schedule upgrades when recommended.

Expected downtime

PingOne Advanced Services environment configurations and customizations are preserved across upgrades, and most users should not notice the upgrade.

Specifically, the following will not be affected:

  • PingFederate service provider (SP) connections

  • Authentication flows and policies

    PingOne Advanced Services performs rolling upgrades of the application engines (PingFederate, PingAccess, PingDirectory), so at no point should the platform be unable to process authentication requests as a direct result of the upgrade.

    However, with some major version updates, PingFederate might not recognize tokens issued by earlier versions. As traffic moves from old to new instances, some users might need to reauthenticate.

  • PingDirectory schemas

  • PingAccess application rules and similar settings

If exceptions apply, you will be informed of them before the upgrade, and they will be documented in your upgrade runbook.

Downtime is expected, however, to occur with:

  • Admin consoles and single-node resources

    Resources with a single node, such as the PingFederate admin console, will not be available while they are being upgraded. During that window, you will not be able to make configuration changes through those admin UIs or certain administrative APIs. Authentication engines continue to serve traffic while admin consoles are offline.

  • Observability and tools

    Logging and metrics might show short gaps or brief anomalies when components are restarted. We monitor the platform before, during, and after the upgrade to ensure it returns to normal.

  • Multi-region deployments

    For multi-region deployments, each region has a defined upgrade sequence established in the runbook for your account. In most cases, at least one region continues serving traffic while the other is being upgraded, but the specifics depend on your DNS and load-balancing configuration. We’ll temporarily stop sending users to your primary region and send them to the secondary regions during the upgrade.

  • Full rollback scenarios

    In the rare case of a full rollback, PingOne Advanced Services might need to reinitialize from backup in the affected environment. During the reinitialization and restoration process, the environment will be unavailable until fully restored and validated.

    Rollbacks are treated as incidents, and you will receive appropriate incident communication and updates throughout the process. If a full outage is expected for any reason during an upgrade, we will state that explicitly in your upgrade communication prior to the upgrade.

Upgrade duration and planning

Upgrades are performed on each environment and the Customer Hub (CHUB), which is a shared infrastructure that underpins all of your PingOne Advanced Services environments, but it does not directly serve end-user authentication traffic. The CHUB hosts shared services all of your environments depend on, including networking, DNS, certificate management, and platform tooling, which is why the CHUB must be upgraded first in any platform upgrade campaign.

The following table provides information about each type of upgrade, the expected duration of the upgrade, and additional information regarding scheduling:

Type of upgrade Duration Additional information

CHUB

A few hours, depending on the amount of data involved.

Must be explicitly scheduled and upgraded first. No impact to the customer experience.

DEV environment

A few hours, depending on the size of the environment.

Upgraded to the target platform version and validated. Cannot be rescheduled once an upgrade date is set.

TEST environment

A few hours, depending on the size of the environment.

Upgraded, allowing broader integration and regression testing. Cannot be rescheduled once an upgrade date is set.

STAGE environment

Scheduled in 8 - 12 hour windows.

Upgraded after the DEV and TEST environment validation is complete.

PROD environment

Scheduled in 8 - 12 hour windows.

Upgraded after the STAGE environment validation is complete and internal change approvals are satisfied.

Multi-region environments take about 2 additional hours per region.

Don’t plan on completing an upgrade in less time than your account team plans for. We perform safe, rolling restarts and run health checks between each step to ensure mistakes aren’t made. The time it takes to complete will also depend on blackout and freeze periods, internal approval processes, and any operational constraints.

Also note that weekend upgrades are available as a paid add-on for PROD environments. If you have purchased this add-on, your account team can discuss how to schedule within that program. Targeted security patches do not qualify for the weekend upgrade slot.

Before, during, and after an upgrade

There are a variety of tasks that must be completed before, during, and after an upgrade by you, your account team, and the support and operations teams. The support and operations teams, and your account team will create and maintain their own tickets to monitor and record progress throughout the upgrade.

Before an upgrade

The support and operations teams will:

  • Prepare for the upgrade and run the following standard backups:

    • PingFederate and PingAccess every hour.

    • PingDirectory every 6 hours, except if you have large PingDirectory upgrades that take longer than 6 hours to create backups. If you do not have large PingDirectory upgrades, backups are taken during the upgrade window after post-check testing is complete. These are the backups that the team will restore in the event of a rollback.

  • Run an additional backup immediately before the upgrade. We note the date and time of this backup and will use it to compare the data and configurations after the upgrade is complete.

  • Sign on to all products so that we can test the experiences and ensure they’re working as expected after the upgrade.

Your account team will:

  • Plan and schedule the upgrade, and ensure that you understand when upgrade windows will begin and end.

  • Confirm the upgrade schedule with you through your upgrade service request, which will include the environments in scope, the target versions, and the planned start time for each environment. The service request will also contain links to the relevant release notes.

You should:

  • Ensure internal approvals and CAB processes are satisfied before scheduled upgrade windows. Notify us in advance of any freeze periods or blackout windows.

  • Let us know about significant load events, large migrations, or seasonal peaks so upgrades can be planned around them.

  • Review the release notes before your upgrade window. Pay particular attention to any Java version updates or changes to security controls, as these are the areas most likely to require your attention.

  • Ensure that you understand what time the upgrade is scheduled to start and end.

    Platform upgrades for STAGE and PROD environments are size-dependent and scheduled in 8 - 12 hour windows.

    • Single region: 8 hours

    • Double region: 10 hours

    • Triple region: 12 hours

      For example, if your upgrade is scheduled to start at 9:00 PM, plan for the window to run until approximately 7:00 AM. Ensure that your internal teams also understand when the upgrade windows begin and end.

    Customers with large PingDirectory upgrades might be bumped to the next region size class due to the amount of time that PingDirectory requires to upgrade itself.

During an upgrade

The support and operations teams will:

  • Complete a series of steps performed in most upgrades:

    1. Verify the current versions.

      Check to see which underlying product versions are currently being used.

    2. Divert traffic.

      For multi-region environments, we’ll temporarily stop sending users to your primary region and send them to the secondary regions during the upgrade.

      Inform us if you don’t want us to use a failover, or if you’re not using our global endpoint.

    3. Update the environment variables configuration in Git.

    4. Upgrade the PingFederate, PingAccess, and PingDirectory services.

      We’ll use the upgrade utility to upgrade products to new versions and ensure that previous configurations are migrated to the new versions.

    5. Check on the status of the pods.

      We monitor the pods and only upgrade a few pods at a time using your pre-upgrade backup data and configuration information, so the environment comes back with the same settings and data it had before. Then, we verify that the correct product versions are being used and perform validation checks for the region.

    6. Return traffic.

      When we’re done, we restore the primary region links within Global DNS reporting. These links enable traffic to be directed back to the upgraded primary region, diverting it from secondary regions, so that any remaining region upgrades can be performed.

    7. Inspect AWS monitors.

      We check and monitor the canary objects in AWS and ensure that they haven’t had interruptions of service after the update was performed.

    8. Perform validation checks.

      We then complete post-upgrade validation checks, which include signing on to all products to validate rendering, and screen capture configuration review.

  • Keep you and the account team informed of progress by updating the service request.

Your account team will:

  • Serve as the central point of contact and keep you informed of progress by updating the ticket.

  • Notify you when an environment upgrade is complete and ask you to ensure that your environment is functioning as it should before we start working on the next environment.

    Catching issues in the DEV and TEST environments is far less disruptive than discovering issues in your PROD environment.

  • Answer any questions you have along the way.

You should:

  • Stay up-to-date on upgrade communications and answer questions in the service request in a timely manner.

    If you have questions or observe unexpected behavior, immediately contact the support team in the service request. You should not need to communicate with an engineer directly.

  • When notified, test your environments to ensure they are functioning as they should.

    You don’t need to test every possible flow, but you should have a defined set of critical flows that you run after each upgrade as part of your business continuity practices. If you do not have this type of testing plan in place, we recommend developing one with your account team before the next upgrade campaign.

  • Ensure that your integration kits and custom adapters work as expected.

    We verify that your integration kits initialize without errors after the upgrade and confirm that first-party integrations function with default endpoints. However, we cannot verify how an integration kit is operating on the external system, or whether a third-party application that relies on the kit continues to behave as expected after a product version change.

    You are responsible for validating end-to-end behavior through your critical flows in the STAGE environment. Pay particular attention when release notes call out Java version changes, which can affect your integration kits and custom adapter compatibility.

After an upgrade

We test the platform and product stability throughout the upgrade process, but we cannot replicate all of your integrations and flows, which only you can test.

Specifically, we recommend that you test:

  • Primary authentication flows: Verify that your main SSO flows, federation connections, and sign-on journeys work as expected for your administrators and end users.

  • SP connections and application integrations: Confirm that applications that connect to PingFederate are authenticating successfully and receiving correct assertions or tokens.

  • Custom adapters and integration kits: Verify that these initialize correctly and that the systems they integrate with are responding as expected. A kit loading without errors does not guarantee the downstream system is behaving correctly.

  • PingDirectory behavior: If your use case relies on PingDirectory for identity data, password validation, or related functions, confirm that those flows are working.

  • Logging and observability: Verify that your log streams are reaching your security information and event management (SIEM) or observability platform and that log formats match your parsing rules. If the release notes for your upgrade mention log format changes, be sure to test your log integrations.

  • Admin UI access: Confirm that admin consoles are accessible and that your admin credentials work after the upgrade.

Out-of-cycle or emergency upgrades

If a critical security vulnerability is identified that affects the platform or one of the underlying Ping Identity products, we might need to apply a security patch immediately, or outside the normal upgrade cadence, and without advance communication.

What to expect in most situations:

  • We will reach out to you to explain the vulnerability and what the patch does to address it.

  • We’ll also explain the scope of the change, which environments will be patched, and in what order.

    The DEV and TEST environments will be patched first. Like other upgrades, once it’s scheduled, it cannot be rescheduled. The STAGE and PROD environments also have the 48-hour rescheduling policy.

  • Like other upgrades, you will be asked to validate your environments after each environment is patched before we proceed to the next.

Depending on the severity and exposure of the vulnerability, our scheduling flexibility might be limited. We will always communicate the urgency and the reason for it, and we will work with you to find a workable window while being transparent about the risk of delay.

Security patches are scheduled for weekdays and do not qualify for the weekend upgrade program.

If you are aware of upcoming blackout dates or constraints that could limit your ability to upgrade for a security patch on short notice, notify your account team.

Rollback policy and criteria

If we detect an issue during or immediately after an upgrade, our operations team will pause or rollback changes in the affected environment or region, according to our runbooks. Our support team will open another ticket associated with your upgrade service request to communicate status, impact, next steps, and to coordinate the rollback, if necessary.

First, we will work to restore stability. Then, we’ll analyze the root cause of the issues and work to address them.

Rollback decisions are made by our operations team and depend on whether specific conditions exist. If our operations team confirms that one or more of the following situations exist in your STAGE and PROD environments during the upgrade window, they might perform a rollback according to our runbooks.

  • Authentication flows are failing, not just degraded, and cannot be stabilized within the upgrade window.

  • A core service, (for example, PingFederate or PingDirectory) cannot reach a healthy running state.

  • Pre-agreed health checks defined in the upgrade runbook cannot be satisfied.

A full rollback might require reinitializing the environment from backup, during which the environment will be unavailable until fully restored and validated.

We will not complete a rollback for your DEV and TEST environments unless our operations team deems it necessary. These environments exist to discover issues before they reach the STAGE and PROD environments. We resolve issues by creating a targeted fix, configuration correction, or component upgrade, during which the validation path remains intact. Rolling back a DEV or TEST environment would discard the information gained from the upgrade and delay the overall campaign.