Case study · Transaction platform
Monolith to Microservices on AWS ECS
Decomposed a 24+ module transaction monorepo into independently deployable services while preserving external API contracts and workflow orchestration.
All consulting services
Consulting · Platform modernization
Migrate your monolith to microservices without breaking existing APIs.
I help engineering teams break apart tightly coupled applications into independently deployable services while existing clients keep calling the same endpoints. The work is incremental by design: one service at a time, validated against real production traffic, with a rollback that is a single parameter flip.
01Who this is for
Where this work fits
You might recognize
- Teams where one shared deployable forces every release to be coordinated across unrelated modules.
- Platforms with external API consumers who cannot be asked to change their integration on your schedule.
- Organizations that have attempted a big-bang rewrite before and need an incremental path instead.
- Teams running workflow orchestration that must keep working across a service split.
What it costs you
- Release cycles stretch because unrelated changes ship together and a single regression blocks everything.
- Change becomes risky: any edit can affect modules nobody intended to touch.
- Scaling is all-or-nothing when one deployable cannot be scaled per workload.
- Rewrites that break client contracts cost integration work across every downstream consumer.
02Approach
How the migration runs
The order matters more than the tooling. Each step exists to keep the next one reversible.
Inventory what clients actually call
Access logs, not the API spec, define the contract you must preserve. This comes first because every later decision depends on it.
Find boundaries in the domain, not the folder structure
Service boundaries follow transaction and business domains, and stay compatible with existing workflow orchestration.
Put a routing layer in front
A reverse proxy keeps external routes stable while services move behind it, so consumers see no change during the migration.
Migrate one service at a time
Each cutover is validated against production traffic patterns, with promotion gates and an exercised rollback rather than a documented one.
Plan the retirement of the compatibility layer
Transparent rewrites become permanent architecture if nobody sets a date. Legacy routes move to permanent redirects and are then removed.
03Tradeoffs
What each choice costs
Every one of these has a downside. Here is what you are accepting and what you get for it.
Incremental migration over a big-bang rewrite
Slower on paper, and it means running two systems for a while. In exchange, every step is reversible and the business keeps shipping throughout.
A compatibility layer over asking clients to migrate
Adds a routing hop and a second routing table to maintain. It also removes the need to coordinate a cutover with every downstream consumer at once.
Workflow tests before the first extraction
Delays the first visible milestone. It is also the safety net that makes every subsequent cutover faster, and the thing I would do earlier next time.
04Deliverables
What you get from a review
Scoped as a focused assessment. Anything beyond this is agreed before it starts, not assumed.
- A service boundary map derived from the real domain and the routes clients actually call.
- A prioritized migration roadmap with the order of extraction and the risk at each step.
- A routing and compatibility design that keeps external contracts stable during the move.
- A rollback and promotion-gate plan, with the retirement window for legacy routes agreed up front.
- Written technical risks and the open questions worth resolving before work starts.
05Evidence
This is not theoretical
The approach above describes work I led, not a framework I read about.
Technical write-up
Migrating a Monolith to ECS Microservices with Zero Client Changes
The implementation detail behind the approach: routing rules, promotion gates, rollback, and retiring the compatibility layer.
Next step
Tell me what your monolith looks like.
Where it hurts, who calls your APIs, and what you have already tried. I'll tell you whether an incremental migration is the right call — including when it isn't.