Modernising the monolith without a big bang

On this page

A legacy core becomes dangerous when every change depends on one high-risk cutover. Modernisation should reduce business risk in controlled slices while the essential service keeps running.

A monolith is not automatically a failure. It becomes a business constraint when change is slow, dependencies are unclear, operational knowledge is concentrated and releases expose too much of the enterprise at once. Rewriting everything does not remove those conditions by itself; it often carries them into a new stack.

A capability-led approach starts with the business journeys that need to change, the operational risks that must remain controlled and the ownership model required after migration. Architecture then supports the sequence instead of dictating it.

Fund a sequence of independently valuable capability releases with explicit exit and rollback gates. Do not fund an undifferentiated replacement programme whose value appears only after final cutover.

The first deliverable is an evidence-backed map of business capabilities, applications, data stores, integrations, operational processes and people dependencies. Static application inventories are insufficient; teams need to know which journeys trigger which components, where data authority sits and how failure propagates.

A useful first slice is important enough to prove value, bounded enough to control and representative enough to test the future delivery pattern. Selecting only a trivial edge service proves little; selecting the hardest domain first creates avoidable exposure.

Incremental modernisation requires seams where behaviour can be intercepted, compared and redirected. Depending on the estate, those seams include APIs, events, change-data capture, façade services, replicated read models and workflow orchestration. The pattern should preserve a clear system of record during transition. The Strangler Fig application pattern is one established approach to creating these seams around a live legacy core.

• Priority journeys and decisions
• Revenue, service or regulatory consequence
• Process variants and workarounds
• Accountable business owners
• Runtime and data dependencies
• Integration contracts
• Release and environment path
• Failure and recovery behaviour
• Support queues and runbooks
• Manual controls
• Peak periods and blackout windows
• Service and data obligations
• Internal knowledge concentration
• Skills required by migration wave
• Partner dependencies
• Transition and continuity needs
• The capability boundary and system of record are explicit.
• Consumers have passed contract and integration tests.
• Data reconciliation and exception ownership are operational.
• Security, privacy, accessibility and audit controls are tested.

The first deliverable is an evidence-backed map of business capabilities, applications, data stores, integrations, operational processes and people dependencies. Static application inventories are insufficient; teams need to know which journeys trigger which components, where data authority sits and how failure propagates.

• Priority journeys and decisions
• Revenue, service or regulatory consequence
• Process variants and workarounds
• Accountable business owners
• Runtime and data dependencies
• Integration contracts
• Release and environment path
• Failure and recovery behaviour
• Support queues and runbooks
• Manual controls
• Peak periods and blackout windows
• Service and data obligations
• Internal knowledge concentration
• Skills required by migration wave
• Partner dependencies
• Transition and continuity needs

Incremental modernisation requires seams where behaviour can be intercepted, compared and redirected. Depending on the estate, those seams include APIs, events, change-data capture, façade services, replicated read models and workflow orchestration. The pattern should preserve a clear system of record during transition. The Strangler Fig application pattern is one established approach to creating these seams around a live legacy core.

Contract tests protect consumers while interfaces change. Observability traces a business transaction across old and new components. Reconciliation controls detect divergence when data moves asynchronously. Every wave needs a rollback or fallback path that operations teams understand. MENTARA uses OpenTelemetry as vendor-neutral instrumentation guidance for tracing transactions across mixed estates.

Domain boundaries, interface contracts, service extraction, user experience and decommissioning.

Authority, migration, synchronization, reconciliation, history, retention and quality controls.

Environments, delivery pipelines, identity, observability, resilience and cost controls.

Product ownership, support, incident routes, documentation, skills transfer and service acceptance.

Modernisation fails sustainably when the new stack depends on a temporary programme team. Each wave should name the long-term product, application, data and operations owners before build begins. The workforce plan then closes specific gaps through internal development, permanent hiring, specialist augmentation, partnership or managed capacity.

Knowledge transfer should be observable: paired work, reviewed runbooks, architecture decisions, support simulations and operational ownership exercised before transition. Documentation alone does not demonstrate readiness.

• The programme is organized around business capabilities, not application components alone.
• Each migration wave produces usable value or removes a defined constraint.
• Legacy retirement criteria are explicit and funded.
• Data authority and transition states are clear for every slice.
• Release, rollback and pause decisions have named owners.
• The future product and operations teams are mobilized before cutover.
• Architecture, workforce, adoption and run costs are assessed together.
• Progress is measured through capability movement and risk retirement, not code volume.