DEV Community: Saulo Santos

Incremental Modernization Architecture: Splitting Monoliths into Microservices Without Breaking the Business

Saulo Santos — Sat, 02 May 2026 17:10:12 +0000

A Pragmatic Approach to Service Decomposition

For many enterprises, the monolith is both a strength and a challenge. Over decades, organizations build robust platforms that support critical operations — but eventually, the weight of legacy coupling begins to hinder growth.

Successful modernization is less about "new tech" and more about managing the transition of complexity.

The real question is never "should we modernize?" — it is "how do we modernize without stopping the business that funds the modernization?"

A Tale of Two Modernizations: Lessons from the Field

I have lived through two very different modernization efforts — separated by roughly two decades, different companies, different scales, different outcomes. What they share is that the architecture of the transition mattered far more than the architecture of the target system.

Case 1: The Language Migration Trap (The "Big Bang" Failure)

Early in my career, I was part of a company that decided to rewrite its entire monolith into Java J2EE. This wasn't an incremental evolution — it was a full stop, full swap. Legacy maintenance was put on pause. The "New World" was everything.

Looking back now, the failure modes are clear.

The first was customer patience running out. While the team was absorbed in the rewrite, real business demands kept coming. Support tickets piled up. Feature requests went unanswered. The old system was frozen, and the new one wasn't ready. There is only so long a customer base will tolerate that gap before the relationship breaks.

The second was over-ambition in the architecture itself. The lead architect — talented, no question — went deep into building a universal framework that would auto-generate screens and business logic. The idea was impressive on paper. In practice, the generated code was slow and inflexible, and the framework became a bottleneck. Every change required fighting the abstraction rather than solving the business problem. Code reviews turned into painful rework cycles. Development slowed to a crawl.

Here is the hard lesson: they built it because they could, not because the business needed it. There was no real requirement driving the need to regenerate screens automatically. It was engineering ambition outrunning business reality.

The frustration compounded over time. Engineers lost momentum. Team morale eroded. About two years after I left, the company went bankrupt.

Not because of bad engineers. Because of an approach that put architectural purity ahead of continuous value delivery.

Case 2: The Microservices Evolution (The Balanced Win)

Years later, leading the web and API team at a UK insurance technology firm, I faced a different challenge. We had a large integration monolith — not a traditional business logic monolith, but a complex orchestration layer connecting our core insurance processing platform (handling policies, contacts, claims and more) with banking validation, payment processing, and a range of custom-built internal services. It was the nervous system of the operation.

The goal was to decompose this into microservices. The constraint was that we could never stop the business while doing it.

We allocated 15–20% of development capacity to the migration. The rest kept the platform running and delivering features. We applied the Strangler Fig pattern — gradually routing traffic away from the monolith and toward new, purpose-built services, while both coexisted in production for an extended period. There was no hard cutover. There were instead many intermediate states, each stable enough to operate in, each a step closer to the target architecture.

It worked. Not because we were faster or smarter than the team in Case 1 — but because we never stopped serving the business while we transformed it.

Engineers had room to learn new technologies — microservices patterns, event-driven architecture, modern API design — without being pulled entirely away from the systems that mattered today. That balance kept frustration low and momentum high.

The Strangler Fig in Practice

The Strangler Fig pattern deserves more than a passing mention, because it is the architectural mechanism that makes incremental decomposition possible.

The principle is straightforward: rather than replacing a system in one move, you grow new capability around it. New requests are routed to the new service. The monolith handles what hasn't been migrated yet. Over time, the monolith "strangles" — its surface area shrinks as each capability is extracted — until it can eventually be retired, or simply left running the small residual it still owns.

In our case, the monolith was an integration and transformation layer. Extracting from it meant two distinct types of work:

Service extraction — identifying discrete integration flows (say, payment processing or banking validation) and pulling them out as standalone services with their own deployment lifecycle.
Transformation layer rewriting — where the monolith was doing complex schema and API transformations between systems, we rewrote those translation responsibilities into a new architecture, giving us cleaner contracts and independent evolvability. Neither of these was a clean, surgical operation. Real systems aren't clean. The intermediate states — where both the old and new paths existed simultaneously — required careful routing logic, thorough testing at the boundary, and a tolerance for living with complexity during the transition. That tolerance is itself an architectural decision. You have to accept that the system will look messy for a while. The alternative is a Big Bang that looks clean on a diagram and fails in production.

The Strangler Fig trades short-term tidiness for long-term survivability. That is almost always the right trade.

The Boundary Problem: Strategic vs. Tactical

Both stories surface the same underlying challenge: where do you draw the line?

In software, we tend to think of this as a technical question — bounded contexts, API contracts, data ownership. But in practice, it operates at three levels simultaneously:

Logical Boundaries (Domain-Driven Design): Ensuring that a change to payment processing doesn't cascade into claims, and that each service owns its own model cleanly.
Implementation Boundaries (Anti-Corruption): When integrating with a third-party platform that has its own data model and terminology, you need a translation layer that protects your new services from absorbing legacy concepts. Your domain language should stay yours.
Operational Boundaries (Capacity): This is the one most teams ignore. How much architectural change can your organisation absorb per sprint without compromising delivery? That is a real constraint, and it needs to be treated as one. Most failed modernizations violate all three simultaneously — trying to redesign the domain model, integrate legacy systems, and restructure the team all at once.

The Human Side of Transformation

This is the part that rarely makes it into architecture documents, but it determines outcomes as much as any technical decision.

In Case 1, the human cost was visible in hindsight. Engineers were asked to build an entirely new world while the old one decayed around them. The framework they were building didn't give them small wins — it was all or nothing. When the abstraction fought back, there was no relief valve. Frustration accumulated quietly until the team began to leave.

In Case 2, the 15–20% model created a different dynamic. Engineers were working on modern technology and shipping production value in the same sprint. Learning didn't come at the cost of delivery. People could see the migration moving forward in concrete steps — a service extracted, a transformation layer replaced — without feeling like the business was being held hostage to the architecture.

There is also a knowledge dimension that is easy to underestimate. A monolith built over many years carries encoded business logic that exists nowhere else — not in documentation, not in the heads of current team members, but in the behaviour of the running system. A Big Bang rewrite forces you to rediscover all of that logic under pressure, at the worst possible time. An incremental approach surfaces it gradually, giving the team time to understand it and encode it correctly in the new services.

The domain knowledge in legacy code is an asset. Treat it as such.

The 15–20% Capacity Model: Governance, Not Just a Number

The capacity allocation deserves its own framing, because it is often misread as a conservative compromise. It isn't. It is a governance model that answers a question most modernization programs never ask explicitly:

At what rate can this organisation absorb architectural change without compromising delivery?

The constraint is intentional. By capping the modernization investment, you force prioritization. Only the highest-value boundaries get addressed first. Engineers can't disappear into abstraction for quarters at a time. Stakeholders see continuous delivery alongside the transformation, which preserves the trust that long modernization programs tend to erode.

And it compounds. Early investments in shared infrastructure — service templates, deployment pipelines, observability tooling — reduce the cost of each subsequent extraction. The 20% buys you more over time, not less.

Modernization becomes a capability, not a project.

Strategic Principles for Success

Avoid technology for technology's sake. If a framework doesn't solve a current business requirement, it is a liability, not an asset. Case 1 is the cautionary example.
Modernize the path, not just the destination. The process of decomposing a monolith is as important as the target architecture. Design the transition, not just the end state.
Apply the Strangler Fig deliberately. Accept intermediate states. Plan for them. Route carefully, test the boundaries, and retire the old paths only when the new ones are proven.
Protect your domain model. When integrating with legacy systems or third-party platforms, use translation boundaries to keep your new services speaking your language, not theirs.
Budget for evolution. A fixed capacity allocation turns transformation from a high-stakes project into a continuous architectural practice.
Use observability as a compass. Instrument the system before you decompose it. Traces will show you where the real boundaries are — and validate that your extractions are actually working. (See Part 1 of this series for how to introduce observability non-invasively.)

Conclusion

Whether you are migrating into a new technology or decomposing an integration monolith into microservices, the path to success is the same: pragmatic incrementalism.

Modernization is not a single event. It is a strategic design choice to build the future without abandoning the present.

The strongest architectures are not those that are the most "pure" — they are those that are the most resilient to change. And resilience, in architecture as in engineering, is built through deliberate, sustained, small steps — not through a single leap of faith.

The monolith served the business for a reason. Your job is not to condemn it.

Your job is to evolve it — without breaking it.

This article is Part 2 of the Incremental Modernization Architecture series.

Part 1: Enabling Observability in Legacy Systems

Incremental Modernization Architecture: Enabling Observability in Legacy Systems

Saulo Santos — Sat, 02 May 2026 16:11:37 +0000

A Pragmatic Approach to Enterprise Modernization

Many corporations have spent more than a decade building what were once considered “perfect” monoliths — robust, feature-rich systems that power critical business operations. Today, however, these same systems are often viewed as obstacles: difficult to scale, hard to maintain, and incompatible with modern cloud-native architectures.

This creates a fundamental question for enterprise leaders: Should we throw everything away and start from scratch?

In practice, organizations that attempt a full rewrite — pausing legacy maintenance in favor of a “big bang” transformation — frequently fail. Costs spiral, delivery timelines slip, and business continuity is jeopardized. On the other hand, companies that adopt a step-by-step modernization strategy are far more likely to succeed.

This article focuses on one critical piece of that journey:
observability enablement in legacy systems — without requiring extensive code changes.

The Observability Gap in Legacy Systems

Modern distributed systems rely heavily on observability — metrics, logs, and traces — to provide insight into runtime behavior. In microservices architectures, observability is often built in from the start.

Legacy systems, however, present a different reality:

Limited or inconsistent logging
No distributed tracing capabilities
Tight coupling between components
High resistance to invasive code changes

Yet, observability is not optional. It is essential for:

Diagnosing production issues
Understanding system performance
Supporting gradual modernization
Enabling reliable integration with new services

The challenge becomes clear:
How do you introduce observability into systems that were never designed for it — without rewriting them?

Rethinking Modernization: Enable, Don’t Replace

A common misconception in modernization programs is that legacy systems must be replaced before they can participate in modern architectures.

In reality, modernization is not a replacement exercise — it is an enablement strategy.

Instead of rebuilding everything, organizations should:

Extend legacy systems with modern capabilities
Introduce abstraction layers and integration points
Gradually evolve architecture through coexistence

Observability is one of the most impactful capabilities to introduce early, because it:

Reduces operational risk
Accelerates debugging and issue resolution
Provides visibility into system behavior during transformation

Non-Invasive Observability: A Practical Approach

To enable observability without rewriting legacy systems, organizations can adopt non-invasive instrumentation techniques. These approaches allow telemetry to be introduced externally or at runtime, avoiding large-scale code changes.

1. Bytecode Instrumentation

Bytecode instrumentation enables runtime modification of application behavior without altering source code. By injecting telemetry logic dynamically, organizations can:

Capture method-level execution traces
Measure performance across critical flows
Introduce distributed tracing across legacy components

This approach is particularly effective in large Java-based systems, where rewriting code is impractical.

2. Agent-Based Observability

Instrumentation agents (such as those aligned with OpenTelemetry standards) can be attached to running applications to automatically collect:

Metrics (CPU, memory, throughput)
Logs (structured and correlated)
Traces (request-level visibility)

These agents operate independently of application code, making them ideal for legacy environments where direct modification is risky or costly.

3. Build-Time Tooling and Plugins

Another approach is to introduce observability during the build process using tools such as:

Maven or Gradle plugins
Annotation processors
Bytecode enhancement frameworks

These mechanisms allow developers to:

Inject telemetry hooks automatically
Enforce consistent observability patterns
Reduce manual implementation effort

Over time, this creates a standardized observability layer across both legacy and modern components.

4. Proxy and Gateway Instrumentation

In integration-heavy systems, observability can also be introduced at the boundaries:

API gateways
Reverse proxies
Service mesh layers

This enables:

Request tracing across systems
Latency measurement between services
Visibility into external dependencies

While this does not replace internal instrumentation, it provides immediate value with minimal disruption.

Real-World Implementation: Enabling Observability in a Large-Scale Legacy Platform

To apply these principles in practice, we implemented a non-invasive observability layer across a large-scale enterprise platform composed of multiple legacy Java applications and evolving microservices.

Rather than introducing manual instrumentation across thousands of methods — which would have been slow, error-prone, and difficult to maintain — we built a custom Maven-based bytecode enhancement plugin.

A Build-Time Instrumentation Strategy

At the core of the solution was a Maven plugin responsible for post-compilation bytecode transformation.

This was not a simple annotation injector, but a rule-driven bytecode enrichment engine designed to selectively introduce observability based on configurable policies rather than blanket instrumentation.

Instead of modifying source code, the plugin:

Intercepts compiled .class files during the build lifecycle
Injects observability-related annotations directly into bytecode
Preserves original line numbers to ensure debugger compatibility
Avoids any changes to developer-written source code

This allowed us to introduce observability without impacting day-to-day development workflows.

Selective and Rule-Based Instrumentation

A key design decision was avoiding blanket instrumentation.

Not every method should be traced.

To prevent unnecessary performance overhead, we introduced a rule engine based on regex matching, allowing instrumentation to be selectively applied at multiple levels:

Package level (e.g. com.company.billing.*)
Class level
Method level
Parameter level

This was fully parametrised as plugin configuration and ensured observability was applied only where it added real operational value.

If every single method was enabled for observability, we wouldn’t only get a lot of noise causing the trace trees to be unreadable, but it would also cause the application performance to degrade and quite severely. So balance was the key here.

Annotation Enrichment Model

We standardized on two core OpenTelemetry-related annotations:

@WithSpan for tracing execution boundaries
@SpanAttribute for enriching spans with contextual metadata

To support parameter-level observability, the plugin also required access to method parameter names at compile time. This was enabled by configuring the Java compiler with the appropriate flag: -parameters

This ensured parameter names were retained in the compiled bytecode, allowing them to be used as structured span attributes without manual declaration.

Flexible, Generic Design

Rather than building a narrowly scoped “OpenTelemetry plugin”, we deliberately designed the system as a generic annotation enrichment framework.

Through configuration, we could define:

Which annotations to apply
Where to apply them (class, method, parameter)
Whether parameter names should be automatically mapped as attributes
Which code regions should be included or excluded via regex rules

This made the solution reusable beyond observability — for any future bytecode-level enrichment use case.

Dual-Layer Observability Architecture

The build-time instrumentation layer was combined with a runtime observability stack:

OpenTelemetry Java Agent enabled via JVM arguments
Telemetry exported to a centralized OpenTelemetry Collector
Downstream integration with APM platforms such as Elastic and Datadog

This created a two-layer model:

Compile-time enrichment (our Maven plugin)
Runtime telemetry collection (OpenTelemetry agent)

Outcome: Observability as a Default Capability

Because all legacy applications inherited from a shared Maven parent, adoption was effectively automatic.

No application rewrites were required.
No developer workflow changes were introduced.
Instrumentation became a transparent build-time concern.

Over time, this approach evolved from a legacy modernization technique into a standard part of all new microservice development, effectively making observability a default architectural property rather than an afterthought.

Observability as a Bridge to Microservices

One of the most overlooked benefits of observability is its role as a bridge between legacy systems and microservices architectures.

By instrumenting legacy systems:

Existing workflows become traceable end-to-end
Bottlenecks and coupling points are identified
Candidate services for extraction become clear

This allows organizations to:

Decompose monoliths incrementally
Validate architectural decisions with real data
Reduce risk during migration

In this sense, observability is not just an operational tool — it is a strategic enabler of modernization.

The Human Factor in Transformation

Modernization is not purely a technical challenge. It is also deeply human.

Legacy systems are often maintained by teams who:

Have years of domain expertise
Understand system behavior beyond documentation
Are cautious about disruptive change

Introducing observability in a non-invasive way:

Builds trust within engineering teams
Demonstrates value without forcing immediate change
Encourages gradual adoption of modern practices

Successful modernization efforts recognize that people evolve alongside systems — not in parallel, and not under pressure.

A Pragmatic Path Forward

Organizations do not need to choose between stability and innovation. With the right approach, they can achieve both.

A pragmatic modernization strategy should:

Preserve and stabilize existing systems
Introduce modern capabilities incrementally
Use observability to gain visibility and control
Enable gradual transition toward cloud-native architectures

Observability is one of the first — and most impactful — steps in this journey.

Conclusion

The future of enterprise systems is not built by discarding the past, but by extending it intelligently.

Legacy systems still power some of the most critical operations in finance, insurance, healthcare, and government. Replacing them entirely is often unrealistic. However, leaving them unchanged is equally unsustainable.

By enabling observability through non-invasive techniques, organizations can:

Unlock visibility into complex systems
Reduce operational risk
Accelerate modernization efforts
Build a foundation for scalable, cloud-native architectures

Modernization is not a single event — it is a continuous evolution.
And in that evolution, observability is not just a tool.
It is a bridge between what exists and what comes next.