Loading content
Coexistence Architecture defines strategies for running legacy systems alongside new cloud‑native components. It emphasizes interface layers, decoupling, data consistency and phased migration so operations and development can coexist. The goal is to reduce risk, enable continuous delivery and achieve incremental modernization without full replacement.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Coexistence Architecture is an architectural pattern for running legacy systems and new components side by side for a limited time. It supports modernization in small steps without replacing the existing solution all at once.
The pattern comes from modernization efforts where existing business systems must keep running while new platforms, services, or cloud components are introduced. Instead of a big-bang replacement, Coexistence Architecture separates responsibilities through facades, adapters, and transition layers so operations, data reconciliation, and new development can proceed in parallel. It combines lessons from legacy migration, strangler-style change, and hybrid operation.
Think of two running lanes with a transition zone between them. On the left, the legacy system keeps serving; on the right, the new solution grows. A clear interface layer routes requests, replicates or synchronizes data, and decouples both sides as far as needed. Capabilities move one by one; once a function works reliably on the new side, the old lane is retired.
Old and new systems operate at the same time so behavior and data can be compared under control.
A mediating layer hides technical and domain differences between the systems.
Dependencies are reduced so both sides can evolve independently.
Data states are compared, synchronized, or deliberately cross-checked before cutover.
Functions or domains are moved one after another instead of in a single replacement.
This pattern is useful when replacement cannot happen without interruption: during high operational risk, long migration cycles, regulatory constraints, or when old and new components must be tested in parallel. The trade-off is extra transition components, duplicated operations, and more coordination effort; without stable data contracts and clear interfaces, coexistence can become more expensive than a clean cutover.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.