Software Transition Plan: [System name]

Software Transition Plan (STrP) describing the resources a support agency needs to maintain delivered software and the developer's plan for handing that support over: facilities, hardware, software, documentation, personnel, recommended procedures, training, anticipated changes and the transition schedule. The section numbering follows the MIL-STD-498 Data Item Description DI-IPSC-81429 (Software Transition Plan, 5 December 1994; public domain). Replace every [bracketed] value and every row marked Example.

1. Scope

1.1 Identification

This plan applies to [System name] version [x.y] and its software items [CSCI-01 Mission planning server 2.3, CSCI-02 Operator web client 2.3, CSCI-03 Data exchange gateway 1.1].

1.2 System overview

[System name] [purpose]. Sponsor: [sponsor]. Acquirer: [acquirer]. Users: [users]. Developer: [developer]. Support agency after transition: [support agency]. Operating sites: [sites]. [History, for example: developed 2025-2026 in three builds; in operation at nine centres from YYYY-MM-DD.]

1.3 Document overview

This plan identifies the resources needed to support the deliverable software, recommends support procedures, sets out training, lists likely areas of change and schedules the transition. [Security or privacy considerations.]

1.4 Relationship to other plans

2. Referenced documents

3. Software support resources

The support agency needs the resources below to maintain the software and to produce, test and release modifications.

3.1 Facilities

3.2 Hardware

Security considerations: [for example, test servers must sit in the acquirer's restricted network segment].

3.3 Software

3.4 Other documentation

3.5 Personnel

The support agency needs [number] staff with the skills below. Estimates are based on development staffing of [14 FTE] at peak and [3 FTE] in the last two months of warranty work.

3.6 Other resources

[Consumables and other items, with type and number to acquire.] Example: two hardware security tokens for release signing; a test account on the national incident system; annual budget of [amount] for cloud test environments.

3.7 Interrelationship of components

The figure shows how the support resources work together to produce a modified release.

4. Recommended procedures

5. Training

6. Anticipated areas of change

7. Transition planning

7.1 Activities, roles and resources

7.2 Schedule and milestones

The schedule below is aligned with the contract master schedule.

7.3 Installation and checkout in the support environment

1. [Install tools from section 3.3 at the versions listed and record licence keys.]
2. [Restore the source repository and confirm the tagged baseline matches the SVD.]
3. [Run the CI pipeline and confirm the build reproduces the delivered artefacts (identical checksums for reproducible components).]
4. [Run the regression suite in the test lab; all tests must pass.]
5. [Make, test and release a trivial change end to end, led by support staff.]

Exit criteria for transition acceptance: [all deliverables received and checked; support staff completed training; at least [three] problem reports fixed by support staff during joint support; open problem reports handed over with analysis].

8. Notes

Appendixes

Standard and licence note

Based on MIL-STD-498 Data Item Description DI-IPSC-81429, Software Transition Plan (STrP), dated 5 December 1994, a US Department of Defense document approved for public release (public domain). The section numbering follows its content requirements, written in original wording. A later revision (DI-IPSC-81429A, 2000) exists; check which revision your contract cites. Template licence: MIT.