Upgrade rollout is a partner and customer collaboration. Partners need staged release discipline; customers need sandbox validation before allowing production upgrades.
- Test the new version in a representative sandbox
Both partners and customers benefit from a sandbox that mirrors the production customisations. Run the upgrade there first, validate behaviour, and document any breaking changes.
- Review the partner's release notes
Read every entry in the partner's release notes. Pay special attention to schema changes, deprecation announcements, and any required post-upgrade steps.
- Schedule the production upgrade in a change window
For push upgrades, partners schedule against a quiet window. For pull upgrades, customers schedule against their own change calendar. Avoid mid-quarter close days.
- Run post-upgrade validation
After the upgrade lands, validate critical flows: page renders, automation, integrations, and any user-facing surfaces. Catch regressions in the first 24 hours when it is easiest to roll back.
- Communicate to affected users
For visible changes, notify the user community before and after the upgrade. Most upgrade complaints come from users surprised by changed behaviour, not from technical regressions.
- Push upgrades affect the entire selected customer set at the scheduled time. Test against representative customisations or break customers en masse.
- Customer customisations on managed objects survive upgrades, but custom validation rules on managed records can fail if the upgrade changes underlying schema.
- Patch upgrades go through faster review but are constrained; do not use them to ship structural changes that need a major release.
- Failed upgrades leave the customer on the previous version. Rollback is not always clean; pre-upgrade validation is the right insurance.