Strategy

Platform Deprecation

Strangler-fig approach to legacy removal. Façade-first migration preserving operational continuity through wrap, replace, and retain sequencing.

Decision neededUpdated 18 Mar 2026Current State →Future State →

Why this matters

Legacy decomposition strategy determines operational continuity risk during transformation. The wrong sequencing will disrupt dealer operations.

What this informs

Phase 1 scope, vendor selection criteria, and the migration risk profile. Directly linked to scenario selection.

What remains unresolved

Deprecation strategy awaiting steering committee approval. Façade layer architecture not yet specified. First migration pilot domain not selected.

Legacy Systems

Approach

Strangler-Fig

Phases

Estimated Duration

18 months

Status

Decision needed

Deprecation Approach

Strangler-Fig Pattern

01Foundation

Wrap First

Place API façades in front of legacy systems. New consumers only interact via the façade. Legacy systems remain operational behind the boundary.

02Migration

Replace Later

Build new domain services behind the same façade contracts. Migrate traffic gradually. Validate at each stage. Roll back if needed.

03Optimisation

Retain Temporarily

Some legacy components are retained where replacement risk exceeds benefit. Documented as conscious decisions, not technical debt. Reviewed quarterly.

State Transitions

Current State

Direct coupling

Dealer portal → SAP (direct DB queries)

Siebel ↔ SAP (batch sync)

Telematics → custom pipeline

No abstraction layer

Regional variations hardcoded

Transition State

Façade layer active

Façade APIs wrap legacy systems

New services consume via façade

Dual-running during migration

Traffic routing by feature flag

Monitoring on all integration points

Target State

Domain-owned services

Domain APIs own their data

Event bus for async communication

Legacy systems decommissioned

Façade removed or absorbed into gateway

Regional config, not regional code

Systems Targeted for Deprecation

System	Current Status	Strategy	Target Date	Dependencies
Service Operations Platform (Siebel)	Sunset	Replace — new domain service	2027-Q2	SAP, DMS Hub
Dealer Portal (Sitecore)	Legacy	Wrap then replace — façade first	2027-Q1	SAP, Siebel, MuleSoft
Legacy ETL Pipelines	Legacy	Replace — domain event streams	2027-Q3	Snowflake, Power BI

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 façade 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

Façade Layer Architecture

How the API façade wraps legacy systems and routes traffic to new domain services during the transition period.

Draft

Architecture Lead

Decision Layer

Decisions Supported

ADR-001 (strangler-fig confirmed). Deprecation strategy requires steering committee approval.

Dependencies

Blocked by scenario selection. Depends on current-state map (DEL-001) and risk assessment (DEL-005).

Next Actions

Define façade contract specifications. Identify first domain for migration pilot.

Confidence

Medium — approach is sound but dependent on scenario lock and façade architecture specification.