A cloud-native microservices migration moves a monolithic or legacy application, one capability at a time, into small services that are built, deployed and scaled independently on containers, Kubernetes or serverless platforms. It pays off when a single codebase is slowing several teams down or parts of the system need to scale very differently. For many smaller teams, a well-structured modular monolith is the better first move.
If you are moving a whole estate rather than one application, start with our cloud migration playbook.
When microservices are worth it, and when a modular monolith is the better call
Microservices solve an organisational problem more than a technical one: they let separate teams release their part of a system without coordinating every deployment. With one team of eight engineers that benefit barely exists, while the costs (network calls, distributed data, more pipelines, more to monitor) arrive on day one.
Martin Fowler’s Monolith First argument still holds. Most successful microservice systems began as a monolith that outgrew itself, and moving functionality between services is much harder than moving it inside one codebase, so boundaries drawn too early are expensive to fix.
Microservices tend to be worth the overhead when several of these are true:
- Three or more teams regularly block each other on one codebase or release train.
- Parts of the system have very different load, such as search or media processing that must scale separately from billing.
- Some components need their own release cadence, runtime or compliance boundary.
- The domain is understood well enough to draw stable boundaries around business capabilities.
A modular monolith is the better call when the team is small, the domain is still changing, or the real pain is tangled code rather than deployment contention. You enforce module boundaries inside one deployable, with internal APIs and no reaching into another module’s tables. If you later need to extract a module, the seams are already there.
If the system mainly needs to leave old hardware or an unsupported runtime, rehosting or replatforming may be enough. Our guide to legacy system modernisation compares those options.
How the strangler-fig migration works, step by step
The strangler-fig approach replaces a legacy system gradually instead of rewriting it in one go. A routing layer in front of the old application sends each request to the monolith or to a new service, so users see one system throughout (Microsoft’s pattern guide covers the mechanics). Fowler argues the lower risk and earlier value outweigh the cost of the temporary code it needs.
The steps
- Map the system and agree outcomes. Inventory modules, dependencies, data stores and integrations, and agree what success means. Without that, the migration becomes an architecture project with no end.
- Add tests and telemetry to the monolith. Characterisation tests record what the system does today, and tracing shows which calls and queries each feature makes. Both are the safety net for every later step.
- Put a facade in front. An API gateway or Kubernetes Gateway API route takes all traffic and initially forwards everything to the monolith. Run it redundantly so it is not a single point of failure.
- Choose the first slice. Pick a capability with clear boundaries, real value and few inbound dependencies, such as notifications or document generation. Leave the core transaction flow for later.
- Build the service with an anti-corruption layer. The new service gets its own code, pipeline and data; a translation layer keeps legacy data models out.
- Shift traffic gradually. Send a small percentage or one customer segment to the new service, compare results with the monolith, then increase. Feature flags and canary releases keep rollback quick.
- Delete the old code. Remove the retired module and its tables from the monolith, or you will run two systems indefinitely.
Then repeat with the next slice. Each cycle should get faster as pipelines and habits mature.
Splitting the data
Data is where most migrations stall. If the new service still writes to the monolith’s tables, you have moved code but not ownership, and every schema change still needs a meeting.
Microsoft’s guidance sets out a safe sequence. The new service first uses the legacy tables, then gets its own database, seeded by a one-off load and kept in sync with change data capture (Debezium is a common tool). After consistency checks it becomes the system of record, and rollback stays possible until the legacy tables are dropped.
Expect cross-domain joins and transactions to become events and eventual consistency. The transactional outbox pattern keeps data changes and their events in step, and sagas coordinate multi-service workflows. If two capabilities truly need strong consistency, they probably belong in one service.
Containers, Kubernetes or serverless: where should services run?
Containers are the common unit for almost every option, so the real decision is how much platform you want to operate yourself. Kubernetes is the default for teams that need control: the CNCF’s latest annual survey found 82% of container users run Kubernetes in production. That does not make it the right first step for a small team.
| Option | Good fit | Trade-offs |
|---|---|---|
| Managed Kubernetes (EKS, AKS, GKE) | Many services, mixed workloads, fine control over networking and autoscaling (KEDA, Karpenter) | Highest operational load; needs platform skills, upgrades and active cost management |
| Managed container platforms (Cloud Run, Azure Container Apps, ECS on Fargate) | A handful to a few dozen stateless services and workers | Less control; usage-based pricing can climb under sustained heavy load |
| Serverless functions (AWS Lambda, Azure Functions) | Event handlers, scheduled jobs, spiky low-volume work | Cold starts, execution limits, per-invocation cost at high volume |
| Modular monolith in a container | Small team, unsettled domain, early migration | Scales as one unit; boundaries need discipline |
Many teams mix these: a managed container platform for most services, functions for event handlers, and Kubernetes only once the service count and skills justify it. Containerise the monolith early so old and new code share one deployment path.
Why observability and a platform come before the tenth service
Across services, one request may cross a gateway, five services and two queues, so a stack trace no longer tells the story. You need distributed tracing from the first extracted service.
OpenTelemetry is the standard way to get it: one set of APIs and SDKs for traces, metrics and logs, sent to the backend of your choice without vendor lock-in. Instrument the monolith too, so traces show the full path through old and new code.
Platform engineering stops each team rebuilding pipelines from scratch. A platform team offers a paved road: service templates, CI/CD, GitOps with Argo CD or Flux, secrets and default telemetry, often behind a portal such as Backstage. DORA’s 2025 research found 90% of organisations have adopted at least one platform.
For a smaller company, a shared template repository and a few documented pipelines are enough, as long as the tenth service is cheaper to create than the second.
Using coding agents to speed up refactoring safely
Coding agents such as Claude Code, OpenAI Codex and GitHub Copilot’s coding agent now handle much of a migration’s mechanical work: mapping call graphs, writing characterisation tests, extracting modules and upgrading frameworks. Through Model Context Protocol (MCP) servers they can also read tickets, logs and traces. AWS Transform applies agents to .NET and mainframe modernisation.
The guardrail is tests. Anthropic’s Claude Code best practices are blunt: give the agent a check it can run, and if you cannot verify a change, do not ship it. Pin current behaviour with tests first, review them yourself, then let the agent refactor until they pass without editing them.
DORA makes the same point at team level: AI adoption still has a negative relationship with delivery stability unless strong automated testing and fast feedback are in place. Keep agent changes small, put them through the same pipeline as human changes, and have someone other than the author review each diff.
A realistic six-month roadmap, with costs and ROI
Six months is enough to build the foundations and move two to four meaningful capabilities out of a medium-sized monolith. It is rarely enough to retire the whole thing.
| Month | Focus | Exit criteria |
|---|---|---|
| 1 | Dependency and data map, outcome metrics, target platform, first slice | Baseline delivery metrics and hosting cost recorded |
| 2 | Containerise the monolith, CI/CD, facade, OpenTelemetry, characterisation tests | Monolith deploys through the new pipeline; traces visible end to end |
| 3 | First service built, shadow traffic, canary release | First service live with rollback tested |
| 4 | First service gets its own data via change data capture; second slice starts | First service is system of record; its legacy tables retired |
| 5 | Second and third slices; service templates hardened | New services created in days, not weeks |
| 6 | Compare against the baseline | Written decision to continue, pause or settle on a modular monolith |
What drives the cost
- Tangled data: shared tables, stored procedures and cross-domain reports take the most effort.
- Test coverage: few automated tests means building that safety net first.
- Integrations and consumers that must be repointed.
- Platform skills: running Kubernetes well needs people who know it.
- Double running: the monolith and new services run side by side.
Watch running costs from the first service. Flexera’s latest State of the Cloud survey found organisations estimate 29% of their cloud spend is wasted, and 85% call managing spend a top challenge. Tag every service by owner, set budgets per environment and review unit costs, such as cost per order, every month.
How to judge the return
Measure the month-one outcomes against the baseline: deployment frequency, lead time, change failure rate and recovery time for the migrated areas, plus hosting cost per unit of business activity and the business measure that justified the work.
If those numbers are not moving after two or three slices, stop and reassess. A cleaner modular monolith plus a few extracted services is a legitimate result.
Failure modes that sink migrations, and how to fix them
| Failure mode | What it looks like | Fix |
|---|---|---|
| Distributed monolith | Services must be deployed together; one change touches five repositories | Redraw boundaries around business capabilities; merge services that always change together |
| Chatty services | One page load triggers dozens of synchronous calls, so latency and failures multiply | Coarser APIs, local read models fed by events, asynchronous messaging where no instant answer is needed |
| Shared database | Several services write the same tables; schema changes need cross-team sign-off | One owning service per table; others use its API or events |
| Big-bang rewrite | A parallel system built for a year with no production traffic | Strangler-fig slices carrying real traffic within the first quarter |
| Too many services too soon | More services than engineers | Start coarse; split only when a team or scaling need demands it |
The most stubborn failures are organisational. In the CNCF survey, cultural change within development teams was the top challenge, cited by 47% of respondents. Align team ownership with service boundaries, or the architecture will drift back towards the old structure.
How Pixelpk approaches this
Pixelpk Technologies is an AI and software development company founded in 2018 and headquartered in Lahore, with offices in Malaysia, the UK, Australia, Saudi Arabia and the US. Our 50+ team members have shipped more than 1,000 projects, we are rated 4.9/5 on Clutch, and we build and run our own AI products in production, including Aivastark and AITube.
We work as an Extended Team alongside your engineers, a Managed Dedicated Team that owns a defined part of the work, or through custom solution development for a set scope. For short-term Kubernetes or data skills, staff augmentation is often simplest. Browse our case studies or book a free strategy call to discuss whether your system needs microservices at all.
Frequently asked questions
How long does a monolith to microservices migration take?
For a medium-sized application, six months is a realistic window to build the foundations and move two to four capabilities into production services. Fully retiring a large legacy system takes considerably longer, depending on how tangled the data is, existing test coverage and how many integrations depend on the monolith. Plan in slices and review after each.
Is a modular monolith better than microservices?
For small teams and domains that are still changing, often yes. A modular monolith keeps one deployable and one database but enforces clear boundaries between modules, so you get most of the maintainability benefit without network calls and distributed data. Microservices become worth their overhead when several teams block each other or parts of the system need to scale or release independently.
What is the strangler-fig pattern?
The strangler-fig pattern replaces a legacy system gradually. A routing layer sits in front of the old application, and you move one capability at a time into a new service, shifting traffic once it is proven and then deleting the legacy code. Users see one system throughout, and the migration can pause at any point without leaving the business stranded.
How much does a microservices migration cost?
There is no honest fixed price. Cost depends on how tangled the data is, existing test coverage, the number of integrations, the target platform and the team’s experience with it. You also pay to run old and new systems side by side. Estimate per slice after a short assessment, and track cloud spend per service from the start.
Can AI coding agents migrate a legacy system on their own?
No. Coding agents speed up the mechanical work, such as mapping dependencies, writing characterisation tests and extracting modules, but they need tests they can run and people who review the plan and the diff. Keep their changes small, tested and reviewed in the normal pipeline. Service boundaries, data ownership and when to stop are still decisions for experienced engineers.