Microservices Migration Roadmap: 12-Month Plan With Strangler Fig

9 min read ยท 2026-10-25

A microservices migration roadmap is a phased plan for moving a monolithic application to independently deployable services, one business capability at a time, while the product keeps running and shipping. It sets the order of extraction, the platform work that must come first, how data will be split, which team owns each service and how you will measure that the move is paying off.

Most teams use the strangler fig pattern: new or extracted functions go into services behind a routing layer, and the monolith shrinks over time instead of being rewritten in one go. The 12-month template below follows that approach. It is written for engineering managers, architects and technical program managers who need a plan they can run and defend. It includes a filled-in example, who owns what, the metrics to report and the traps that turn migrations into multi-year stalls.

The roadmap at a glance

Goal: Within 12 months, three business capabilities run as independent services owned by stream-aligned teams, behind a routing layer, with their own data, CI/CD pipelines and monitoring, and the monolith no longer changes for those areas. Duration: 12 months

  1. Why, what and baseline (Weeks 1-4)

    Agree on the business reason for the migration and measure today's delivery performance.

    • Write the problem in business terms, such as releases blocked by unrelated changes or one module that cannot scale on its own.
    • Measure the current baseline with DORA metrics: deployment frequency, lead time for changes, change failure rate and time to restore service.
    • Map the monolith's modules, their dependencies, shared tables and the teams that change each one.
    • Agree on a stop rule with leadership: what result would make you pause or change course.

    Milestone: A one-page migration brief with the business problem, DORA baseline and dependency map, approved by the CTO or VP of engineering.

  2. Domain map and extraction order (Weeks 3-8)

    Decide where the service boundaries are and which ones to extract first.

    • Run event storming or domain workshops with product and engineering to find bounded contexts.
    • Score each candidate on business value, change frequency, coupling to the rest of the code and data entanglement.
    • Pick a first service that is valuable but loosely coupled, such as notifications or search, rather than the core of the system.
    • Draft the target team structure, with each future service owned by one team.

    Milestone: A context map with a ranked extraction order and a named owning team for the first three services.

  3. Platform foundations (Weeks 6-14)

    Build the paved road every service will use, before the first extraction.

    • Set up a CI/CD pipeline template so a new service can be built, tested and deployed the same way every time.
    • Put a routing layer, such as an API gateway or reverse proxy, in front of the monolith to direct traffic between old and new code.
    • Add centralized logging, metrics and distributed tracing, for example with OpenTelemetry.
    • Agree on standards for service APIs, versioning, authentication between services and secrets management.

    Milestone: A sample service deployed to production through the template pipeline, visible in logs, metrics and traces, with routing in place.

  4. First extraction (Weeks 14-24)

    Move one capability out of the monolith end to end and learn from it.

    • Build the service behind the routing layer and send a small share of traffic to it first.
    • Compare results between old and new code paths, then increase traffic in steps.
    • Move the capability's data to its own store, using a sync or change data capture during the transition.
    • Remove the old code path from the monolith once the service handles all traffic.

    Milestone: First service handles all production traffic for its capability, owns its data, and the old code is deleted from the monolith.

  5. Repeat and split the data (Weeks 24-44)

    Extract the next two capabilities faster, using what you learned.

    • Hold a retrospective on the first extraction and update the template, standards and checklist.
    • Extract the second and third services in parallel only if each has its own team and no shared tables.
    • Replace direct database reads across boundaries with APIs or events.
    • Write runbooks and on-call rotations for each service before it takes full traffic.

    Milestone: Three services in production, each with its own data store, runbook and on-call owner.

  6. Measure and decide what is next (Weeks 44-52)

    Show the results and decide how far to take the migration.

    • Compare DORA metrics and incident data for the extracted areas against the baseline.
    • Review cloud and tooling costs for the new services with finance.
    • Decide which remaining parts of the monolith to extract and which to leave as a well-structured modular core.
    • Publish next year's roadmap with the extraction order and team changes.

    Milestone: Year-end review presented to leadership with metrics against baseline and an approved plan for the next 12 months.

Should you migrate at all?

Microservices solve specific problems: teams blocking each other in one codebase, parts of the system that need to scale or deploy independently, and slow releases because everything must be tested together. They also add costs: network calls instead of function calls, distributed data, more pipelines, more monitoring and more on-call work.

Before you commit, check whether a modular monolith would solve your problem. Clear module boundaries, separate ownership and enforced internal APIs inside one deployable unit can fix many coupling issues at a fraction of the effort. Many teams do this first and extract services only where independent deployment or scaling really matters. Write that decision in the migration brief so leadership knows what was considered.

Example: a filled-in roadmap for an e-commerce platform

Picture an online store running a ten-year-old monolith with four teams working in one codebase. Releases happen every two weeks after a long regression cycle, and a slow search feature hurts sales during peaks. The goal is faster, independent releases for the teams that change most often.

The order matters. Notifications goes first because it is loosely coupled and low risk, which lets the team prove the platform. Search follows because it brings clear business value. Checkout stays in the monolith for now because it touches orders, payments and stock.

  • Q1 (owners: VP engineering and principal architect): DORA baseline, event storming, context map, extraction order agreed. Platform team starts pipeline template and API gateway. Milestone: sample service in production.
  • Q2 (owner: customer engagement team): notifications service extracted, email and SMS traffic moved in steps, old code deleted. Milestone: all notifications sent by the new service.
  • Q3 (owner: discovery team): search service with its own index fed by product change events. Milestone: search runs independently and scales on its own during a peak.
  • Q4 (owners: accounts team and platform team): customer profile service, retrospective, cost review. Milestone: year-end review approved with next year's order.

How to split the data

Code is the easy part. Shared databases are where most migrations stall. A service that still reads and writes the monolith's tables is not independent, because a schema change in one place can break the other. Plan the data split for each service explicitly, with its own steps and milestones.

A common sequence works like this. First, the new service reads from the shared tables through a clear interface. Then it gets its own store, kept in sync with the monolith by events or change data capture. Finally, the monolith stops writing that data and reads it from the service's API instead. Accept that some data will be eventually consistent, and agree with product owners where that is fine and where it is not.

Who owns what

Conway's law applies: your services will mirror your team structure. If one team owns five services and another owns pieces of each, the boundaries will blur. Plan team changes alongside the technical roadmap, not after it.

Give the program a technical program manager or an engineering manager who owns the overall plan, the dependency board and the monthly update. Architecture decisions should be written down as short decision records so new team members understand why a boundary sits where it does.

  • CTO or VP engineering: sponsor, approves the business case, extraction order and team changes.
  • Principal architect: owns the context map, standards and architecture decision records.
  • Platform team: owns the pipeline template, routing layer, observability and developer documentation.
  • Stream-aligned teams: each owns its service from code to production, including on-call.
  • Product managers: confirm boundaries match how the business works and accept consistency trade-offs.
  • Technical program manager: owns the roadmap, dependency tracking, risk log and stakeholder updates.
  • Security: reviews authentication between services, secrets handling and network policies.

Metrics to track

Report results, not activity. The number of services is not a success metric. What leadership cares about is whether teams ship faster and more safely, and whether the system is more reliable and cost-effective.

Measure the baseline in the first month and report the same metrics each quarter for the extracted areas and for the remaining monolith.

  • Deployment frequency: deploys per team per week, from your CI/CD tool.
  • Lead time for changes: time from commit to production, from your pipeline data.
  • Change failure rate: share of deployments that cause an incident or rollback.
  • Time to restore service: median time from incident start to recovery, from your incident tool.
  • Monolith change share: share of commits that still touch the monolith, which should fall over time.
  • Running cost: infrastructure and tooling cost per service, reviewed with finance each quarter.

How to present it to leadership

Executives do not need the context map. They need the business problem, the plan in quarters, the cost in people and time, and how you will know it worked. Use one slide with a timeline: each quarter shows the service being extracted, the owning team and the business result, such as search scaling on its own during peaks. Add a second line for platform work so the first months do not look empty.

Be clear about what stops during the migration. If two teams spend part of their time on extraction, some features move out. Show that trade-off on the slide and ask leadership to confirm it. Report every quarter with the DORA metrics against the baseline and the decision for the next quarter: continue, adjust or pause.

Common mistakes to avoid

  • Starting with a full rewrite freezes features for months and often fails, so extract one capability at a time behind a routing layer with the strangler fig pattern.
  • Extracting the most central module first creates huge risk, so start with a valuable but loosely coupled capability to prove the platform.
  • Leaving services on a shared database keeps them tightly coupled, so plan a data split with its own milestones for every service.
  • Skipping platform work means each team builds its own pipeline and logging, so build a paved road with templates and observability before the first extraction.
  • Splitting code without changing team ownership produces services nobody fully owns, so assign each service to one team that runs it in production.
  • Counting services as progress hides whether delivery improved, so report DORA metrics and incidents against the baseline every quarter.

Frequently asked questions

What is a microservices migration roadmap?

It is a phased plan to move a monolithic application to independent services over time. It covers the business case, service boundaries, extraction order, platform foundations, data split, team ownership and the metrics that show progress. Each phase has an owner and a checkable milestone.

What is the strangler fig pattern?

It is a migration approach where new or extracted functions are built as separate services, and a routing layer sends traffic to them instead of the old code. Over time, more functions move out and the monolith shrinks until it can be retired or kept as a small core. It avoids a risky all-at-once rewrite.

How long does a migration from monolith to microservices take?

It depends on the size of the monolith, how tangled its data is and how many teams can work on it. A first service with platform foundations often takes several months, and a full migration of a large system can take years. Many teams never extract everything and keep a modular core.

Which service should you extract first?

Pick a capability that has clear business value, changes often and has few dependencies on the rest of the code and data. Notifications, search or reporting are common first choices. Avoid starting with the core transaction flow.

How do you measure the success of a microservices migration?

Compare delivery and reliability metrics against a baseline taken before the migration, usually the four DORA metrics. Add the share of changes that still touch the monolith and the running cost per service. Review them every quarter with leadership.

Generate this roadmap with AI