--- title: Upgrade considerations description: The following changes between PingAccess versions might require additional steps during an upgrade. component: pingaccess version: 8.2 page_id: pingaccess:upgrading_pingaccess:pa_upgrade_considerations canonical_url: https://docs.pingidentity.com/pingaccess/9.1/upgrading_pingaccess/pa_upgrade_considerations.html llms_txt: https://docs.pingidentity.com/pingaccess/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: August 20, 2026 superseded_by: https://docs.pingidentity.com/pingaccess/9.1/upgrading_pingaccess/pa_upgrade_considerations.html section_ids: removing-support-for-java-8-and-11: Removing support for Java 8 and 11 considerations-when-upgrading-to-6-0-or-later: Considerations when upgrading to 6.0 or later performing-a-zero-downtime-upgrade-from-6-0-6-0-1-6-0-2-or-6-0-3-to-a-later-version: Performing a zero downtime upgrade from 6.0, 6.0.1, 6.0.2, or 6.0.3 to a later version new-templates-for-error-and-logout-pages: New templates for error and logout pages previous-target-version: Upgrading to a PingAccess version released before your current version using-a-proxied-pingfederate-deployment: Using a proxied PingFederate deployment spa-support: SPA support considerations-when-upgrading-to-7-0-or-later: Considerations when upgrading to 7.0 or later runtime-state-clustering-removal: Runtime state clustering removal upgrading-to-or-past-version-7-3-with-a-customized-log4j2-xml-file: Upgrading to or past version 7.3 with a customized log4j2.xml file ec-key-pair-issues-with-aws-cloudhsm-client-sdk-5: EC key pair issues with AWS CloudHSM Client SDK 5 improved-configuration-replication-compatibility: Improved configuration replication compatibility considerations-when-upgrading-to-8-0-or-later: Considerations when upgrading to 8.0 or later upgrading-to-or-past-version-8-0-from-version-6-2-or-below: Upgrading to or past version 8.0 from version 6.2 or below --- # Upgrade considerations The following changes between PingAccess versions might require additional steps during an upgrade. ## Removing support for Java 8 and 11 With continued product and hardware security module (HSM) *(tooltip: \
\

A dedicated cryptographic processor designed to manage and protect digital keys. HSMs act as trust anchors that protect the cryptographic key lifecycle by securely managing, processing, and storing cryptographic keys inside a hardened, tamper-resistant device.\

\
)* integration improvements, customers should migrate off of Java 8 and 11. Ping Identity removed Java 8 support from the qualification process in December 2023 and removed Java 11 support in December 2025. Learn more in [Installation requirements](../installing_and_uninstalling_pingaccess/pa_installation_requirements.html). ## Considerations when upgrading to 6.0 or later ## Performing a zero downtime upgrade from 6.0, 6.0.1, 6.0.2, or 6.0.3 to a later version If you're using PingAccess 6.0, 6.0.1, 6.0.2, or 6.0.3, zero-downtime upgrades to later versions might fail because of PKCE changes. To prevent this issue, edit your existing web sessions and enable PKCE support: 1. Click **Access** and then go to **Web Sessions > Web Sessions**. 2. Expand the web session and click the **Pencil** icon. 3. Click **Show Advanced**. 4. Click **Enable PKCE**. 5. Edit the web session. Click **Save**. 6. Repeat these steps for each web session. ### New templates for error and logout pages In PingAccess 6.1, we updated several error and logout page template files to modernize their appearance and remove Ping branding: * `general.loggedout.page.template.html` * `general.error.page.template.html` * `admin.error.page.template.html` * `policy.error.page.template.html` You can find more information about the templates in [User-facing page customization reference](../configuring_and_customizing_pingaccess/pa_user_facing_page_customization_ref.html). If you customized the template files previously, recustomize the new files. ### Upgrading to a PingAccess version released before your current version As of PingAccess 6.1, the upgrade utility can download missing reference files if connected to the internet. This simplifies upgrading to a PingAccess version that was released before your current version. For example, upgrading from PingAccess 7.3.4 (released May 2024) to 8.0.1 (released March 2024). If an internet connection is unavailable, you can use the following workaround. > **Collapse: Workaround** > > 1. Go to https\://pingone.s3.amazonaws.com/public_downloads/pingaccess/*\*/reference-files-*\*.zip to download the missing reference file automatically. > > For example: > > ``` > https://pingone.s3.amazonaws.com/public_downloads/pingaccess/7.3.4/reference-files-7.3.4.zip > ``` > > 2. In a new installation of the PingAccess version you want to upgrade to, create the following directory: > > ``` > _HOME>/upgrade/reference-files// > ``` > > For example: > > ``` > /upgrade/reference-files/7.3.4/ > ``` > > 3. Add the reference files to the upgrade utility manually by extracting their contents to the directory you created in the previous step. > > For example, extract the contents of the 7.3.4 reference files and add them to the upgrade utility in 8.0.1 manually. ### Using a proxied PingFederate deployment PingAccess 6.2 introduced the ability to configure a proxied PingFederate deployment through PingAccess. If you configured a similar deployment in an earlier version of PingAccess manually, you can continue to use it. However, if you plan to switch from a deployment that you configured manually to a proxied PingFederate deployment through PingAccess: * Review the configuration options in the proxied PingFederate deployment admin console. Verify that it can support your current configuration's use cases. * Remove any PingFederate-related applications before migrating the configuration. ### SPA support We removed the single-page application (SPA) support checkbox from the admin UI for **Web** applications in PingAccess 6.2. Consequently, all **Web** applications created in PingAccess 6.2 and later have SPA support enabled by default. The SPA support checkbox is still available for **API** applications and **Web + API** applications. You can find more information in [Application field descriptions](../pingaccess_user_interface_reference_guide/pa_application_field_descriptions.html). | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | If the default settings for SPA support with **Web** applications aren't compatible with your environment or with a specific application, you can [change the default authentication policy](../pingaccess_user_interface_reference_guide/pa_changing_the_default_authentication_challenge_policy.html) or [Configuring authentication challenge policies](../pingaccess_user_interface_reference_guide/pa_configuring_authn_challenge_policies.html). | PingAccess 7.1 added a system-provided authentication challenge policy that disables SPA support by default. This policy is useful if you aren't onboarding any new SPAs and don't have many SPAs in your current environment. Learn more in [Authentication](../pingaccess_user_interface_reference_guide/pa_authentication.html). ## Considerations when upgrading to 7.0 or later ### Runtime state clustering removal Support for runtime state clustering was removed in PingAccess 7.0. However, one benefit of runtime state clustering was that it enabled [rate limiting rules](../pingaccess_user_interface_reference_guide/pa_adding_rate_limiting_rules.html) to behave more consistently in a clustered environment. This was because runtime state clustering enabled all the engines in a cluster to know the total number of requests for a resource, not just the requests which that engine received. If you're using runtime state clustering with rate limiting rules, before upgrading to PingAccess 7.0 or later, you should either: * Configure a load balancer sitting in front of a PingAccess cluster to stick the session to a specific engine. This ensures that a single PingAccess engine node applies the rate limiting rule. Learn more in [Managing load balancing strategies](../pingaccess_user_interface_reference_guide/pa_load_balancing_strategies.html). * Tune down the **Max Burst Requests** interval on the rate limiting rule, following the *\*/*\* ratio. ### Upgrading to or past version 7.3 with a customized `log4j2.xml` file PingAccess 7.3 introduced a new `log4j-categories.xml` file to enable adjustment of the amount of detail included in PingAccess's logs. Learn more in [Configuring verbose logging in the admin console](../pingaccess_user_interface_reference_guide/pa_configuring_verbose_logging.html). If you've customized your `log4j2.xml` file, you must merge those customizations into the updated `log4j2.xml` file the first time you upgrade to PingAccess 7.3 or a later version. ### EC key pair issues with AWS CloudHSM Client SDK 5 As of PingAccess 7.3, PingAccess offers support for Amazon Web Services (AWS) *(tooltip: \
\

An Amazon subsidiary providing cloud computing platforms.\

\
)* CloudHSM Client SDK 5 instead of Client SDK 3. Client SDK 5 introduces an issue with elliptic-curve (EC) key pairs for all TLS handshakes, similar to the extant issue with TLS 1.3 for EC and RSA keys. As a result, you can create EC key pairs in PingAccess, but you can't assign them to a listener. ### Improved configuration replication compatibility PingAccess 7.3 introduced the ability for engine nodes and the replica administrative node to connect to an administrative node that's running a later version of PingAccess. This ability was backported to PingAccess 7.2.2 as well. Nodes running PingAccess 7.2.2 or later can replicate data that's relevant for the version of PingAccess that they're running from the administrative node. You can find more information on clustering and configuration data replication in [Clustering in PingAccess](../reference_guides/pa_clustering_ref_guide.html). This ability to maintain compatibility reduces the possibility for outages caused by outdated information, providing more flexibility during the upgrade process for those with large scale or hybrid environments. It also improves stability for containerized deployments because clustered engine nodes don't need to maintain their replication data throughout a restart. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------- | | | You should still finish upgrading the engine nodes as soon as possible and avoid making configuration changes until all engines have been upgraded. | ## Considerations when upgrading to 8.0 or later ### Upgrading to or past version 8.0 from version 6.2 or below If you have PingAccess 6.2 or below, you cannot upgrade directly to PingAccess 8.0. You must upgrade to a version above 6.2 first, and then upgrade to 8.0. This is because in PingAccess 8.0, an outdated H2 JAR file was removed, and PingAccess 6.2 and below use an H2 embedded database.