Convert the SSP without breaking the one your contracts still need.

Before you touch the document

• Confirm the SSP is convertible. A convertible SSP has one addressable implementation statement per requirement. If yours is narrative prose organized by chapter, restructure it under Rev. 2 first, because the crosswalk maps one statement at a time.
• Freeze a Rev. 2 baseline copy. Version and archive the current SSP as the of-record document for active Rev. 2 contracts. Conversion happens on a branch, never in place.
• Inventory which contracts need which view. Your contract mix decides which versions of the SSP the conversion must produce.

The five conversion passes

• Pass 1: structure mapping. Rebuild the skeleton on the 17 Rev. 3 families. Two moves catch people out: the SSP requirement itself moves into the new Planning family, and Security Assessment becomes Security Assessment & Monitoring.
• Pass 2: statement conversion. Walk the crosswalk requirement by requirement. Carried requirements keep their statements with updated citations; consolidated requirements get merged statements that preserve each parent's substance; new requirements get placeholders that state the gap honestly.
• Pass 3: disposition records. Every requirement gets a recorded disposition: satisfied as-is, satisfied with modification, gap (with POA&M entry), or not applicable with rationale. The disposition table becomes the audit trail for the transition.
• Pass 4: ODP embedding. Each implementation statement that touches a parameter cites the ODP register value inline. An SSP that contradicts its own register fails the easiest check an assessor can run.
• Pass 5: evidence re-pointing. Statements reference evidence by Rev. 3 assessment-objective index (see the evidence guide), so the document and the artifact library stay in sync.

Maintaining both views

Until your last Rev. 2 contract closes out, both documents have to stay accurate at the same time. The pattern that works makes the Rev. 3 SSP primary and maintains the frozen Rev. 2 SSP as a derived view, with changes flowing through the crosswalk so each update lands in both. Two documents edited independently diverge within a quarter. The full operating model is in dual-baseline operations.