Spring Modulith, first hand
We teach a dedicated Spring Modulith training and use the framework in delivery work. The same reasoning and practical exercises inform both.
Application Modernisation
The system pays the bills, but changes carry increasing delivery and operational risk. Upgrades are overdue, and the proposals on the table are a rewrite or a microservices programme the organisation cannot yet operate. We modernise legacy Java systems incrementally, often towards well-bounded modular monoliths with Spring Modulith, and plan the work around production and delivery obligations.
Fixed-scope discovery first, then delivery in increments.
The situation we are usually called about
A legacy system becomes a delivery problem when coupling, unsupported dependencies, and weak feedback loops make every change harder to assess.
-
Change has become expensive
A feature that took days now takes weeks. Everything touches everything, no boundary holds, and estimates have stopped meaning anything. The team spends more time navigating the code than improving it.
-
Upgrades were postponed too long
The JDK is old, the framework is out of support, and security findings are piling up. Each postponed upgrade can make the next one larger and narrow your support options.
-
The rewrite is on the table
Starting over may be one option, but it also concentrates delivery risk and creates a long period in which old and new capabilities must be reconciled. The decision needs evidence, not a default preference.
-
Network boundaries came before domain boundaries
Moving existing coupling across a network can add latency, partial failure, and operational overhead without creating independent capabilities. We establish and test boundaries before deciding whether separate deployment is worthwhile.
How we modernise
Where separate deployment is not justified, a modular monolith provides explicit boundaries without adding distributed-system operations.
-
Module boundaries with Spring Modulith
We carve the system into modules along domain lines and make the boundaries executable: Spring Modulith checks them in the build, so boundary violations are detected during development rather than remaining hidden.
-
Strangler-fig migration
New structure grows around the old code slice by slice. We design each slice with a release and rollback approach appropriate to the existing system, and coordinate it with ongoing feature work.
-
Domain events over hidden coupling
Modules communicate through explicit events and published APIs instead of reaching into each other’s tables and internals. That is what makes independent work – and later extraction – possible.
-
Tests that reduce change risk
Characterisation tests capture important current behaviour before we change it. Module-level tests then protect boundaries and reduce uncertainty during refactoring.
-
Platform and framework upgrades
JDK and Spring Boot upgrades, dependency risk reduction, build-pipeline modernisation, and – where it pays off – startup and footprint optimisation up to GraalVM native images.
-
Observability as a deliverable
Actuator, Micrometer, and OpenTelemetry wired in as we go, so every migrated slice is observable. Production evidence can then guide the next slice.
How the engagement runs
Discovery first, then increments. You commit to one slice at a time and can stop after any of them.
-
Discover
A fixed-scope discovery: we analyse the estate, map domain boundaries and change coupling, and identify the riskiest dependencies. You get a modernisation roadmap with slices ranked by value and risk – useful even if you deliver it without us.
-
Stabilise
Before restructuring, we reduce uncertainty: characterisation tests around the critical paths, a trustworthy build pipeline, and the platform upgrades that unblock modern tooling.
-
Migrate slice by slice
We extract one module at a time along the roadmap – boundaries enforced by Spring Modulith and communication moved to events and APIs. Release sequencing follows the constraints identified in discovery.
-
Hand over
Your team works in the migration from day one – pairing, reviews, and our Spring Modulith training where useful. The goal is a team that continues the roadmap without us.
What you get
A prioritised roadmap and delivered slices aimed at reducing the cost and risk of subsequent change.
- A modernisation roadmap with slices ranked by business value and risk
- Module boundaries that are verified in the build, not just drawn in a diagram
- A release and rollback approach for each agreed migration slice
- Current JDK and Spring versions, with dependency risk under control
- Tests and observability that reduce uncertainty in subsequent changes
- Documented boundaries that support later service extraction if the evidence justifies it
- Boundaries, APIs, tests, and observability that can also support controlled AI integrations – see our AI readiness checklist
- Pairing, reviews, and training to support your team’s handover
Who this is for
-
CTOs and engineering managers with a legacy estate
You run business-critical Java systems that have outlived their structure, and you need delivery speed back without betting the company on a rewrite.
-
Teams facing an expensive decision
You need evidence to compare incremental improvement, replacement, a modular monolith, and service extraction before committing budget and people.
-
Organisations preparing for AI
You want agents or AI features, but the estate lacks the boundaries, APIs, tests, or observability needed for controlled integration. Modernisation can address those gaps where the wider business case supports it.
-
Teams revisiting a transformation
A previous modernisation stalled or a service split added complexity. We start from the system, delivery data, and constraints you have now.
Why us
We work on exactly this class of system – production Java and Spring – and we teach the method we use.
Senior eyes on the code
Patrick Baumgartner brings more than 20 years of enterprise Java experience and works directly with the code, evidence, and people responsible for the system.
Evidence over fashion
We do not sell a target architecture. Discovery produces the evidence, the roadmap follows the evidence, and “keep it and improve it” remains a valid recommendation.
Designed to end
Pairing, reviews, and training are built into the migration so the capability stays when we leave. Our success is your team continuing the roadmap without us.
Not sure the problem is the architecture? Start with an independent architecture review. If the constraint is how the team works, look at developer coaching.
Frequently Asked Questions
Do we have to rewrite the system?
Not necessarily. Discovery compares incremental change, replacement, and retention against the system’s risks and business constraints. We prefer smaller migration slices when the evidence supports them.
Why a modular monolith instead of microservices?
A modular monolith can provide explicit, testable boundaries without introducing network and operational complexity. If a module later has a justified need for independent deployment, established boundaries make that decision easier to assess.
Does development stop during modernisation?
We plan migration slices around normal feature work and production obligations. The release and rollback approach depends on the existing system, so discovery identifies where parallel delivery is practical and where extra stabilisation is needed.
Can you also upgrade our Java and Spring versions?
Yes. Framework and JDK upgrades, dependency risk, and build-pipeline improvements can be included when they reduce risk or make the next migration slice feasible.
Is this how we get ready for AI?
It can help when AI work depends on clearer boundaries, controlled APIs, tests, or observability. Modernisation should still be justified by the system’s business and engineering needs, not by AI alone. Our AI readiness checklist can structure that discussion.
What does it cost?
The fixed-scope discovery produces the modernisation roadmap. Delivery is then priced in increments, so you commit to one slice at a time.
Plan the next modernisation step
Book 30 minutes with Patrick. Bring the system, the decision on your table, and the constraint creating the most delivery risk. We will assess whether modernisation is the right move – and what the first slice would be.