# 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*.

<!--
Guidance: How to use this template
- Write for the support agency: the team that will fix, change, build,
  test and release the software after the developer leaves. Ask them to
  review the draft.
- Be specific about status for every resource: acquirer-furnished, to be
  delivered, already held by the support agency, or to be acquired.
- Licences and data rights are where transitions fail. Confirm them early
  for every tool and component.
- Keep the DID numbering. Tailored-out paragraphs keep their heading with
  "This paragraph has been tailored out." and a reason.
-->

| Field | Value |
|---|---|
| Document number | [STRP-SYSTEM-001] |
| System / software | [System name] ([abbreviation]), [software item IDs and versions] |
| Developer | [Organisation] |
| Support agency | [Organisation or team] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Prepared by | [@author] |
| Approved by | [@developer-pm], [@support-agency-lead], [@acquirer] |
| Contract / CDRL | [Contract no.], [CDRL item or "Not applicable"] |
| Last updated | YYYY-MM-DD |

## 1. Scope

<!-- Guidance: Identify the system and software, summarise the system and its history, describe this document and its relation to other plans. -->

### 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

| Plan | Relationship |
|---|---|
| *Example:* Software development plan SDP-01, section 5.13 | Summarises transition preparation; this plan gives the detail |
| *Example:* Software maintenance plan SMP-01 | Prepared by the support agency; starts where this plan ends |
| *Example:* Configuration management plan SCMP-01 | Baselines handed over under its procedures |
| [Plan] | [Relationship] |

## 2. Referenced documents

<!-- Guidance: List number, title, revision and date of referenced documents, and sources for those not publicly available. -->

| Number | Title | Revision | Date | Source |
|---|---|---|---|---|
| *Example:* SVD-2.3.0 | Software Version Description (support site) | 1.0 | YYYY-MM-DD | Document portal |
| *Example:* SDD-01 | Software Design Description (as built) | 2.3 | YYYY-MM-DD | Document portal |
| *Example:* SPS-01 | Software Product Specification | 2.3 | YYYY-MM-DD | Document portal |
| [Number] | [Title] | [Rev] | YYYY-MM-DD | [Source] |

## 3. Software support resources

<!-- Guidance: Identify everything needed to control, copy and distribute the software and its documentation, and to specify, design, implement, document, test, evaluate, control, copy and distribute changes. -->

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

### 3.1 Facilities

| Facility | Purpose | Status |
|---|---|---|
| *Example:* Secure office space for 6 engineers | Daily support work with access to personal data | Held by support agency |
| *Example:* Test lab with two dispatcher workstations | Reproduce operator issues | To be delivered (moved from developer site) |
| [Facility] | [Purpose] | [Status] |

### 3.2 Hardware

| Item | Model / configuration | Rationale | Manual | Status | Supply and support |
|---|---|---|---|---|---|
| *Example:* Build and test servers | 4 x cloud VMs, 8 vCPU, 32 GB | Match CI capacity used in development | Cloud provider docs | Acquirer-furnished | Current; supported for life of contract |
| *Example:* Radio gateway simulator | [Vendor model], firmware 4.2 | Needed to test CSCI-03 without live radios | [Manual ref] | To be acquired | Available; 8-week lead time |
| [Item] | [Model] | [Rationale] | [Manual] | [Status] | [Supply, support, licence] |

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

### 3.3 Software

| Item | Version | Rationale | Status | Licence and data rights | Vendor support |
|---|---|---|---|---|---|
| *Example:* CI server and pipelines | [Version] | Builds and signs releases | To be delivered (pipeline as code) | Open source | Community |
| *Example:* Compiler / runtime | [Language] [version] | Required to build CSCI-01 | Support agency has | Open source | Supported to YYYY-MM |
| *Example:* Map rendering SDK | 3.8 | Used by CSCI-02 | To be acquired | Commercial; licence to transfer to support agency | Supported; renewal YYYY-MM-DD |
| *Example:* Test data generator | 1.2 | Creates anonymised test data | To be delivered | Developed under contract; acquirer has unlimited rights | Developer for 3 months |
| [Item] | [Version] | [Rationale] | [Status] | [Licence] | [Support] |

### 3.4 Other documentation

| Document | Identifier / version | Reason needed | Status | Where to obtain |
|---|---|---|---|---|
| *Example:* Software Product Specification | SPS-01 2.3 | Source listings and build instructions | To be delivered | Document portal |
| *Example:* Software Test Description | STD-01 2.3 | Regression test cases | To be delivered | Repository |
| *Example:* Support manual | SM-01 1.0 | Build, deploy, diagnose | To be delivered | Document portal |
| *Example:* Vendor SDK manual | [Ref] | Map SDK usage | To be acquired | Vendor portal |
| [Document] | [ID] | [Reason] | [Status] | [Source] |

### 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.

| Role | Number | Skills and level | Clearance |
|---|---|---|---|
| *Example:* Software engineer (server) | 2 | [Language], PostgreSQL, messaging; mid to senior | [Level] |
| *Example:* Software engineer (client) | 1 | TypeScript, web accessibility | [Level] |
| *Example:* Test engineer | 1 | Test automation, performance testing | [Level] |
| *Example:* Release / configuration engineer | 0.5 | CI pipelines, container registry | [Level] |
| [Role] | [Number] | [Skills] | [Clearance] |

### 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.

```mermaid
flowchart LR
  REPO["Source repository"] --> CI["CI build and test"]
  TOOLS["Compilers and SDKs"] --> CI
  CI --> REG["Signed artefact registry"]
  CI --> LAB["Test lab and simulators"]
  LAB --> REL["Release approval"]
  DOCS["Support documentation"] --> REL
  REG --> REL
  REL --> SITES["Operational sites"]
```

## 4. Recommended procedures

<!-- Guidance: Share procedures, advice and lessons learned the developer recommends to the support agency. Practical tips matter more than generic process. -->

| Topic | Recommendation |
|---|---|
| *Example:* Building releases | Always build from a tagged commit through CI; local builds are not reproducible because of signing |
| *Example:* Database changes | Use forward-only, backward-compatible migrations; we have never needed a down migration |
| *Example:* Gateway testing | Run the radio simulator soak test for at least 8 hours before any gateway release; most defects appeared after 4 hours |
| *Example:* Dependency updates | Monthly patch cycle; read the map SDK release notes, as minor versions have broken styling twice |
| [Topic] | [Recommendation] |

## 5. Training

<!-- Guidance: Plan training for support personnel: schedule, duration, location, split between classroom and hands-on, and familiarisation with both the operational software and the support software and host system. -->

| Course | Audience | Schedule and duration | Location | Classroom / hands-on | Content |
|---|---|---|---|---|---|
| *Example:* System and architecture overview | All support staff | YYYY-MM-DD, 1 day | Support agency site | Classroom | Operational use, architecture, data flows |
| *Example:* Operational software familiarisation | Engineers, testers | YYYY-MM-DD, 2 days | Test lab | Hands-on | Planning workflows, admin functions, logs |
| *Example:* Support environment and build | Engineers, release engineer | YYYY-MM-DD, 2 days | Remote and lab | Hands-on | Repository, CI, signing, deployment, rollback |
| *Example:* Shadowing | Engineers | 4 weeks | Mixed | Hands-on | Paired fixes of real problem reports |
| [Course] | [Audience] | [Schedule] | [Location] | [Type] | [Content] |

## 6. Anticipated areas of change

<!-- Guidance: Describe the parts of the software most likely to change and why, so the support agency can staff and plan for them. -->

| Area | Expected change | Driver | Likely size |
|---|---|---|---|
| *Example:* Gateway (CSCI-03) | Schema v4 for national incident system | Announced by other contractor for YYYY | Medium |
| *Example:* Region data | Boundary updates twice a year | Administrative changes | Small, data only |
| *Example:* Map SDK | Major version upgrade | Vendor end of support YYYY-MM | Medium |
| *Example:* Reporting | New statutory report | Regulation change | Medium |
| [Area] | [Change] | [Driver] | [Size] |

## 7. Transition planning

<!-- Guidance: Describe every transition activity, who does it, the resources and their sources, the schedule compatible with the master schedule, and procedures for installing and checking out deliverables in the support environment. -->

### 7.1 Activities, roles and resources

| ID | Activity | Responsible | Supporting | Resources and source |
|---|---|---|---|---|
| TR-01 | *Example:* Transition planning meetings | Developer PM | Support lead, acquirer | Meeting rooms; developer |
| TR-02 | *Example:* Prepare items for delivery (source, tools, docs) | Developer CM | Engineering lead | Repository export; developer |
| TR-03 | *Example:* Package, ship, install and check out support environment | Developer release engineer | Support release engineer | Cloud accounts; acquirer |
| TR-04 | *Example:* Install and check out operational software at support site | Support agency | Developer | Test lab; support agency |
| TR-05 | *Example:* Train support personnel | Developer | Support lead | Section 5 courses |
| TR-06 | *Example:* Joint support period | Support agency | Developer | 2 developer engineers for 8 weeks |
| TR-07 | *Example:* Transition acceptance review | Acquirer | Both | Exit criteria in 7.3 |

### 7.2 Schedule and milestones

The schedule below is aligned with the contract master schedule.

```mermaid
gantt
  title Software transition schedule
  dateFormat YYYY-MM-DD
  Planning meetings          :t1, 2026-09-01, 2w
  Prepare deliverable items  :t2, after t1, 4w
  Support environment setup  :t3, after t1, 5w
  Training                   :t4, after t3, 3w
  Joint support period       :t5, after t4, 8w
  Transition acceptance      :milestone, m1, after t5, 0d
```

### 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

<!-- Guidance: Background, rationale, glossary and an alphabetical list of acronyms. -->

| Term | Meaning |
|---|---|
| CSCI | Computer software configuration item |
| SPS | Software product specification |
| STD | Software test description |
| Support agency | Organisation responsible for maintaining the software after transition |

## Appendixes

<!-- Guidance: Lettered appendixes for long lists such as full tool inventories, referenced from the body. -->

| Appendix | Content | Referenced in |
|---|---|---|
| A | *Example:* Full tool and licence inventory | 3.3 |
| B | *Example:* Training materials list | 5 |

## 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.