--- title: Upgrade considerations description: When upgrading, you must consider factors such as the scope of the update, the PingAuthorize version from which you're upgrading, and your installed Java version if you aren't using Docker. component: pingauthorize version: 10.2 page_id: pingauthorize:upgrading_pingauthorize:paz_upgrade_consids canonical_url: https://docs.pingidentity.com/pingauthorize/11.1/upgrading_pingauthorize/paz_upgrade_consids.html llms_txt: https://docs.pingidentity.com/pingauthorize/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-08-17T00:00:00Z superseded_by: https://docs.pingidentity.com/pingauthorize/11.1/upgrading_pingauthorize/paz_upgrade_consids.html section_ids: general-considerations: General considerations upgrade-considerations-introduced-in-pingauthorize-10-1: Upgrade considerations introduced in PingAuthorize 10.1 resolving-issues-with-copying-policy-elements: Resolving issues with copying policy elements paz_upgrade_consids_100: Upgrade considerations introduced in PingAuthorize 10.0 camel-upgrade: Camel upgrade sni-host-name-checking-disabled-by-default: SNI host name checking disabled by default upgrading-a-pingauthorize-server-running-java-8-to-version-10-0: Upgrading a PingAuthorize server running Java 8 to version 10.0 upgrading-a-pingauthorize-policy-editor-running-java-8-to-version-10-0: Upgrading a PingAuthorize Policy Editor running Java 8 to version 10.0 --- # Upgrade considerations When upgrading, you must consider factors such as the scope of the update, the PingAuthorize version from which you're upgrading, and your installed Java version if you aren't using Docker. ## General considerations For Docker deployments, the upgrade process involves downloading and deploying the latest containers. For manual installations, the upgrade process involves downloading and extracting a new version of the PingAuthorize Server `.zip` file on the server and running the update utility with the `--serverRoot` or `-R` option value from the new root server pointing to the installation. Consider the following when upgrading: * The update affects only the server being upgraded. The process doesn't alter the configuration of other servers, so you must update those servers separately. * The update tool verifies that the installed Java version meets the new server requirements. To simplify the process, install the Java version supported by the new server before running the tool. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | You can find additional considerations in [Best Practices: Planning your upgrade](https://docs.pingidentity.com/solution-guides/best_practice_guides/htg_plan_software_upgrade.html). | ## Upgrade considerations introduced in PingAuthorize 10.1 ### Resolving issues with copying policy elements After upgrading from a version of PingAuthorize earlier than 10.1 and attempting to delete a copy of a Policy Editor element, that copy might persist in the UI and return an error when selected. To completely remove deleted copies from the Policy Editor, follow the steps in [Deleting persistent copies](../pingauthorize_policy_administration_guide/paz_entity_copy_troubleshooting.html). ## Upgrade considerations introduced in PingAuthorize 10.0 ### Camel upgrade PingAuthorize 10.0 now supports Apache Camel 3.21.2. The limitations on using Apache Camel to connect policy information points (PIP) introduced in PingAuthorize 9.3 still apply. For more information on working around these limitations, see [Enabling Camel service connections](../pingauthorize_policy_administration_guide/paz_camel_enable.html). For details on upgrading from Apache Camel 2.x to 3.0, see Apache's [migration guide](https://camel.apache.org/manual/camel-3-migration-guide.html). ### SNI host name checking disabled by default If you're upgrading to PingAuthorize 10.0 or later with an existing configuration that has SNI host name checks enabled, you might encounter an issue when using a host name not found in the key store. To migrate an existing configuration from an earlier version of PingAuthorize and disable SNI host name checks, add the following to your `configuration.yml` file: ``` server: ... applicationConnectors: - type: "https" ... disableSniHostCheck: "${PING_DISABLE_SNI_HOSTNAME_CHECKS:-true}" ``` This change also introduces a new `setup` option, `--disableSniHostnameChecks`, that you can set to `false` to enable SNI host name checks. ### Upgrading a PingAuthorize server running Java 8 to version 10.0 Support for Java 8 has been deprecated, and upgrading to Version 10.0 of PingAuthorize will fail unless you are running Java 11 or 17. If you are upgrading a server running Java 11 or 17 to version 10.0, you can proceed with the server upgrade after confirming one of the following: * Your default Java installation is a supported version. * You are pointing one of the following environment variables to a supported version of Java: * `JAVA_HOME` * `UNBOUNDID_JAVA_HOME` The `java.properties` configuration file won't be modified if you upgrade the server to version 10.0 under the previous conditions. | | | | - | ------------------------------------------------------------------------------------------------------------------------ | | | The upgrade process from a server instance running Java 8 is not automatic and will fail. Java 8 is no longer supported. | * Updating to a supported Java version before upgrading the server Before upgrading the server to version 10.0, you must install either Java 11 or 17. Learn more in [System requirements](../installing_and_uninstalling_pingauthorize/paz_system_requirements.html). Upgrading to version 10.0 after updating Java requires changes to the `java.properties` file. Select one of the following options for handling how `java.properties` gets modified. Where a Java version is specified, substitute your installed, supported Java version. * Before updating the server, convert the file manually: 1. Edit `config/java.properties` file to convert the JVM parameters to be specific to Java 11. 2. Run `bin/jds/javaproperties` to make the changes go into effect. * Before upgrading the server, create a new file: 1. Rename the old `java.properties` file. 2. Run the `bin/dsjavaproperties` command to initialize a new Java 11 `java.properties` file. For this option, run the following command: ``` bin/dsjavaproperties --initialize ``` 3. Use the generated file as a reference for converting the original `java.properties` file. Alternatively, upgrade the server using the generated file, and then restore your customized settings afterward. * Allow the upgrade to replace the file: 1. Upgrade the server to version 10.0. The upgrade process will overwrite the `java.properties` file and the original file will be saved as `java.properties.old`. A `java.properties.change` file will also be created, containing the diff output between the new and old `java.properties` files. 2. Restore or convert the JVM settings that were overwritten during the upgrade process. ### Upgrading a PingAuthorize Policy Editor running Java 8 to version 10.0 If you are upgrading from a PingAuthorize Policy Editor instance running Java 8, you must export the `JAVA_HOME` environment variable by running the following command: ``` export JAVA_HOME=$JAVA11_HOME ``` | | | | - | ---------------------------------------------------------------------------------------------------------------------------- | | | You must perform this export before running any scripts in PingAuthorize 10.0, including `bin/setup` and `bin/start-server`. |