When picking the first capability to peel off a monolith with a strangler-fig migration, what makes a good 'seam,' and what characteristics of a module make it a poor first choice?

## What a seam is A seam, in **Michael Feathers'** original usage from legacy-code work, is a place in a system where you can alter behavior without editing the code at that exact point — a joint along which the system can be safely pulled apart. Applied to monolith decomposition, a good seam is a module boundary with **low coupling** to the rest of the system and **high internal cohesion**, such that extracting it into a separate service touches as little of the surrounding codebase and data model as possible. Finding good seams is arguably as important a skill in a strangler-fig migration as executing the extraction itself, because a wrong choice can turn what should be a confidence-building early win into the migration's first and most damaging failure. ## Two sources of signal Concretely, useful signals for identifying seams come from two sources: the code and the data. - **On the code side**, teams look at dependency/call-graph analysis (how many other modules call into this one, and how many does it call out to — low fan-in and fan-out is favorable), and at git co-change or churn analysis (which files tend to be edited together in the same commits; files that rarely co-change with the rest of the system are more independent than the call graph alone might suggest). - **On the data side** — often the more decisive factor — teams look at which database tables a candidate module reads and writes, and whether those tables are exclusive to it or shared with other, unrelated features; a module that owns its own tables outright is a far better seam than one that looks structurally isolated in code but reaches into a dozen tables other features also depend on. Domain-driven design's **bounded-context mapping** is frequently used as a complementary technique: talking through the domain with subject-matter experts to find natural conceptual boundaries often lines up with, and helps validate, what the coupling analysis finds mechanically. ## Why the first choice carries so much weight The reason this matters so much is that strangler-fig migrations are typically sequenced from easier to harder, and the first extraction sets the tone. It's where the team builds and proves: - its routing infrastructure; - its rollback procedures; - its data-migration tooling; - and its confidence with stakeholders that the whole multi-year effort is worth funding. A poorly chosen first seam — one with hidden coupling that only becomes apparent mid-extraction — can turn a planned two-week project into a stalled six-month one, souring organizational appetite for the rest of the migration. Good candidates therefore combine technical isolation with modest, not necessarily maximal, business value: valuable enough that finishing it matters, but not so central or so risk-sensitive (core billing, core auth) that a mistake is catastrophic before the team's tooling is proven. ## What a poor seam looks like Poor seams share recognizable characteristics: - they sit at the center of the dependency graph with high fan-in from many other modules, so almost everything depends on their current in-process behavior and must be touched or at least tested against the new remote version; - they share tables with several unrelated features, so no clean data boundary exists without either giving the new service broad cross-schema database access (defeating the purpose of the split) or building many new data integrations at once; - or they participate in synchronous, chatty interaction patterns that would become slow, unreliable network calls immediately, a classic sign that the module is not actually a separate bounded context but an artificial slice of one. ## The trap of one-sided isolation A commonly underestimated trap is a module that looks isolated by one signal but not the other — the canonical example being a **reporting or analytics module** that almost nothing else calls (very low inbound code coupling, which looks great on paper) but which itself reads directly from thirty tables owned by ten different features (very high outbound data coupling). Judged only by "who calls this," it looks like an ideal first seam; judged by total coupling including data dependencies, it's one of the worst, because extracting it either requires it to keep reaching across service boundaries into other services' private data (undermining the whole point of decomposition) or requires building data-replication or API integrations with ten different teams simultaneously before the extraction can even begin. Effective seam identification always checks both directions and both code and data before committing.