Upgrade guide
Quick answer
Upgrading IdentityIQ means moving to a new version or patch: review the release notes, back up the database and files, apply the upgrade in a lower environment first, run the schema and object updates, then retest every customisation, rules, workflows and connectors, before promoting to production.
Key takeaways
- Read release notes for breaking changes first
- Back up database and files before starting
- Upgrade a lower environment before production
- Run schema and object updates in order
- Retest all customisations after upgrade
Upgrading SailPoint to a new version brings new capabilities, fixes and continued support, but it must be planned and tested, because it touches the application, the database schema and any customisations you have built. This page covers doing it safely.
What an upgrade involves
- Applying the new application version (WAR / platform update).
- Running the provided database schema upgrade scripts, never hand-editing the schema.
- Reviewing customisations (rules, workflows) for compatibility.
- Regression-testing core flows before production.
A safe upgrade approach
- Read the release notes and compatibility matrix (Java, app server, database).
- Upgrade a lower environment first and test thoroughly.
- Back up the database and configuration before upgrading production.
- Have a tested rollback plan.
Why customisations matter
The biggest upgrade risk is usually custom code. Rules and workflows written against older APIs may need adjustment. Reviewing and testing them in a lower environment is what prevents an upgrade from breaking production behaviour.
Common pitfalls
- Skipping the schema upgrade scripts or editing the schema by hand.
- Not testing customisations against the new version.
- No backup or rollback plan before upgrading production.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
Before upgrading you should first?
- A. Retest customisations. Regression-test rules, workflows and connectors.
- B. After a lower environment. Prove the upgrade in dev/test before production.
- C. Read the release notes. Release notes reveal breaking changes and deprecations.
Show answer
C. Read the release notes. Release notes reveal breaking changes and deprecations.
Read the release notes. Release notes reveal breaking changes and deprecations.
Upgrades should be applied to production?
- A. Read the release notes. Release notes reveal breaking changes and deprecations.
- B. Retest customisations. Regression-test rules, workflows and connectors.
- C. After a lower environment. Prove the upgrade in dev/test before production.
Show answer
C. After a lower environment. Prove the upgrade in dev/test before production.
After a lower environment. Prove the upgrade in dev/test before production.
After upgrading you must?
- A. Read the release notes. Release notes reveal breaking changes and deprecations.
- B. Retest customisations. Regression-test rules, workflows and connectors.
- C. After a lower environment. Prove the upgrade in dev/test before production.
Show answer
B. Retest customisations. Regression-test rules, workflows and connectors.
Retest customisations. Regression-test rules, workflows and connectors.