Cloud migration often preserves rather than eliminates legacy when structural redesign is deferred. Re-legacy occurs when outdated domain boundaries, embedded behavioural coupling, and implicit integrations are rehosted under modern infrastructure abstractions. This compounds structural debt, financialises complexity, and stabilises fragility under the banner of transformation. True modernisation requires deliberate structural intervention (redefining boundaries, clarifying state ownership, and reducing coupling) not merely upgrading the substrate.

Executive Summary

Cloud migration and platform modernisation frequently preserve underlying structural complexity. When behavioural decomposition, domain boundary clarification, and state ownership redesign are deferred, legacy systems are not transformed — they are re-legacied.

Re-legacy compounds debt by layering modern infrastructure beneath old coupling. Costs become visible, integration density remains, and structural fragility persists. Over time, the debt of deferred structure becomes more expensive and more difficult to unwind.

Infrastructure remediation may be necessary. But without structural intervention, it stabilises legacy rather than dissolving it.

Transformation requires changing system structure — not merely upgrading its substrate.

Contents

1. Introduction

Migrating legacy systems to modern platforms is often celebrated as transformation. Infrastructure is refreshed. Estates are consolidated. Data centres are exited. Programmes close.

But when structure remains unchanged, migration does not eliminate legacy. It re-hosts it.

Re-legacy is what happens when architectural structure is preserved under new infrastructure abstractions. It is legacy with modern tooling. It is complexity that has been relocated, not reduced.

In the previous article, I argued that data is a symptom of function: that causality flows from capability through behaviour and integration down to persistence. Re-legacy is what occurs when we accept that causal hierarchy intellectually but intervene below it operationally. Infrastructure is modernised while the behavioural and boundary structure that generates the estate remains intact. The result is not transformation, but stabilised causality.

The result is not stagnation. It is compounded structural debt.

1.1 Quadraphenia: Four Architecture Articles Together

A critique of superficial modernisation and a defence of structural discipline in enterprise systems: Enterprise modernisation fails when intervention occurs below the level of causality. This four-part series examines transformation through a structural lens:

1. Data Is a Symptom of Function: Migrating RDBMS Estates Is Not Transformation
   Why starting at the data layer mistakes persistence for capability.
2. Re-Legacy: The Debt of Deferred Structure
   How infrastructure modernisation compounds structural debt when topology remains unchanged.
3. If Your Enterprise Architect Cannot Draw Your Core Architecture From Memory, What Are They?
   Why structural ownership must exist cognitively, not just in tooling.
4. Stop Making Sense: Semantic Collapse in the Enterprise
   How semantic drift erodes architectural reasoning itself.

Across the series, one principle holds:

• Structure determines behaviour.
• Behaviour determines state.
• State produces data.
• Infrastructure merely hosts it.

If transformation does not intervene at the structural level, it is optimisation, not redesign.

The same structural stack applies here, but attention shifts to the middle layers: integration and state. Re-legacy occurs when infrastructure is modernised while domain boundaries, ownership of state, and coupling patterns remain intact.

The topology above the infrastructure layer defines the real complexity. When that topology is preserved and merely hosted on new platforms, structural debt is stabilised rather than reduced.

2. What Is Re-Legacy?

Re-legacy is structural technical debt that has been infrastructure-optimised rather than structurally redesigned. It arises when misaligned domain boundaries, embedded behavioural coupling, and ambiguous state ownership are preserved during migration, stabilising legacy topology under modern platforms. Unlike ordinary technical debt, re-legacy is institutionalised (endorsed by successful migration) and therefore harder to challenge.

It has three defining characteristics:

• Existing domain boundaries remain misaligned.
• Behaviour embedded in persistence remains embedded.
• Integration patterns remain implicit and tightly coupled.

Only the hosting model changes.

The system may now run on managed cloud services. It may use containers, orchestration platforms, or service meshes. But the causal structure — the way behaviour, state, and integration relate — is intact.

Re-legacy is not failure to migrate. It is migration without structural change.

3. Technical Debt Versus Structural Debt

Technical debt is often understood in local terms: poor code quality, duplication, brittle tests, and outdated libraries. Structural debt is different. Structural debt exists when:

• Domains are incorrectly bounded.
• Multiple capabilities share the same persistence model.
• Integration occurs through shared tables rather than explicit contracts.
• State ownership is ambiguous.
• Feedback loops are implicit and undocumented.

Structural debt is architectural topology, not code hygiene. Re-legacy is what happens when technical debt graduates into topology. When migration programmes defer structural redesign, they do not freeze debt at its current level. They create a second layer: the debt of deferred structure.

The original misalignment remains. On top of it, new infrastructure abstractions are layered. Observability is added. APIs are wrapped around stored procedures. Event streams mirror legacy schemas. The topology does not simplify. It becomes more elaborate.

4. The Economic Consequence

In on-prem estates, structural inefficiencies are often obscured. Over-fetching, cross-domain joins, and batch inefficiency consume hardware but do not produce itemised invoices. In cloud environments, these behaviours are metered.

• Every I/O is billed.
• Every cross-zone transfer is charged.
• Every inefficient query has a measurable cost.
• Every redundant computation consumes priced compute.

Re-legacy converts structural entropy into operating expense. What was previously hidden as capital expenditure becomes visible as monthly cost volatility. The architecture has not changed, but its inefficiencies are now economically explicit. Migration without structural simplification financialises complexity.

5. Organisational Stabilisation of Complexity

Re-legacy is not only technical. It is organisational. When migration programmes are labelled “transformation,” leadership perceives the problem as solved. Budgets shift. Attention moves elsewhere. Architectural scrutiny declines.

The system is declared modern because its infrastructure is modern. This narrative stabilises structural debt. Future attempts to redesign domains or extract behaviour are framed as incremental improvements rather than necessary correction. Re-legacy becomes institutionalised.

6. The Strangler That Never Strangles

Many programmes adopt incremental patterns: rehost first, then refactor; wrap the core in APIs; introduce events; progressively extract services. Without explicit structural intent, these efforts become adapters rather than decompositions.

• New services depend on old schemas.
• APIs proxy stored procedures.
• Event streams replicate legacy data models.
• The core remains the gravitational centre.

The strangler does not strangle. It decorates. Surface area increases. Coupling remains.

7. Feedback Loop Amplification

Legacy systems often contain tightly coupled feedback loops: state influences behaviour; behaviour modifies state; downstream systems react; reactions propagate upstream. Re-legacy adds abstraction layers (gateways, meshes, observability platforms) without altering the feedback structure itself.

• The number of components increases.
• The number of boundaries increases.
• But the behavioural topology does not simplify.

Complexity expands outward while remaining dense at the core.

8. Signals You Are in Re-Legacy

Re-legacy can be diagnosed. Common indicators include:

• Migration complete, but change velocity unchanged.
• Reporting still queries core transactional tables.
• Domain ownership remains ambiguous.
• New services depend on legacy events or schemas.
• Decommissioning timelines remain perpetually deferred.
• Every significant change requires cross-team coordination.

The system appears modern. Its behaviour remains legacy.

9. Breaking the Debt of Deferred Structure

Structural debt cannot be paid down by infrastructure optimisation. Breaking re-legacy requires explicit structural intervention:

• Freeze new integration into legacy cores.
• Define and enforce domain boundaries.
• Extract behavioural seams deliberately.
• Assign clear ownership of state.
• Separate operational capability from historical memory.
• Decommission, rather than wrap, obsolete structures.

Transformation must be funded separately from migration.

• Migration addresses platform risk and cost exposure.
• Transformation addresses structural misalignment.

They are not interchangeable.

10. Conclusion: The Architectural Choice

Re-legacy is comfortable. It allows organisations to claim modernisation without confronting domain misalignment, behavioural entanglement, or political boundary changes. It preserves institutional knowledge without requiring institutional redesign.

But it compounds debt. The longer the structural intervention is deferred, the more elaborate and expensive the eventual redesign becomes. New services entrench old assumptions. Cloud abstractions wrap legacy coupling. Complexity accrues interest. At some point, the organisation must choose:

• Redesign the structure deliberately
  or
• Continue layering modern infrastructure onto historic topology

Cloud does not eliminate legacy. It reveals whether an organisation is willing to change its structure, or merely its substrate.