Strategy

Platform Deprecation

Strangler-fig approach to legacy removal. Facade-first migration preserving operational continuity while progressively replacing legacy dependencies.

Decision neededUpdated 16 Mar 2026

Why this matters

Legacy systems cannot be switched off without a verified replacement path. The deprecation strategy determines migration risk, dual-running costs, and the transformation timeline.

What this informs

Phase 1 mobilisation scope, integration layer investment, and the sequence in which legacy systems are retired.

What remains unresolved

Steering committee has not yet confirmed the strangler-fig approach. Facade layer technology selection is outstanding.

Legacy Systems

Approach

Strangler-fig

Phases

Estimated Duration

18 months

Status

Decision needed

Deprecation Pattern

Strangler-Fig Pattern

Step 1

Wrap First

Build API facade layer around legacy systems. New consumers integrate with the facade, not directly with legacy. Legacy continues to operate unchanged.

Foundation

Step 2

Replace Later

Progressively replace legacy implementations behind the facade. New services take over domain by domain. Facade routes traffic to new implementations.

Migration

Step 3

Retain Temporarily

Keep legacy systems running during transition for rollback capability. Decommission only after new implementations are validated under production load.

Optimisation

State Transitions

Current State

Tightly coupled legacy systems

Database-level integrations

No abstraction layer

Manual workarounds compensate for gaps

Transition State

Facade layer wraps legacy APIs

New consumers use facade contracts

Dual-running legacy + new services

Domain-by-domain migration

Target State

Domain-driven service boundaries

API-first integration contracts

Legacy systems decommissioned

Composable architecture operational

Systems Targeted

System	Current Status	Strategy	Target Date	Dependencies
Service Operations Platform (Siebel)	Legacy	Replace via facade	2027-Q2	SAP integration layer, domain API contracts
Dealer Portal (Sitecore)	Legacy	Replace with composable DXP	2027-Q1	New experience layer, WeChat integration
Manual processes	Operational	Automate through new services	2027-H2	Domain services, AI capabilities

Migration Timeline

Phase 0 — Discovery

Mar – Apr 2026

Phase 1 — Foundation

May – Aug 2026

Phase 2 — Migration

Sep 2026 – Mar 2027

Phase 3 — Optimisation

Apr – Sep 2027

Phase 0 — Discovery

Stakeholder interviews complete2026-03-21

Current-state map validated2026-03-28

Future-state scenarios presented2026-04-11

Architecture blueprint delivered2026-04-25

Phase 1 — Foundation

Integration facade layer deployed2026-06-01

Domain API contracts published2026-06-15

Observability baseline established2026-07-01

First domain migrated to new boundary2026-08-15

Phase 2 — Migration

Dealer portal v2 pilot2026-10-01

Service operations cutover (EMEA)2026-12-01

Legacy Siebel decommission2027-02-01

China parallel track go-live2027-03-01

Phase 3 — Optimisation

Customer self-service launch2027-04-15

Predictive maintenance integration2027-06-01

Full dealer network migration2027-08-01

Platform cost optimisation review2027-09-15

Facade Layer Architecture

API facade topology showing how new consumers are isolated from legacy system interfaces during transition.

Draft

Architecture Lead

Decision Layer

Decisions Supported

ADR-001 (strangler-fig pattern). Deprecation sequence depends on ADR-003 (composable DXP) and ADR-006 (SAP retention).

Dependencies

Depends on DEL-001 (Current-State) for system inventory. Blocked by scenario selection for timeline confirmation.

Next Actions

Steering committee to confirm strangler-fig approach. Initiate facade layer technology evaluation. Define Phase 1 migration scope.

Confidence

Medium — pattern is sound but approach requires formal approval. Timeline depends on scenario selection.

← Risk & Dependencies

All outputs Next

China Architecture→