Split the monolith or stabilize it? Decision criteria for modular modernization

Monday morning, 9:10 a.m.: a business unit reports a „small change“ in the ordering process. IT glances at the ticket text; it looks feasible. Two hours later the mood has changed. The build runs longer than planned, a side job is tied to the same release package, and a look into the database makes clear: this change touches more tables and triggers than expected. By now the question that regularly occupies many teams arises: Break up the monolith or stabilize it?

Anyone who reflexively answers „Microservices!“ often overlooks the core: it’s not about an architecture label, but about delivery capability and operational reliability. This practical guide walks through a pragmatic assessment, shows decision criteria for modular modernization and describes actionable steps. It also covers typical failure patterns as well as clear stop and escalation points — so modernization does not become a long-running project without measurable effect.

Break up the monolith or stabilize it: first the symptom, then the architecture

„The monolith is to blame“ sounds decisive, but is rarely precise enough for a decision. A monolith (an application as a single deployment artifact) can run very reliably — or constantly cause friction. Likewise: microservices (many small, separately deployable services) can reduce lead times, but inevitably bring more operational tasks.

Martin Fowler soberly classifies this reality: Microservices are primarily another Operations-Footprint — in other words a different operational effort with more components, more deployments, more sources of failure and more need for automation.^[Source] The limitation of this statement: it does not replace an analysis of your system. The practical conclusion is nevertheless clear: whoever declares „Microservices“ as the goal before the bottleneck is clearly described will quickly modernize the wrong part.

Decision criteria: When decomposition really helps — and when it doesn’t

Pressure to modernize is real: security requirements rise, interfaces multiply, teams change, and business software must continue running while it evolves. Decomposition can be a sensible step — but only if it addresses the bottleneck and not merely makes the architecture diagram look nicer.

Criterion 1: Operational maturity — can your operations carry the Footprint?

With every additional deployable unit, the need for disciplined delivery and monitoring increases: CI/CD (automated build/test/deploy pipeline), Observability (metrics, logs and traces for diagnosis), incident processes, runbooks and clear responsibilities. AWS frames this as a trade-off: finer segmentation can bring benefits for reliability and scaling, but increases operational complexity with the number of components.^[Source] The caveat: this is a guardrail, not a guarantee of success. The implication: if you already have difficulty getting a deployment stable today, a service landscape multiplies that problem.

Concrete checkpoints that should not be dismissed:

• Release capability: rollback/backout is defined, maintenance windows and communication are established.
• Monitoring & alerting: alerts are actionable (not „everything red“), sources of failure are localizable.
• Incident handling: there is a rhythm for postmortems and remediation actions, not only ad-hoc firefighting.
• Ownership: who decides on interfaces, who prioritizes, who bears operations and quality?

Criterion 2: Change decoupling — do requirements block each other?

Decomposition is worthwhile when independent changes in the monolith regularly become dependent on one another, even though they are functionally separate. A common pattern: a portal area needs frequent adjustments while a billing area must rarely change and requires high care. If both always end up in the same release train, they slow each other down.

Conversely, decomposition often backfires when almost every change runs across many areas (permissions, pricing logic, reporting, data cleanup). In that case you create interface traffic instead of decoupling — and coordination increases rather than decreases.

Criterion 3: Data coupling – is the complexity in the database?

Many systems are coupled less by code than by data: shared tables, triggers, transactional flows and batch jobs. Sam Newman points out in his decomposition patterns that the real challenge is often the data and integration strategy — and that Big-Bang initiatives are particularly risky in this context.^[Source]

Practical implication for operations: If multiple components write to the same tables without rules, side effects arise that are hard to roll back cleanly. Modular modernization therefore requires early decisions on data ownership, consistency and decoupling of reporting.

Criterion 4: Stability and business value – what must be preserved?

Mature digital enterprise solutions often contain a lot of correctly implemented domain logic: edge cases, commercial rules, exceptions in processes, historically evolved data cleansing. This is not ‚legacy junk‘, but often the reason the business works at all. Modernization is economical when it does not recklessly discard this value — and at the same time identifies the areas that make operation and further development disproportionately expensive.

Selecting an approach: three target models that work in enterprises

Between „everything stays“ and „everything becomes Microservices“ there are practical target models that make modernization plannable. AWS Prescriptive Guidance explicitly recommends checking before decomposition which parts should actually be decomposed, and favoring incremental approaches.^[Source]

Practical guide: From assessment to implementation (with stop/go points)

1) Make system boundaries visible — small enough to be used

You don’t need an 80-page system documentation to make decisions. What helps is a compact map: main processes, critical interfaces (e.g. portals, EDI, file exports, REST-APIs), batch jobs, and locations with high susceptibility to failure. Goal: be able to make decisions, not to archive knowledge.

A view that brings operations and the business unit together has proven effective: „Which process flow is business-critical, and what does it depend on technically?“ That quickly makes visible where an extraction would be risky — and where it could actually provide relief.

2) Define baseline metrics — otherwise it remains a matter of faith

Modernization without a baseline is like performance optimization without measurement. Crucial are indicators that reflect both delivery and operations: deployment frequency, lead time (from request to production), change failure rate (incidents after changes), MTTR (mean time to recovery) and recurring incident classes. The metrics don’t have to be academically perfect — but they must be collected consistently so that a Stop/Go decision is possible.

3) Partition candidates — by domain, not by technical layers

A common false start is cutting by layers („UI service“, „DB service“). That creates new dependencies instead of reducing them. A domain cut means: a module is responsible for a business area including rules and data. That is usually more tangible for teams than a purely technical boundary.

If you can’t name the domain boundaries, that’s not a reason to cut faster — it’s a signal to first stabilize and modularize the monolith: clarify terms, understand data flows, identify cross-cutting functions.

4) Strangler instead of Big Bang — redirect in a controlled way, shut down consistently

When availability matters and risks must be controlled, the Strangler-Fig-Pattern is a dependable approach: functions are gradually replaced alongside the existing system; traffic is redirected in a controlled manner until old paths are decommissioned.^[Source]

The discipline behind the pattern is important: clear routing decisions, compatibility in data and interfaces, monitoring across both paths — and a real „done“ when the old path is removed. Otherwise parallel operation becomes a permanent state.

5) Firmly establish the data and reporting strategy early

In practice, modernization often comes down to two questions: who “owns” which data — and how is reporting done? If reporting accesses operational tables directly, it blocks changes. If multiple components “share” data without rules, inconsistencies arise.

Plan explicitly for:

• Data ownership: which module is authoritative for which entity (customer, order, invoice …)?
• Consistency requirements: where is strong consistency required, where is Eventual Consistency sufficient?
• Reporting decoupling: how are reports fed without hardening operational models?

6) Define security and operations per module — don’t bolt them on later

With each new component the attack surface increases: service-to-service communication, secrets, permissions, audit trails. Clarify early how authentication (e.g. centrally via SSO) and authorization (role-/permission-based per domain) interact. For day-to-day operations, also consider: logs must be diagnostically useful, but must not violate data protection and retention rules. These points belong in runbooks and operational documentation — not only on architecture slides.

8-step checklist for a robust Go/No-Go decision

1. Identify the bottleneck: What exactly should improve (release duration, stability, scaling, parallel development)?
2. Measure the baseline: Which metrics represent the current state (Lead Time, Change Failure Rate, MTTR etc.)?
3. Check operability: CI/CD, monitoring, alerting, runbooks, incident processes, ownership.
4. Outline domain boundaries: Where are natural domain limits? What are cross-cutting concerns?
5. Design the data strategy: data ownership, consistency, reporting, migration paths.
6. Inventory dependencies: jobs, interfaces, file exports, user groups, permissions.
7. Plan the slice: a small, deliverable package including rollback and monitoring targets.
8. Define stop/go criteria: Which signals stop the decomposition or require a stabilization step?

Typical failure patterns — how they appear in operation

Failure 1: More components, but no ownership

If nobody is end-to-end responsible (prioritization, quality, operations), decoupling becomes a coordination problem. In an incident this leads to long review cycles, unclear decisions and the reflex to deploy “everything together” again. Countermeasure: a clear owner group per module, defined handovers and a decision log for interfaces and data ownership.

Failure 2: Shared data without rules

The anti-pattern is well known: services are separated but continue to write to the same tables or use direct database access across domains. That breaks isolation, complicates audits and makes rollbacks unreliable. Countermeasure: data access via defined interfaces, clear data responsibility and — where necessary — controlled synchronization (e.g. events).

Failure 3: Network latency and failure cascades are “planned for” but not tested

What was an in-process call in a monolith becomes a network call in distributed architectures, with timeouts, retries and potential cascades. Without clean timeouts, correlation (request IDs) and realistic end-to-end tests, error analysis becomes significantly harder. Countermeasure: clear SLOs (measurable service objectives), defined timeouts, trace correlation and load tests across complete process flows.

Error 4: Partitioning by organizational chart instead of domain logic

If services primarily mirror team boundaries but, from a domain perspective, cut across processes, coupling remains—just at a different level. Countermeasure: domain-aligned partitioning, even if that initially causes friction. If that is not organizationally feasible, a modular monolith is often the better intermediate step.

Stop and escalation points: when stabilizing becomes the better decision

A modernization initiative needs stop rules, otherwise it will consume budget and attention. These signals are strong reasons to consciously switch gears:

• Operational overload: flood of alerts, rising MTTR, on-call no longer coverable.
• No measurable improvement: lead time, change failure rate or stability do not show noticeable improvement.
• Interface complexity explodes: versioning unclear, breaking changes accumulate, debugging becomes guesswork.
• Data conflicts: inconsistencies, duplicate truths, hard-to-explain report discrepancies.
• Ownership remains unclear: decisions stall, no one assumes responsibility for operation and further development.

Escalation then does not mean „back to the old way“, but: prioritize stabilization. Typical measures are: catch up on regression for core processes, improve observability, consolidate data accesses, sharpen module boundaries in the monolith – and only after that reassess whether an extraction actually brings benefit.

What „stabilizing“ concretely means — and why it often works faster

Stabilization is not a cosmetic cleanup. In operations it shows as fewer surprises and predictable releases. Concrete levers that teams feel immediately:

• Release mechanics: reproducible build, consistent environments, practiced rollback path.
• Transparency: logging standards, error classification, correlation of requests across process flows.
• Test focus: end-to-end regression for core flows (not just isolated tests).
• Module boundaries in the monolith: defined internal APIs, disciplined data access, clear responsibilities.
• Data hygiene: unambiguous master data sources, documented side effects of jobs, reduced special-case logic.

The result is often a robust modular monolith: the software remains operable as a unit, but is internally more clearly partitioned. This lets teams reclaim much of what decomposition promises – without immediately multiplying operational complexity.

Final check before you decide

If you were to decompose today: could you tomorrow morning, in an incident, quickly say which part is responsible, who reacts, which metric proves the fault and how you would roll back? If this question remains uncomfortably open, the decision is usually not „more architecture“ but „more operational safety“.

If you want to assess your starting point in a structured way and set up a modernization path with clear stop/go points, you can contact us for that on a one-off, targeted basis:

Legacy modernization and the Strangler Fig pattern are also important for this topic. The article places these aspects into context and shows what matters in everyday operational practice.

Discuss a project or modernization initiative with Net-Base.