Delivery and product
Move to microservices with a plan
The decision to leave the monolith is made, but the order, the boundaries and the platform are not. We find the boundaries, sequence the move and deliver the first services with your teams.
- Duration
- 4 to 12 months
- Model
- Staged programme
- Output
- First services live and a sequenced plan
Signs the monolith is holding the teams back
The problem is rarely the monolith itself. It is that every team has to change the same code at the same time.
- Teams wait for each other because every feature touches the same codebase and the same release.
- A full build and test run takes so long that engineers batch their changes to avoid it.
- One part of the system needs to scale, but the only option is to scale all of it.
- The move to microservices was announced, yet nobody can say which service comes first, or why.
- A first service was extracted, but it still shares the database with the monolith.
- The number of services grows, but deployment, monitoring and on-call have not kept up.
- Different teams build services with different conventions, and the result already looks like a distributed monolith.
Boundaries before services
Most failed microservice migrations cut the system along technical layers or along the org chart of the day. The result is services that must change together, call each other constantly and share data: a distributed monolith with extra network hops.
We start with the domain. Using domain-driven design, we find the bounded contexts where data ownership and change patterns line up, and we rank them by how much independence they would give your teams. Sometimes the right answer for part of the system is a modular monolith, and we say so.
The move is sequenced so that each extraction is small, reversible and useful on its own. Platform prerequisites such as deployment, observability and service templates are put in place before the number of services grows, not after.
Scope
Included
- Domain and bounded context discovery
- Ranking of candidate services by team independence and risk
- Migration sequence with exit criteria for each step
- Data ownership split and synchronisation during the transition
- Service template: build, deploy, observe, secure
- Delivery of the first three services with your teams
- Architecture governance for new services
- Measurement of delivery speed before and after
Not included
- Rewriting the whole system in one go
- Splitting everything into services regardless of value
- Team reorganisation and HR decisions
- Long-term operation of the services after handover
How the programme runs
- Months 1 to 2Find the boundaries. Event storming and code analysis reveal the bounded contexts. Candidate services are ranked, and the target is drawn as a context map.
- Months 2 to 3Prepare the platform. A service template, a deployment pipeline and an observability baseline are set up so that every new service starts the same way.
- Months 3 to 9Extract in sequence. The first services are extracted one at a time with your teams, each with its own data and a way back until it is proven.
- Final monthsGovern and hand over. Decision records, a review rhythm and the remaining sequence are handed over, so your teams can continue without us.
What you receive
The services, the template and the plan are yours from the first day.
Who this service is not for
- Small teams working on a single product. A well-structured modular monolith usually serves them better, and we will recommend it.
- Organisations expecting us to deliver all the services. The goal is teams that can carry on alone.
- Migrations with a fixed end date for the whole system, decided before the boundaries are known.
Frequently asked questions
What if microservices are not the right answer for us?
Then we say so. For part or all of the system, a modular monolith with clear internal boundaries is often the better choice, and the context map is useful either way.
How do you handle the shared database?
Data ownership moves with each service. During the transition, data is synchronised with events or change data capture, and the old tables are retired once the service owns its data.
Which service should come first?
Usually one with clear boundaries, real value to a team and limited coupling. The first extraction proves the template and the platform, so a low-risk candidate is worth more than a spectacular one.
How is this different from System Modernisation?
System Modernisation focuses on replacing ageing code without stopping it. This programme focuses on team independence: boundaries, services, platform and governance.
Do our teams need to change?
Service boundaries work best when they match team ownership. We show where they diverge and what that costs; the organisational decisions stay with you.
Start with a short technical call
Thirty minutes. You describe the monolith and the teams around it, and we tell you where the first boundary is likely to be.