📖 Overview

Sam Newman is one of the most respected voices in the microservices world. He is a consultant at ThoughtWorks, a former technical lead at a UK government digital service, and the author of Building Microservices (2015), the book that helped a generation of architects decide what to build. Monolith to Microservices (2019) is its necessary sequel.

If Building Microservices answers the question "how do I build a system of small, autonomous services?", this book answers the harder one: "how do I get there from here?" Most organizations do not have the luxury of greenfield design. They have a working monolith, a team that knows it, customers who depend on it, and an executive sponsor who has read about Netflix. The gap between that reality and the promised land of microservices is the entire subject of this book.

The book's signature move is honesty. Newman's first chapter is essentially a long argument that you should probably not do this. Most monoliths should stay monoliths. The cost of migration is enormous, the failure rate is high, and the success stories are survivorship-biased. He is explicit: do not migrate because microservices are fashionable. Migrate only when the cost of staying exceeds the cost of moving, and you have evidence of that cost.

Once that decision is made, the book delivers a pattern catalog. The Strangler Fig, parallel run, change data capture, event collaboration, event sourcing, branch by abstraction, UI composition, the anti-corruption layer. Each pattern is a tested technique for extracting one piece of a monolith at a time, running it in production, and removing the old code. Newman is careful to discuss the trade-offs of each, the conditions under which it applies, and the smells that indicate you are doing it wrong.

The deepest material is on the data layer. Shared databases are the single most common cause of failed migrations, and Newman devotes three chapters to alternatives: how to split a database, how to keep services in sync without distributed transactions, and how to use events as the integration contract. By the end, you understand why the data layer — not the service layer — is the hard part.

The final act addresses the human side. Conway's Law, team restructuring, the prerequisites for migration (CI/CD, observability, containerization, a deployment culture), and the anti-patterns that have destroyed real programs. Newman names them: the distributed monolith, microservice envy, the shared-database trap, the chatty service. He has watched these patterns take down real projects, and he writes with the calm authority of someone who has seen the wreckage.

---

🧠 Executive Summary

Newman organizes the migration problem into a decision framework, a pattern catalog, and a list of prerequisites and pitfalls.

| Pillar | Core Idea | |--------|-----------| | The Decision | Migration is justified only by clear, measured pain. Newman's bar: "if the monolith works, keep it." Evidence of cost must precede commitment. | | The Patterns | Strangler Fig, parallel run, change data capture, event collaboration, event sourcing, branch by abstraction, UI composition. Each is a tested technique for incremental extraction. | | The Data | The data layer is the hardest part. Shared databases, distributed transactions, and join-across-services are the dominant failure modes. Events and CDC are the dominant solutions. | | The People | Conway's Law is binding. Team structure and architecture structure co-evolve. Migration is impossible without CI/CD, observability, and a deployment culture. |

The book's contrarian backbone is simple: the most important pattern is the one you do not run. Most monoliths should not be migrated, and most migrations that are attempted fail.

---

🎯 Key Takeaways

• Do not migrate by default. Newman is explicit: the bar for migration is high, the failure rate is high, and the success stories are biased. Migration is justified only when the monolith demonstrably blocks the business.
• The Strangler Fig is the dominant pattern. You do not rewrite monoliths; you grow replacements around them, route traffic gradually, and retire the old code when nothing calls it.
• Decompose by capability, not by layer. A Customer service beats a Database service. Capability-aligned services are autonomous, independently deployable, and survive organizational change.
• Find the seams first. Bounded contexts from Domain-Driven Design are the canonical way to identify where the cuts should be. Newman devotes an entire chapter to techniques for finding them.
• The data layer is where migrations die. Shared databases, distributed transactions, and join-across-services are the most common failure modes. CDC, event collaboration, and event sourcing are the canonical fixes.
• Migrate in waves. Each wave extracts one service, runs both implementations in parallel, verifies behaviour, and only then retires the old code.
• UI composition is often skipped and always regretted. If your front end is a monolith calling microservices, you have moved the problem, not solved it.
• Prerequisites are not optional. CI/CD, observability, containerization, feature flags, and a deployment culture must exist before microservice migration is viable. Building them is part of the work.
• Conway's Law is binding. Team structure determines architecture. Migration requires team restructuring; restructuring enables migration. The two cannot be sequenced.
• Anti-patterns are explicit and named. Distributed monolith, microservice envy, the shared-database trap, chatty services, time-dependent coupling. Newman names each and tells you how to recognize it.

---

👥 Who Should Read

| Read this | Skip this | |-----------|-----------| | Architects and senior engineers about to undertake a migration | Greenfield engineers with no monolith to migrate from | | Tech leads executing or sponsoring an existing migration | Anyone looking for a microservices primer (read Building Microservices first) | | Engineering directors whose team structure is blocking the migration | Pure infrastructure engineers — the book is architecture, not Kubernetes | | Platform engineers building the tooling the migration depends on | Readers wanting distributed systems theory (Newman writes for practitioners) | | Consultants advising on modernization programs | Anyone allergic to the word "should" — Newman is opinionated on purpose |

---

🚫 Who Should Skip

If you are at a greenfield startup with no legacy system, this book is not for you. It assumes you have a working monolith, an existing team, real customers, and a real migration to plan. The content on prerequisites, organizational change, and incremental delivery will feel abstract without that context. Newman's Building Microservices is the right starting point; come back to this one when you inherit your first monolith.

Some readers also find Newman's prose too cautious. He is explicit that he would prefer most readers to walk away and not migrate. The result is a book that sometimes reads like a long argument against the project you are about to undertake. That is the point — but it can be disorienting for executives who have already decided.

---

📊 Core Themes

The Cost of Migration: Newman's foundational theme. He opens with the cost and returns to it throughout. Migration is expensive, slow, and risky. The bar for undertaking it must be evidence-based, not fashion-based. The first half of the book is essentially a long cost-benefit argument.

Incrementalism Over Rewrites: Big-bang rewrites fail. The Strangler Fig is the dominant pattern precisely because it is incremental: extract one service, run both, verify, retire. Newman never advocates a full rewrite, and the only successful migrations he describes are incremental ones.

The Primacy of the Data Layer: The most counter-intuitive theme for readers who came from Building Microservices. The data layer is the hard part. Service boundaries are negotiable; data ownership is not. Two services writing to the same table is not microservices — it is a distributed monolith, the worst of both worlds.

Conway's Law as Design Constraint: Newman's treatment of Conway is one of the most practical in the literature. The book argues that the team structure you have today determines the architecture you can have tomorrow. Migration and reorganization must proceed together; you cannot sequence them.

Prerequisites as Anti-Pattern Insurance: The book devotes a chapter to prerequisites that are not optional. CI/CD, observability, feature flags, central logging, distributed tracing, containerization, and a deployment culture. Newman argues that without these, microservice migration is doomed. Building them is part of the work, not a precondition that someone else will handle.

---

💡 Why This Book Matters

The microservices wave of the mid-2010s produced a generation of greenfield systems and a generation of failed rewrites. Organizations that had read about Netflix and Amazon rushed to decompose their working monoliths, often without understanding the cost. The result was a wave of "distributed monoliths" — systems that had all the complexity of microservices and none of the benefits, because the data layer was still shared and the team structure was still monolithic.

Newman wrote this book for that wreckage. It is the only mainstream guide that starts with the question "should you?" rather than "how do you?" The patterns are tested; the anti-patterns are named; the prerequisites are explicit. For any organization contemplating migration, this is the book that prevents the most common failure modes.

It also matters because of who wrote it. Newman is not a vendor, not an evangelist, not a consultant selling services. He is a practitioner who has watched these patterns succeed and fail in real organizations. The book's authority comes from that experience. When Newman says "do not migrate," he is not theorizing; he has watched migrations fail.

The core insight — that the hard part of microservices is the data layer, the team structure, and the prerequisites, not the services themselves — is genuinely useful. It is the kind of book that should be required reading for any executive sponsor of a migration program.

---

🔗 Related Books

| Book | How It Connects | |------|----------------| | Building Microservices by Sam Newman | The prequel — covers the what and why of microservices; this book covers the how of migration | | Microservices Patterns by Chris Richardson | Deeper pattern catalog, including sagas, CQRS, and API composition; complements Newman with more code | | Domain-Driven Design by Eric Evans | The canonical source for bounded contexts, which Newman uses to find seams | | Refactoring by Martin Fowler | The Strangler Fig and Branch by Abstraction patterns are Fowler's; Newman applies them to microservices | | Designing Data-Intensive Applications by Martin Kleppmann | The deeper theory behind event sourcing, CDC, and eventual consistency that Newman applies in migration | | Team Topologies by Matthew Skelton | The team-structure and platform-engineering material that Newman assumes; complementary | | Fundamentals of Software Architecture by Mark Richards | The architectural trade-offs (cost vs. agility, performance vs. resilience) that motivate migration decisions | | The Phoenix Project by Gene Kim | The DevOps prerequisite material — CI/CD, deployment culture, observability — that Newman assumes exists | | Accelerate by Nicole Forsgren | The research basis for why those prerequisites matter, drawn from the State of DevOps report |

---

⭐ Final Verdict

Rating: 9/10

Monolith to Microservices is the most useful book on the subject. Not because it is the deepest (Richardson's is deeper on patterns) or the most theoretical (Kleppmann's is more rigorous on data), but because it is the most honest. Newman tells you when not to migrate, names the failure modes, and gives you a pattern catalog that has been tested in real organizations.

The trade-off: The book is sometimes too cautious. Newman's contrarian opening is bracing, but by the end of the third chapter you may be exhausted by the hedging. The patterns are described in prose, not in code, so readers looking for implementation will need to go to Richardson or the open-source examples. The organizational material is sound but light; readers serious about team structure will need Team Topologies alongside.

Bottom line: If you are about to undertake a migration, this is the book that will save you from the most common mistakes. If you are advising someone who is, it is the book you should hand them. And if you are an executive sponsor reading about microservices for the first time, the first chapter alone is worth the price of admission — because it will probably convince you not to migrate, which is the most valuable advice the book offers.

The Decision: When to Migrate, When Not To

Newman opens with a contrarian argument that runs through the entire book: the default answer to "should we migrate to microservices?" is no.

Most monoliths should stay monoliths. The cost of migration is enormous — measured in years of engineering time, organizational disruption, and risk of failure. The success stories are survivorship-biased: you read about Netflix, Amazon, and Uber, and you do not read about the hundred organizations that tried the same transformation and gave up. Newman's bar for migration is high and explicitly evidence-based.

The triggers he considers legitimate:

• Independent deployability is blocked. A change to a single line in the codebase requires a full redeploy, a regression test of the entire system, and a maintenance window. Team velocity has collapsed.
• Scaling is per-function impossible. The catalog needs ten times more capacity than the checkout, but the monolith forces you to scale both together. You are paying for capacity you do not need.
• Reliability failures cascade. A bug in the recommendations feature takes down checkout. Shared deploys, shared databases, and shared failure domains mean one bad release is a system-wide outage.
• Technology choice is frozen. A new use case (machine learning inference, real-time analytics) requires infrastructure that the monolith cannot host. The team cannot experiment safely.
• Team autonomy is impossible. Multiple teams must coordinate every change. The bottleneck is communication, not code.

The triggers he considers illegitimate:

• "Microservices are the modern way to build." (Fashion, not evidence.)
• "Our monolith is ugly." (Refactoring does not require decomposition.)
• "We want to use Kubernetes." (Tool, not architecture.)
• "Our CTO read about Netflix." (Survivorship bias.)

The decision framework is deliberately weighted against migration. Newman argues that most teams who migrate would be better served by a well-structured monolith — a "modular monolith" with clear internal boundaries, ready for future extraction. The book spends more pages on the decision than on the patterns, because the patterns are useless if the decision is wrong.

flowchart TD
    Q["MONOLITH EXISTS<br/>Migration proposed"] --> P["Is the monolith<br/>actively blocking<br/>the business?"]
    P -->|No| STOP["DO NOT MIGRATE<br/>Refactor in place<br/>Modular monolith"]
    P -->|Yes| E["Is the pain<br/>measured, not<br/>theorized?"]
    E -->|No| MEASURE["Measure first.<br/>Velocity? Outage rate?<br/>Deploy frequency?"]
    E -->|Yes| R["Do prerequisites<br/>exist? CI/CD, observability,<br/>deployment culture?"]
    R -->|No| BUILD["Build prerequisites first.<br/>Migration is impossible<br/>without them."]
    R -->|Yes| C["Can you commit to<br/>incremental extraction<br/>over 1-3 years?"]
    C -->|No| STOP
    C -->|Yes| GO["Proceed. Strangler Fig.<br/>Wave by wave. Verify<br/>at every step."]

    style Q fill:#1a1a2e,color:#fff,stroke:#e94560
    style P fill:#16213e,color:#fff,stroke:#e94560
    style E fill:#16213e,color:#fff,stroke:#e94560
    style R fill:#16213e,color:#fff,stroke:#e94560
    style C fill:#16213e,color:#fff,stroke:#e94560
    style STOP fill:#8b0000,color:#fff,stroke:#e94560
    style MEASURE fill:#533483,color:#fff,stroke:#e94560
    style BUILD fill:#533483,color:#fff,stroke:#e94560
    style GO fill:#006400,color:#fff,stroke:#e94560

---

Finding Seams: Where to Cut

Once the decision to migrate is made, the next question is where to cut the monolith. Newman's answer is unambiguous: decompose by capability, not by layer. A Customer service beats a Database service. A Recommendation service beats a BusinessLogic service. The cuts should follow the natural boundaries of the business domain.

The technique for finding those boundaries comes from Domain-Driven Design (Eric Evans). Bounded contexts are the regions of the business model where a particular term has a single, consistent meaning. Customer in the billing context is not the same as Customer in the marketing context — they have different attributes, different lifecycles, different owners. A microservice is, in practice, a bounded context with its own data store and API.

Newman offers several techniques for finding the seams:

• Event storming. A workshop where domain experts and engineers map out the business events (Order Placed, Payment Received, Item Shipped) and aggregate them into bounded contexts. Surfaces hidden dependencies and shared concepts.
• Seam analysis in the codebase. Looking for modules that change together, modules that are deployed together, and modules that have a clear interface to the rest of the system. The natural seams are usually visible in the code.
• Team boundaries. Where the teams are already split, the service boundaries often already exist. This is the Reverse Conway move applied retroactively.
• Business capability mapping. The capabilities the business cares about (catalog, checkout, fulfillment, support) usually map cleanly to bounded contexts. Capabilities are more stable than features; they survive reorganizations.

The wrong way to find seams: by technical layer. A Service layer, a Repository layer, a Database layer — all of these cut horizontally through the business logic. They produce distributed monoliths (services that cannot be deployed independently, because they all need to change together), not microservices.

---

The Strangler Fig Pattern

The single most important pattern in the book, attributed to Martin Fowler. The Strangler Fig grows a new system around an old one, replacing functionality piece by piece until the old system can be retired.

flowchart LR
    subgraph Start["START: All traffic to monolith"]
        U["User"] --> M["MONOLITH<br/>All functionality"]
    end

    subgraph Middle["MIDDLE: Some routes redirected"]
        U --> R["Router / proxy"]
        R -->|"customer/*"| C["Customer service<br/>(new)"]
        R -->|"*"| M
    end

    subgraph End["END: Monolith retired"]
        U --> R2["Router"]
        R2 --> C2["Customer service"]
        R2 --> CAT["Catalog service"]
        R2 --> O["Order service"]
    end

The pattern in detail:

1. Place a routing layer in front of the monolith. A reverse proxy, an API gateway, or a DNS-level router. All traffic still goes to the monolith.
2. Identify the next capability to extract. Choose something with a clean interface, a clear bounded context, and minimal shared state. Newman's heuristic: start with the easiest, prove the pattern, then take on harder extractions.
3. Build the replacement service alongside the monolith. New code lives in the new service. Old code still runs in the monolith. Both implementations are reachable.
4. Run both in parallel (parallel run pattern). The router sends the same request to both; the responses are compared. Catches semantic differences that tests miss.
5. Switch traffic gradually. Canary first, then small percentage, then full cutover. The old implementation stays in the codebase (or in a disabled state) for rollback.
6. Delete the old code. Once the new service is in production and stable, remove the legacy implementation from the monolith. This step is often skipped and always regretted.
7. Repeat for the next capability. The Strangler Fig grows one service at a time, on a cadence the team can sustain.

The pattern is powerful because it makes migration reversible. Every step is independently shippable and independently reversible. If the new service fails in production, traffic routes back to the monolith. If the team loses momentum, the project pauses cleanly. Big-bang rewrites cannot offer this.

Newman is explicit that the Strangler Fig is not free. You run two systems in parallel, you maintain routing logic, and you tolerate temporary code duplication. The cost is worth paying for the safety.

---

The Data Layer: Where Migrations Die

Newman devotes three chapters to the data layer, and they are the deepest in the book. His central claim: the data layer is where microservice migrations fail. Service boundaries are negotiable; data ownership is not. Two services writing to the same table is not microservices — it is a distributed monolith, the worst of both worlds.

Why Shared Databases Are a Trap

When the monolith's database is shared across multiple extracted services, every service has a transitive dependency on every other. A schema change in one service ripples to all consumers. A migration blocks the entire system. The benefits of independent deployment evaporate.

The problem is invisible at first. It looks like clean service boundaries, with each service exposing a clean API. But under the hood, the services are coupled through the shared database — a coupling that does not appear in any API documentation and does not show up in service-level tests. It shows up only at migration time, when you try to change the schema and discover that three services depend on the same table.

The fix is to give each service its own data store. But "give each service its own database" is easy to say and hard to do. The challenges:

• Schema migration is irreversible. Once two services depend on the same column, splitting them requires coordinated changes in both.
• Cross-service queries are needed. Reports, analytics, and admin tools still need data from multiple services. The shared database was a convenient way to express those queries.
• Transactional consistency is needed. Orders and payments must be updated atomically. The shared database was a convenient way to express that atomicity.
• Legacy code is everywhere. The monolith's data layer is usually a dense thicket of stored procedures, triggers, and ORM models. Untangling it is months of work.

Newman walks through the patterns for solving each of these.

Pattern 1: Change Data Capture (CDC)

CDC treats the monolith's database as the source of truth and publishes its changes as events. A new service subscribes to the events it cares about and maintains its own read model. The monolith is unaware of the new service; the new service does not need to know the monolith's schema in detail.

flowchart LR
    M["MONOLITH<br/>Writes to DB"] --> DB["Shared<br/>database"]
    DB -->|"transaction log"| CDC["CDC process<br/>(Debezium, etc.)"]
    CDC -->|"OrderPlaced<br/>events"| BUS["Event bus<br/>(Kafka)"]
    BUS --> S1["Customer service<br/>consumes events"]
    BUS --> S2["Notification service<br/>consumes events"]
    BUS --> S3["Analytics service<br/>consumes events"]

Tools like Debezium read the database's transaction log (e.g., PostgreSQL's WAL) and emit change events. The new service treats these events as its data feed. This is how you extract a service from a monolith without the monolith's cooperation.

Pattern 2: Event Collaboration

Instead of a service calling another service synchronously, it publishes an event. Other services that care about the event subscribe and react. The interaction is asynchronous, the coupling is loose, and the failure modes are different from synchronous calls.

sequenceDiagram
    participant O as Order Service
    participant BUS as Event Bus
    participant P as Payment Service
    participant N as Notification Service

    O->>BUS: OrderPlaced {orderId, amount, customerId}
    BUS-->>P: deliver event
    BUS-->>N: deliver event
    P->>P: Process payment
    P->>BUS: PaymentProcessed
    N->>N: Send confirmation email

The trade-off: you give up strong consistency. The order is placed, but the payment may take seconds to process. The notification may arrive before or after the payment. This is eventual consistency, and it requires the business to be designed for it.

Newman is explicit: this is the dominant pattern for inter-service communication in a microservice system. Synchronous calls (Service A calls Service B over HTTP) are a smell; events are the default.

Pattern 3: Event Sourcing

Instead of storing the current state, store the sequence of events that led to it. State is a derived view, recomputable by replaying the events. This gives you a complete audit trail, time-travel debugging, and natural fit for event collaboration.

The trade-off: event sourcing is hard. Querying becomes more complex (you need materialized views to answer simple questions). Schema evolution on the event log is delicate. Newman recommends it only when the use case explicitly benefits (financial systems, audit-heavy domains).

Pattern 4: Branch by Abstraction

A technique for changing behaviour behind a stable interface. You create an abstraction layer (a wrapper, an interface, a gateway) that the monolith uses. You implement the new behaviour inside the abstraction. You switch implementations atomically. You delete the old implementation.

This is the technique for incremental database migration. You wrap the table access in a repository, implement the new repository against a new schema, switch over, and drop the old schema. Newman uses this pattern to extract a single table at a time from a shared database.

---

UI Composition

A chapter that is often skipped and always regretted. The front end is rarely part of the migration conversation, but it is usually a monolith too. If your back end is microservices and your front end is a single page that calls all of them, you have moved the monolith up a layer.

UI composition is the pattern: the front end itself is decomposed into components, each owned by a different team, each able to be deployed independently. A page might assemble itself from multiple UI fragments, each fetched from its own service.

flowchart TB
    subgraph Frontend["FRONTEND"]
        P["Page shell<br/>(shell service)"]
        P --> F1["Profile fragment<br/>(Profile service)"]
        P --> F2["Recommendations fragment<br/>(Catalog service)"]
        P --> F3["Cart fragment<br/>(Cart service)"]
    end

Techniques include micro-frontends (each team owns a self-contained bundle of UI), server-side composition (the page is assembled by an aggregator, not the browser), and edge-side includes (fragments are cached and stitched at the CDN). Newman is pragmatic — the right answer depends on the team structure, the deployment cadence, and the user experience requirements.

The key warning: do not let the back end become microservices and the front end remain a monolith. The communication bottleneck moves to the front end. The deployment coupling moves to the front end. The shared failure modes move to the front end. You have not fixed the problem; you have relocated it.

---

Organizational Change and Conway's Law

The book's final movement is on people. Newman is explicit: Conway's Law is binding. The architecture of a system mirrors the communication structure of the organization that built it. If your team structure is monolithic, your architecture will be monolithic, no matter how many services you extract.

The implication is bidirectional. If you want a microservice architecture, you must have a team structure that supports it — small, autonomous, long-lived teams each owning a service. The Reverse Conway move: restructure the teams first, and the architecture will follow.

Newman's prerequisites for a successful migration:

• CI/CD. Every service must be independently deployable. If a deploy takes a week of manual coordination, you cannot extract services.
• Observability. Centralized logging, distributed tracing, metrics. If you cannot see what is happening across services, you cannot operate them.
• Containerization. Lightweight, reproducible deployment. Kubernetes or equivalent. Not strictly required, but the de facto baseline.
• Feature flags. The ability to switch behaviour in production without a deploy. Essential for canary releases and gradual cutover.
• A deployment culture. Teams that are comfortable deploying, monitoring, and rolling back their own services. Without this, no amount of tooling will save you.

If you do not have these, Newman argues, the migration is doomed. The patterns assume a mature platform; the alternatives (manual deploys, shared logs, on-call chaos) make the patterns impossible to execute safely.

---

Anti-Patterns

Newman names the failure modes he has seen. The list is the book at its most practical — these are the traps to avoid.

• Distributed Monolith. Services that cannot be deployed independently. A schema change in one requires coordinated changes in all. The worst of both worlds: distributed complexity with monolithic coupling.
• Microservice Envy. Decomposing too small, too early. A "service" with one function and one endpoint. Operational overhead exceeds the benefit.
• The Shared Database Trap. Two services writing to the same table. See above. The most common cause of failure.
• Chatty Services. Services that call each other in tight loops, with no batching, no caching, no aggregation. Network latency dominates. The architecture is correct; the implementation is hostile.
• Time-Dependent Coupling. Services that depend on a shared clock or a shared cron schedule. A "deploy at midnight" service is coupled to every other service's midnight behaviour.
• Front-End Bottleneck. A monolithic front end calling microservices. The problem has been moved, not solved.
• Stateless Hype. Believing services must be stateless at all costs. Stateful services are fine, if state is owned and managed deliberately.
• Premature Decomposition. Extracting services before the bounded context is stable. The seam moves; the service has to be rewritten. Newman's advice: extract later than you think, not earlier.

---

Frameworks

graph TD
    DEC["THE DECISION"] --> P1["Is the monolith blocking<br/>measurable business outcomes?"]
    P1 -->|No| STOP["DO NOT MIGRATE<br/>Refactor in place"]
    P1 -->|Yes| PREREQ["PREREQUISITES<br/>CI/CD, observability,<br/>deploy culture"]

    PREREQ --> SEAMS["FIND SEAMS<br/>Bounded contexts,<br/>event storming,<br/>team boundaries"]
    SEAMS --> STRAT["CHOOSE STRATEGY<br/>Strangler Fig,<br/>branch by abstraction"]
    STRAT --> EXTRACT["EXTRACT IN WAVES<br/>Parallel run,<br/>canary, gradual cutover"]

    subgraph DATA["DATA LAYER (the hard part)"]
        EXTRACT --> D1["Stop sharing databases"]
        D1 --> D2["Use CDC for sync"]
        D1 --> D3["Use events for collaboration"]
        D1 --> D4["Use event sourcing<br/>when audit is critical"]
    end

    EXTRACT --> UI["UI COMPOSITION<br/>Don't relocate the<br/>monolith to the front end"]
    UI --> ORG["RESTRUCTURE TEAMS<br/>Conway's Law is binding.<br/>Reverse Conway works."]

    AP["ANTI-PATTERNS"] -.->|warns against| EXTRACT
    AP -.->|warns against| DATA
    AP -.->|warns against| UI

    style DEC fill:#1a1a2e,color:#fff,stroke:#e94560
    style PREREQ fill:#16213e,color:#fff,stroke:#e94560
    style SEAMS fill:#16213e,color:#fff,stroke:#e94560
    style STRAT fill:#16213e,color:#fff,stroke:#e94560
    style EXTRACT fill:#0f3460,color:#fff,stroke:#e94560
    style DATA fill:#533483,color:#fff,stroke:#e94560
    style UI fill:#16213e,color:#fff,stroke:#e94560
    style ORG fill:#006400,color:#fff,stroke:#e94560
    style AP fill:#8b0000,color:#fff,stroke:#e94560
    style STOP fill:#8b0000,color:#fff,stroke:#e94560

---

Mental Models

| Model | Application | |-------|-------------| | Strangler Fig | Migration is growth, not replacement. New system grows around old; old is retired when nothing calls it. | | Bounded Context | A region of the business where a term has one meaning. The natural unit of decomposition. | | Anti-Corruption Layer | A translation layer between the monolith and the new service. Prevents legacy concepts from leaking into the new system. | | Parallel Run | Both old and new implementations process the same traffic; responses are compared. Catches semantic differences. | | Conway's Law | Architecture mirrors organization. To change architecture, change the teams first. | | Reverse Conway Maneuver | Restructure the team intentionally, and the architecture will follow. | | Distributed Monolith | The anti-pattern: services that cannot be deployed independently. Worst of both worlds. | | Premature Decomposition | Extracting services before the bounded context is stable. The seam moves; the service is rewritten. | | CDC | The monolith's transaction log is the source of truth. New services subscribe to change events. | | Eventual Consistency | The default for inter-service communication. The business must be designed for it. |

---

Key Lessons

1. The default is no migration. Newman's most important lesson. Most monoliths should stay. The cost is high, the failure rate is high, the success stories are survivorship-biased.
2. The Strangler Fig is the only safe pattern. Big-bang rewrites fail. Incremental extraction is reversible at every step.
3. Decompose by capability. A Customer service beats a Database service. Capability-aligned services are autonomous and durable.
4. The data layer is the hard part. Service boundaries are negotiable; data ownership is not. CDC, events, and event sourcing are the patterns that make data-layer migration possible.
5. Shared databases are a trap. Two services writing to one table is a distributed monolith. The single most common cause of failure.
6. UI composition is part of the migration. A monolithic front end calling microservices is not microservices. The problem has been moved, not solved.
7. Migrate in waves. Each wave extracts one service, verifies it, and retires the old code. Skip the verification step at your peril.
8. Conway's Law is binding. Migration and team restructuring must proceed together. Sequencing is impossible.
9. Prerequisites are not optional. CI/CD, observability, containerization, feature flags, and a deployment culture. Without these, the patterns cannot be executed safely.
10. Anti-patterns are predictable. Distributed monolith, microservice envy, chatty services. Newman has watched each destroy real projects.

---

Practical Applications

Auditing a proposed migration: Before committing, run Newman's decision test. Is the monolith blocking measurable business outcomes (deploy frequency, lead time, MTTR, change failure rate)? If not, the migration is not justified. If yes, are the prerequisites in place? If not, building them is the first wave.

Finding the first extraction: Use event storming. Invite domain experts and engineers. Map the business events. Cluster them into bounded contexts. The context with the cleanest interface and the most stable model is the first extraction.

Splitting a shared database: Start with a single table. Wrap its access in a repository (branch by abstraction). Implement the new repository against a new schema. Run both in parallel. Compare results. Switch the read path first, then the write path. Drop the old table. Repeat for the next table.

Building a new service alongside the monolith: Place a routing layer (API gateway, reverse proxy) in front of the monolith. Build the new service. Route a small percentage of traffic to the new service. Use feature flags to control the cutover. Compare metrics. Increase the percentage. Retire the old path.

Reorganizing the team for migration: Identify the bounded contexts. Assign a long-lived team to each. Move the relevant code, the relevant database tables, and the relevant on-call rotation to the new team. Give them a deployment pipeline and a clear interface to the rest of the system. The architecture will follow.

Detecting anti-patterns early: Watch for these signals. Two services writing to the same table. Synchronous chains of calls deeper than two. A single front end calling all services. A shared schema change that requires coordinated deploys. Any of these means the migration has stalled or failed; revert the relevant changes.

---

Examples

The E-Commerce Migration (composite): A retailer with a 10-year-old PHP monolith serving 50,000 orders/day. Newman's prescription: extract the Recommendations capability first (clean bounded context, read-mostly, low risk). Use CDC to populate a new Recommendations service from the monolith's order events. Run in parallel for a month. Cut over. Move to Inventory, then Checkout. Avoid the temptation to extract Customer first — it touches everything.

The Shared-Database Disaster (cautionary): A financial services company extracted 12 services from a Java monolith, but kept the shared Oracle database. Two years later, a schema change in the Account table required coordinated deploys of all 12 services. The migration had not improved deploy frequency; it had only added network calls. The fix: a multi-year data-layer migration, one table at a time, using branch by abstraction.

The Front-End Bottleneck (common): A media company decomposed its back end into 30 services, but kept its Ruby on Rails front end as a single page calling all of them. Every deploy of any service required a front-end deploy. Every front-end deploy required regression tests of all 30 services. The "microservices" had improved nothing; the bottleneck had simply moved. The fix: UI composition, with each team owning its own front-end bundle.

The Premature Decomposition (cautionary): A startup decomposed its 6-month-old monolith into 15 services because microservices were fashionable. Each service was a thin wrapper around a few database tables. The operational overhead (15 deploy pipelines, 15 sets of metrics, 15 on-call rotations) exceeded the engineering capacity. Two years later, the company was consolidating back into a modular monolith.

The Conway Fix (positive): A bank restructured its IT teams around bounded contexts (retail, commercial, treasury, risk) and let the architecture follow. The monolith persisted, but the team structure enabled future extraction. Five years later, the bank is migrating, but the migration is feasible because the teams are already aligned.

---

Action Plan

1. Run Newman's decision test. Is the monolith blocking measurable business outcomes? If not, do not migrate. Refactor in place.
2. Inventory the prerequisites. Do you have CI/CD, central logging, distributed tracing, feature flags, and a deployment culture? If not, build them. They are the first wave.
3. Find the seams. Use event storming, bounded-context analysis, or team-boundary analysis. Pick the cleanest, most stable bounded context as your first extraction.
4. Place a routing layer in front of the monolith. API gateway or reverse proxy. All traffic still goes to the monolith.
5. Build the new service alongside. New code in the new service. Old code stays. Both implementations are reachable.
6. Run both in parallel. Send the same traffic to both. Compare responses. Catch semantic differences.
7. Switch traffic gradually. Canary, 1%, 10%, 50%, 100%. Roll back at the first sign of trouble.
8. Delete the old code. This step is often skipped and always regretted. The Strangler Fig only works if the old system is actually strangled.
9. Reorganize the team. Each bounded context gets a long-lived team. Move code, data, and on-call rotation to the new team. Conway's Law will do the rest.
10. Watch for anti-patterns. Shared databases, chatty services, front-end bottlenecks, premature decomposition. Catch them early. Revert when you see them.

Strengths

• Honest about when not to migrate. The book's most distinctive quality. Newman spends the first third telling you why you should probably not do the project you are about to undertake. No other mainstream book on microservices opens this way. It is genuinely useful, and it spares readers the most common failure mode (migrating because microservices are fashionable).
• The Strangler Fig is treated with the depth it deserves. Most books mention the Strangler Fig in a paragraph. Newman devotes a full chapter, walks through the routing layer, the parallel-run pattern, the gradual cutover, and the rollback. The treatment is operational, not aspirational.
• The data-layer material is the deepest in print. Three chapters on shared databases, CDC, event collaboration, event sourcing, and branch by abstraction. Other books cover these patterns briefly; Newman covers them with the depth required to actually execute them. The CDC material alone is worth the price of admission.
• Capability-aligned decomposition is a clear, correct thesis. "Decompose by capability, not by layer" is the most actionable sentence in the book. It is the kind of advice that prevents months of wasted work, and it is stated cleanly.
• Anti-patterns are explicit and named. Distributed monolith, microservice envy, chatty services, front-end bottleneck, premature decomposition. Newman names each, gives a recognizable example, and tells you how to detect it. This is the kind of catalog you wish you had three projects ago.
• Prerequisites are made non-negotiable. CI/CD, observability, containerization, feature flags, deployment culture. Newman's insistence that these must exist before migration begins is correct, and it is rare in the literature.
• The Conway's Law treatment is practical, not theoretical. Newman is not interested in the history of the law. He is interested in what it means for your migration. The Reverse Conway move — restructure the team first, and the architecture will follow — is the most actionable advice in the organizational chapter.

---

Weaknesses

• Cautious to a fault. Newman's contrarian stance, while correct, can be exhausting. By the third chapter of "do not migrate," readers who have already committed to the project are fatigued. The book could be 20% shorter without losing substance.
• Patterns are described in prose, not code. Readers looking for implementation will need to go elsewhere. Richardson's Microservices Patterns or the open-source examples on Newman's GitHub are the right complement. The book tells you what to do, not exactly how to type it.
• Limited coverage of specific technologies. No Kubernetes tutorial, no Istio deep dive, no service mesh comparisons. The book is architecture, not infrastructure. Readers who confuse the two will be disappointed.
• The organizational material is sound but light. Conway's Law is covered well, but team structure, communication patterns, and platform engineering are touched only briefly. Team Topologies by Skelton and Pais is the right complement.
• Few concrete case studies with metrics. Newman references real projects but does not present them in depth. The book would be stronger with 2-3 end-to-end case studies showing the wave-by-wave journey of an actual migration.
• Some readers will miss a chapter on "the modular monolith" as an alternative. Newman mentions it in passing but does not treat it as a first-class option. For many organizations, a well-structured monolith is the right answer, and the book could have devoted more space to that path.

---

Criticism

Survivorship Bias in Newman's Skepticism

Newman's contrarian opening is correct, but it is also a form of survivorship bias. The success stories he implicitly cites (Netflix, Amazon, Uber) are real, but so are the failures he is implicitly trying to protect readers from. The book's stance is: assume the worst, and the reader will either back out of a bad project or be prepared for a hard one. But this underweights the cases where the monolith genuinely is blocking the business and a successful migration is the right answer.

The result is a book that sometimes reads like an extended argument against the project the reader has been sent to plan. Some readers will find this refreshing; others will find it disorienting, especially executives who have already made the decision and need a playbook rather than a reconsideration.

The Patterns Are Tested but Not Quantified

Newman presents the patterns as battle-tested, but he rarely quantifies the outcomes. How long does a typical Strangler Fig migration take? How many services are typically extracted per quarter? What is the failure rate of the parallel-run pattern in practice? The book is honest about qualitative trade-offs but quiet on quantitative outcomes.

A reader planning a migration would benefit from base rates. Newman's omission is probably an honesty about the variability of outcomes (every migration is different), but it leaves the reader with less to plan against.

Conway's Law Is Stated as a Constraint, Not a Choice

Newman treats Conway's Law as a binding constraint: your team structure determines your architecture. But this is a description, not a prescription. Some organizations have explicitly chosen to break Conway's Law by hiring dedicated platform teams, embedding engineers across product teams, or adopting a "you build it, you run it" model. Newman does not engage with these alternatives.

The book would be stronger with a more nuanced treatment: Conway's Law is a strong default, but it can be bent with deliberate organizational design. The Reverse Conway Maneuver is one example; embedded engineers, platform teams, and federated governance are others.

The Book Is Architecture-First, Engineering-Second

Newman's framing is heavily architectural. The patterns are about how to decompose a system. The engineering material — how to write the code, how to design the APIs, how to handle serialization, how to test the services in isolation — is thinner. Readers who have already bought in to the architecture may find the engineering guidance wanting.

Richardson's Microservices Patterns is the right complement here. Where Newman is the strategist, Richardson is the engineer. Together they form a complete picture; alone, each is incomplete.

---

Counterarguments

| Criticism | Response | |-----------|----------| | "Too cautious — the reader has already decided" | Newman is explicit that the book's job is to make the reader reconsider. The first chapter is a deliberate checkpoint. Readers who proceed have earned their decision. | | "Patterns are described in prose, not code" | That is a deliberate choice. The book is architecture, not implementation. Code would date quickly; patterns do not. | | "Conway's Law is oversimplified" | Newman acknowledges the simplification. The point is that the team structure is a strong constraint, not the only one. The book is not the last word on organizational design. | | "Few case studies with metrics" | Newman has spoken publicly about his wariness of case studies that are not his own to tell. The book privileges patterns over anecdotes on purpose. | | "Limited technology coverage" | Tools change. Patterns do not. Newman made the right call to keep the book technology-agnostic. |

---

Patterns Referenced

| Pattern | Source | Role in the Book | |---------|--------|------------------| | Strangler Fig | Martin Fowler (2004) | The dominant migration pattern; replace functionality incrementally | | Branch by Abstraction | Jez Humble | Change behaviour behind a stable interface; the technique for database migration | | Parallel Run | Reliability engineering | Run old and new implementations side by side; compare responses | | Change Data Capture | Debezium / similar tools | Read the monolith's transaction log; publish events to new services | | Event Collaboration | Domain-Driven Design | Services publish events; others react; the default for inter-service communication | | Event Sourcing | Greg Young / Fowler | State derived from a log of events; complete audit trail; natural fit for events | | Anti-Corruption Layer | Eric Evans | Translation between the monolith and the new service; prevents legacy concepts from leaking | | UI Composition | Micro-frontends literature | Decompose the front end as well; do not relocate the monolith | | Bounded Context | Eric Evans | The natural unit of decomposition; the seam to find | | Conway's Law | Melvin Conway (1968) | Architecture mirrors organization; binding constraint on migration | | Reverse Conway Maneuver | Various | Restructure the team first, and the architecture will follow |

---

Historical Context

Monolith to Microservices was published in October 2019, near the end of the first decade of mainstream microservices adoption. The book arrived in a moment of consolidation. The 2014-2017 wave had produced a generation of microservice systems and a generation of failed rewrites. Organizations were beginning to admit that the cost of microservices was higher than the evangelists had claimed, and that the dominant failure mode was the distributed monolith.

The book reflects that reckoning. It is more cautious than Building Microservices (2015), more explicit about prerequisites, and more willing to say "do not migrate." The Strangler Fig, which was a niche technique in 2014, is treated as the default in 2019. The anti-patterns, which were unspoken in 2015, are named and described in 2019.

The broader context: the late 2010s saw the rise of Kubernetes, service meshes (Istio, Linkerd), and the cloud-native ecosystem. Newman's book is deliberately technology-agnostic; he does not mention Kubernetes by name. This is a feature, not a bug — the patterns survive changes in tooling, and the book reads cleanly even as the ecosystem shifts.

The book's most underappreciated contribution is its insistence on the data layer. In 2019, the microservice discourse was still heavily focused on service boundaries and API design. Newman is one of the first mainstream authors to argue that the data layer is the hard part. This framing has since become standard, but the book was ahead of the curve.

The cultural moment: a backlash against "microservice envy" and a renewed interest in the modular monolith. Newman's argument that most organizations would be better served by a well-structured monolith is part of this backlash, and the book has aged well in the years since. Many of the projects that started microservice migrations in 2017-2018 are consolidating in 2024-2025, and Newman's patterns are the playbook for that consolidation.

---

Similar Books

| Book | Author | How It Compares | |------|--------|-----------------| | Building Microservices | Sam Newman | The prequel — covers the what and why of microservices; this book covers the how of migration | | Microservices Patterns | Chris Richardson | Deeper pattern catalog with code; complementary to Newman's architecture-first treatment | | Domain-Driven Design | Eric Evans | The source of bounded contexts, anti-corruption layers, and event collaboration | | Refactoring | Martin Fowler | The source of the Strangler Fig and Branch by Abstraction patterns | | Designing Data-Intensive Applications | Martin Kleppmann | The deeper theory behind CDC, event sourcing, and eventual consistency | | Team Topologies | Matthew Skelton | The team-structure material that Newman assumes; complementary on organizational design | | Fundamentals of Software Architecture | Mark Richards | The trade-off analysis (cost vs. agility) that motivates migration decisions | | The Phoenix Project | Gene Kim | The DevOps prerequisite material — CI/CD, deployment culture, observability | | Accelerate | Nicole Forsgren | The research basis for why those prerequisites matter | | Software Architecture: The Hard Parts | Neal Ford | A trade-off analysis approach to decomposition; complementary to Newman's pattern catalog | | Building Evolutionary Architectures | Neal Ford | The broader principle of building systems that can change over time |

---

Long-Term Relevance

High. The patterns in this book are tested, named, and tool-agnostic. They will remain valid as long as organizations have monoliths to migrate from and services to migrate to. The Strangler Fig, branch by abstraction, CDC, and event collaboration are not trendy ideas; they are fundamental techniques.

However, three shifts are worth noting:

1. The modular monolith has gained legitimacy. In 2019, the modular monolith was a footnote. In 2026, it is a serious alternative for many organizations. Newman's "do not migrate" advice has aged into a stronger claim: "consider the modular monolith first." A future edition might devote a full chapter to this path.
2. AI-assisted migration is changing the work. Tools like GitHub Copilot and large language models are accelerating the mechanical parts of migration (writing the new service, generating the CDC code, drafting the API tests). The architecture decisions are still human; the implementation is increasingly automated. Newman's book is about the decisions, so it remains relevant — but the engineering effort per migration has dropped significantly.
3. The team-structure argument is now mainstream. The 2019 claim that "Conway's Law is binding" was ahead of the curve. By 2026, team structure and architecture are universally treated as co-evolving. Newman's contribution to this consensus is one of his lasting legacies.

The book's main vulnerability: it does not address the modular monolith as a first-class option. A 2026-updated edition might add a chapter on when to stop at the modular monolith and when to push through to microservices. The patterns remain the same; the decision criteria might be updated.

---

Final Assessment

| Dimension | Rating | Notes | |-----------|--------|-------| | Argument Quality | 9/10 | Newman's contrarian stance is well-supported and genuinely useful | | Practical Utility | 9/10 | The patterns are operational, not aspirational; the prerequisites are explicit | | Originality | 8/10 | The synthesis is Newman's own; the individual patterns are from Fowler, Evans, Humble | | Readability | 8/10 | Clear, well-structured prose; the caution is wearying at times | | Technical Depth | 7/10 | Architecture-first, not code-first; readers wanting implementation will need Richardson | | Organizational Insight | 8/10 | Conway's Law treatment is the best in the mainstream microservices literature | | Overall | 9/10 | The most useful book on the subject; the contrarian opening alone is worth the price |

Monolith to Microservices succeeds because it answers the question other books skip. Most microservice books assume the reader has decided to migrate. Newman starts with the decision. Most books describe the service layer; Newman devotes three chapters to the data layer. Most books mention the Strangler Fig in a paragraph; Newman walks through the full migration lifecycle. The result is a book that is genuinely useful to practitioners, not just to architects.

The book is not perfect. It is sometimes too cautious, and it could be 20% shorter. It is light on code, light on case studies, and light on organizational design beyond Conway's Law. Readers looking for implementation will need Richardson; readers looking for team structure will need Skelton and Pais.

But for the central question — how do you migrate a monolith to microservices without destroying the business? — this is the definitive book. Newman has watched the patterns succeed and fail in real organizations. The book is the catalog of what he learned, and it is the only mainstream guide that is honest enough to say "do not migrate" when that is the right answer.