Skip to main content

Coexistence & Decommissioning

1. Coexistence is an architecture​

During transition, explicitly define:

  • system of record
  • authoritative semantic layer
  • data synchronization
  • consumer routing
  • ownership
  • reconciliation
  • failure behavior

Avoid dual-write designs unless there is a strong, tested reason.

2. Decommissioning gates​

Retire a legacy workload only when:

  • all consumers are migrated
  • scheduled jobs are disabled
  • interfaces are removed
  • reconciliation is complete
  • retention requirements are satisfied
  • audit requirements are preserved
  • rollback window has expired
  • business owner signs off

3. Decommission in dependency order​

A safe sequence is usually:

Consumers → orchestration → transformations → semantic models → persistence → source interfaces

The exact sequence depends on the dependency graph.

4. Archive vs delete​

Determine what must be retained for legal, audit, operational, or analytical reasons. Do not delete historical data simply because the application is retired.

5. Final architecture record​

Update the enterprise catalog and architecture diagrams so the retired platform does not remain a “ghost dependency.”