Answer
Treat a multi-version jump as needing its own lifecycle plan — database migration steps, deprecated feature removal, and customization compatibility can all compound across skipped releases in ways a single-version upgrade wouldn't show. Read the upgrade notes for every version in the range, not just the start and end points.
Work through these checks
- Record source and target releases, installed components, customizations, and integration/report consumers. Verify the supported upgrade path in the release-specific installation documentation.
- Review release notes and deprecations across the complete version range. Map each affected feature to a source change or test case.
- Rehearse on a representative restored nonproduction environment. Record migration logs, invalid objects, data reconciliation, permissions, and affected page/API behavior.
- Test restart and recovery before scheduling the real change. Retain acceptance evidence and a named recovery owner; do not infer compatibility from a successful build alone.