Migrating a monolith to microservices is one of the most complex decisions a tech team can make. Done well, it unlocks independent scaling and team autonomy. Done poorly, it creates a distributed monolith with all the operational cost of microservices and none of the benefits. This is how to do it incrementally, and how to know whether you should.

First, decide whether to migrate at all

Most applications do not need microservices. The problems people blame on the monolith, slow deploys, tangled code, teams stepping on each other, are usually solved by a modular monolith: clear module boundaries, enforced dependencies, one deployable. Move to services when a specific part needs to scale or deploy independently, or when teams genuinely cannot work without blocking each other, not because the architecture is fashionable.

Prerequisites before you extract anything

• ✓Distributed tracing and centralized logs; you cannot debug a request across services without them.
• ✓Automated CI/CD per service, so a new service is not a manual deploy.
• ✓A test suite you trust on the monolith, so you can tell whether an extraction broke something.
• ✓A clear read on your domain boundaries; if you cannot name your bounded contexts, you are not ready.

The strangler fig pattern

Instead of a big-bang rewrite, you route traffic through a facade and gradually redirect slices of it from the monolith to new services. The monolith keeps running and stays the fallback. Over time it shrinks until what is left is either retired or is itself just another service.

        client
          |
      [ gateway / facade ]
        /            \
  monolith        new service
  (shrinking)     (growing, one context at a time)

Find the boundaries with DDD

The hardest part is not the code, it is choosing where to cut. Use Domain-Driven Design to identify bounded contexts, and an event storming session with the people who know the domain to surface them. Extract the least-coupled context first: it teaches you the mechanics with the lowest risk.

• ✓Map the domain: aggregates, bounded contexts, and the events that cross between them.
• ✓Spot the pain: which modules always deploy together, which slow each other down, which one team is blocked on.
• ✓Decide data ownership: each service owns its data, and no other service reads its tables directly.
• ✓Write the API and event contracts before a line of service code.

Practical steps with Laravel

Extract the module inside the monolith first (its own namespace, an interface at the boundary), put an anti-corruption layer in front of it so the rest of the monolith talks to an interface, then move the implementation behind HTTP or events, and cut over with a flag.

// Before: direct coupling inside the monolith
class OrderController extends Controller {
    public function store(Request $request, UserService $users) {
        $user = $users->find($request->user_id);
        // ...
    }
}

// After: the boundary is an interface; the implementation calls the service
interface UserDirectory {
    public function find(int $id): ?UserData;
}

class HttpUserDirectory implements UserDirectory {
    public function find(int $id): ?UserData {
        $data = Http::get(config('services.users.url') . "/users/{$id}")->json();
        return $data ? UserData::fromArray($data) : null;
    }
}

The hard part: the data

Splitting the code is straightforward; splitting the database is where migrations stall. Do it in stages: first give each context its own schema inside the shared database and stop cross-schema joins, then move the new service to its own database. During the transition, keep the two in sync with an outbox table or change data capture rather than dual writes from application code, which are hard to make reliable.

Communication: synchronous or asynchronous

Use synchronous HTTP or gRPC only when the caller needs an immediate answer: authentication, a payment authorization. Use asynchronous events (RabbitMQ, Kafka) for everything that can happen eventually: notifications, audit logs, analytics, and cross-service updates. A chain of synchronous calls where A waits on B waits on C compounds latency and failure at every hop.

The failure mode: a distributed monolith

If you cannot deploy one service without redeploying others, or a bug in one takes down features that should be unrelated, you have microservices in name and a monolith in practice, now with network calls in the middle. The usual causes are a shared database and synchronous call chains. Both are worth stopping and fixing before extracting the next service.

A microservices migration is a journey measured in months. Pace yourself, measure the outcome of each extraction against the reason you started, and do not hesitate to pause and consolidate before the next one.