CASE STUDY · LEGACY SYSTEM MODERNIZATION
Migrating a decade-old Java monolith to microservices without downtime.
- 30 minutesCutover with under 30 minutes of planned unavailability and no data loss
- 2 weeksRelease cycle down from 2 weeks to 2 days
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Module-by-module mapping, new services placed in front of the old system, and a dual-run migration with checksums and reconciliation. Team: a solution architect, two engineers and a QA specialist; 8 weeks of parallel running.
- 1The company ran its core platform on a 12-year-old Java monolith.
- 2It worked, but every release took 2 weeks.
- 3Changes in one area broke another.
- 4Traffic and integrations kept growing, and each release carried more risk than the last.
- 5The business could not accept a long outage, and there was no appetite for a risky rewrite.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01During the parallel run, the reconciliation job reported small differences in one reporting table
The old system rounded values in a way that was nowhere in the documentation. It had been written into a stored procedure years earlier. Our new service calculated the numbers correctly by the book, but not the way the business had always seen them.
- PROBLEM 02Our new service calculated the numbers correctly by the book, but not the way the business had always seen them
- PROBLEM 03We did not guess
We sat with the finance team, confirmed which result they relied on, and reproduced the old rounding rule on purpose. We documented it, added a test, and marked it for review later. It was a good reminder of why we run both systems side by side.
- PROBLEM 04It was a good reminder of why we run both systems side by side
03 · THE PROCESS
How we ran it.
We split the work into four phases.
- 01Mapping
we read the monolith module by module and traced every integration, scheduled job and database table. We held weekly sessions with the client's longest-serving engineers to confirm what we found.
- 02Seam selection
we chose the first modules to move based on clear boundaries and low coupling. High-risk, tangled areas went last.
- 03Build and prove
new services were built behind the old entry points, with contract tests that compared old and new responses.
- 04Parallel run and cutover
both systems processed live work for 8 weeks, then we cut over in a short planned window.
We kept a daily standup with the client's engineers and a weekly review with their management.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Releases are small and routine, and no longer an event the whole company worries about.
- NOW 02
The system is documented, and new engineers can read how it works.
- NOW 03
Business rules are written down and covered by tests.
- NOW 04
The team uses the same routing and flag approach when it changes other parts of the platform.
- 30 minutes
Cutover with under 30 minutes of planned unavailability and no data loss
- 2 weeks
Release cycle down from 2 weeks to 2 days
Old system retired after the parallel run
05 · WHAT WE BUILT
How it works.
- We placed a routing layer in front of the monolith.
- It sent each capability to either the old code or a new service.
- That let us move traffic gradually and switch it back in seconds.
- For data, we used a dual-run migration.
- Writes went to both systems.
- A reconciliation job compared row counts, key fields and checksums on a schedule, and flagged any difference for review.
- What went wrong, part two
- One integration was missed in the first map. A partner sent files to a fixed address on the old system each night. It was not in any document, and no code in the monolith called it by name. We found it only because traffic logs showed an unexpected inbound connection during the parallel run. We added the route to the new layer and updated the map. After that, we reviewed network logs for every module before it moved.
- Handover
- In the final stage we held walkthroughs with the client's engineers on the routing layer, the reconciliation job and the rollback steps. They ran one rollback drill themselves before cutover.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company ran its core platform on a 12-year-old Java monolith. It worked, but every release took 2 weeks. Changes in one area broke another. Traffic and integrations kept growing, and each release carried more risk than the last. The business could not accept a long outage, and there was no appetite for a risky rewrite. Only a few people understood how the whole system fitted together.
- What did Brandsmashers build?
- Module-by-module mapping, new services placed in front of the old system, and a dual-run migration with checksums and reconciliation. Team: a solution architect, two engineers and a QA specialist; 8 weeks of parallel running.
- How was the work run?
- We split the work into four phases.
- What were the results?
- Cutover with under 30 minutes of planned unavailability and no data loss; release cycle down from 2 weeks to 2 days; old system retired after the parallel run.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
