Jump to text
On this page
Copy and source
Published source confirmed at last check

Source changed 2026-10-14 19:58:00 UTC · snapshot created 2026-10-14 19:58:38 UTC · last check 2026-10-15 01:50:10 UTC

CUST.8:4 - Solution

CUST.8:4.1 - Recover what is changing and who relies on it

Describe the proposed family change in terms of a useful result: a new supported variation, a replacement common operation, a changed provision form, a narrower support promise or retirement. Compare it with the present family, including local residues that still receive promised support.

Find actual consumers through the available agreements, configurations, delivery records, copied materials and observations of use. Include infrequent work and future obligations such as reproducing an earlier result. Absence from recent usage does not establish absence of reliance.

For each materially different use, recover what the recipient must still obtain, the inputs and meanings they depend on, the work they perform, the help they receive and the authority under which the arrangement can change. Keep uncertainty about an unobserved population visible. A plausible class of affected uses is enough to discover a problem; it is not proof that every consumer has been found.

CUST.8:4.2 - Separate the consequences before choosing the transition form

Compare old and proposed provision along the dimensions that change the customer’s result. These may include result meaning, permitted inputs, interface behavior, acceptance evidence, performer preparation, timing, access, payment or funding, and continuing support. Do not impose every dimension when it has no bearing on the change.

Obtain technical compatibility through SYSE.27 — Evolve Platform Interfaces and Contribution Paths when a platform interface or contribution path is involved. Receive the supported combinations, known losses and maintenance conditions. A preserved file format or successful request is insufficient if the recipient interprets the result differently.

Use MKT.11 — Align Promises, Partners and Execution when promises, partners and execution no longer align. Receive a feasible promise and actual provision arrangement. A unilateral provider preference does not supply the customer’s agreement or another party’s authority.

A rights or permitted-use change can defeat a technically feasible transition. Carry the intended recipients, materials and purposes into the applicable permission decision. Where customer-programme materials are involved, use the permitted-contribution treatment in MKT.14:4.3 within MKT.14 — Develop and Change a Programme for Selected Customer Organisations; where inquiry evidence is involved, use MKT.12:4.6 within MKT.12 — Investigate a Customer or Market Question for a Decision. Obtain other qualified professional contributions when the case requires them.

CUST.8:4.3 - Construct alternatives that preserve a complete receiving result

Change formConstruct the continuationBoundary to settle
Compatible extensionPreserve supported old use while making a new variation obtainable.Whether defaults, meanings, support and resource demand remain compatible.
Supported profile or coexistenceKeep distinct old and new conditions explicit and provide both for an attainable period.Who maintains each path and which combinations can operate together.
Adapter or conversionSupply a qualified translation or transformation with its acceptance and exception handling.Lost information, changed effects, partial failure and continuing maintenance.
Explicit migrationSupply the receiving provision and the work by which each selected use reaches it.Preparation, participation, authority, recovery and the point at which old provision can end.
Separate offeringGive materially different results their own supportable provision rather than force them into one family.Shared contributions can remain shared without promising interchangeability.
Retained arrangement or no changeContinue the supported local or common provision within its actual conditions.Its remaining burden and any later condition that makes continuation untenable.

Build the receiving path before scheduling its adoption. Name the new result, preparation, available means, actual performers and assistance. Work backward to the old dependencies that remain necessary until that result is obtainable. If a required conversion, explanation or support contribution is missing, construct or obtain it; a migration date does not fill that gap.

For an engineered platform migration or retirement, use the complete SYSE.29 — Decide Whether and How to Migrate or Retire a Supported Platform Path. It supplies affected-use recovery, transition alternatives, an executable increment, receiving-use and failure checks, and explicit retirement scope. Bring its qualified technical transition into the wider customer arrangement. CUST retains the family choice, promise alignment and resource decision; it does not replace that engineering treatment.

CUST.8:4.4 - Make the selected transition feasible as part of continuing service

Choose the next increment by dependencies and available resources. Several customers may need to move together because they share state or an operating window; others can move independently. The smallest useful increment preserves a complete receiving result, not necessarily one customer or one component.

Agree the work with the parties who must perform it. Include customer preparation, permitted data or material transfer, training through actual use, acceptance, support and the disposition of local adaptations. Retain a qualified return path only where it really restores the required result. Where effects are irreversible, use the supported forward repair, restoration with stated loss or authorized interruption; do not promise a generic rollback.

Compare ordinary service, transition, coexistence and later support together through CUST.7. A specialist cannot be counted as fully available for each at the same time. If the joint demand is infeasible, change the increment, obtain capacity, narrow the new promise or defer the change.

Explain the transition at the customer’s point of use: what changes, what they must do, what remains supported, when assistance is available and how to stop a failed move. Information is useful only when the receiving party can act on it.

CUST.8:4.5 - Qualify the changed result and expand only within its conditions

Before widening reliance, perform an attainable trial or an explicitly labelled rehearsal of the selected receiving use. Check the actual result and the change-dependent failure branch. Reuse an adequate technical or operational result under its conditions rather than repeat it for each document.

Different questions need different evidence. A compatibility test can establish an exercised old/new behavior. A recipient’s completed task can establish that task under the trial conditions. Actual transition requires evidence that the selected uses moved. None of these alone authorizes ending an obligation.

When a trial fails, preserve unaffected service and return the specific defect: family assumption, unavailable preparation, inadequate conversion, missing permission, disputed promise or scarce support. An exception is not automatically a reason to abandon the common improvement; nor is a successful ordinary case enough to widen an unsupported variation.

CUST.8:4.6 - End only the reliance that has a justified disposition

For each remaining supported use, establish an actual continuation: qualified transfer, bounded continued support, an obtainable outside arrangement or an authorized end with its consequences understood. Keep unresolved use explicit rather than counting it as migrated.

Distinguish ending new sales, stopping new requests, removing a path, withdrawing support and disposing of retained material. Their permissions, times and consequences may differ. Update the family description and customer-facing instructions to match actual availability.

Return what changed to the receiving work. CUST.3 receives the supported family and exclusions; CUST.6 receives the revised delivery and support method; CUST.7 receives the observed transition and coexistence burden. If the change reveals a false general assumption about compatibility or transfer, also revise the relevant practice knowledge. A repaired customer configuration alone does not correct that assumption.