6.9.5 Replaceability measures

What this heading covers

Replacement is a migration, and its evidence is a completed scenario, not an interface similarity. The measure should name the product being replaced, the data and integrations involved, and the criteria for a successful replacement. It often matters more to an acquirer than to a developer, which makes it a good family for a tender response. The reverse direction, being replaced, is part of the definition and is often forgotten.

Record position: family 35 of 40 in clause 6, under 6.9 Flexibility, which carries 4 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.9.5 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the replacement scenarios completed within the stated criteria as the numerator over the scenarios attempted. Record the data migrated, the integrations switched and the user impact. A reverse test, restoring the original product, is a second measure.

What to put in place before publication

1. Name the product being replaced and the success criteria.
2. Test the reverse direction as well as the forward one.

Evidence to keep

Two questions to ask

• Which product is being replaced, and what data and integrations move?
• Was the reverse replacement tested?

Where teams usually fall short

• An interface compatibility statement presented as replaceability.

What the number cannot tell you

It cannot tell you whether the replacement is desirable. It measures feasibility, not the business case, and a feasible replacement can still be the wrong move for the organisation.

What happens next

Safety is the last characteristic and the one added in the 2023 model. Read the five families as a set.