Plan the retirement of a connected service before customers depend on it

A connected vehicle function can rely on services outside the vehicle: identity systems, data processing, content delivery or a supplier's platform. Those services can change independently of the hardware customers own. A product strategy therefore needs to consider how the function will remain supported when an external dependency is replaced or retired.

Service retirement is not only an infrastructure decision. It can alter a customer's experience, the availability of maintenance information or the organisation's ability to update software. Plan the transition while the dependency is being introduced, when the product's promises are still being shaped.

Map the dependency to a customer outcome

Identify what the service provides and which vehicle functions or operating processes rely on it. Separate optional enhancement from a dependency required for ordinary operation or maintenance. Describe the experience when connectivity is absent and when the service is permanently unavailable.

The Eclipse SDV charter includes around-vehicle systems within its scope. SPDX offers structured component relationships. These provide context for looking beyond an executable, but the manufacturer needs a specific inventory of the service relationships that affect its supported product.

Record ownership and replacement assumptions

For each relevant dependency, assign an owner who understands the contract, technical interface and support implications. Identify whether the organisation expects to renew, replace or eventually retire the service. An undefined assumption of indefinite availability is a product risk even when the current service works well.

Examine portability of the information and behaviour needed for replacement. A new provider may use different identifiers, permissions or data models. Determine what migration would require and which capabilities cannot be transferred directly. This supports a realistic exit plan without pretending that every service is interchangeable.

Define the transition for installed vehicles

Consider whether vehicles need updated software or configuration to use a replacement service. Include older versions and vehicles that reconnect after a long absence. A backend migration that looks complete from the cloud can leave a supported population unable to communicate.

Decide how relevant accounts, settings and histories are handled through the transition, with the necessary specialist review for the actual data and arrangements. Preserve information needed for maintenance and investigation. Do not let a service shutdown accidentally delete the evidence required to support vehicles that remain in use.

Review the product promise before launch

Customer-facing descriptions should match the supported arrangement and the limitations the business can explain. If a function depends on a service, the organisation needs an accountable plan for changes to that dependency. Product, engineering and service teams should agree the plan together.

Exercise a representative migration or retirement scenario before it becomes urgent. Check technical feasibility, customer support and evidence retention as one workflow. A credible connected product has a future beyond its launch demonstration. Planning service retirement gives the manufacturer a way to preserve that future when suppliers, platforms and commercial priorities change.