Monolith Decomposition Readiness Checklist
A readiness gate for splitting a monolith into services. It confirms domain boundaries, shared-data risks, observability, and rollback controls are in place before any extraction begins.
When to Use This Checklist
Use this checklist before breaking a large monolithic application into independently deployable services. A monolith is a single deployable unit where most code shares one process and often one database. Decomposition fails most often not because the target architecture is wrong, but because the starting point was poorly understood. This checklist confirms you have the visibility, boundaries, and safety controls needed to split safely.
How to Use This Checklist
Work top to bottom across discovery, data, observability, and planning groups. Treat discovery items as gates: do not draw service boundaries until you have mapped domains and shared data. Add tracing and logging to the monolith first so you can compare behavior before and after each extraction. Pick one low-risk module as the first candidate and prove the full extraction loop end to end before scaling the effort.
Assign each required item an owner. Optional items such as co-change analysis sharpen seam selection but are not blockers for a first extraction.
What Good Looks Like
A ready team can name every bounded context, point to the shared tables that need to split, and show dashboards for latency, throughput, and error rates. A strangler-fig routing layer is in place so traffic can move module by module. CI/CD already deploys at least one service independently of the monolith, and feature flags allow instant rollback. Stakeholders have agreed what success means in measurable terms.
Common Pitfalls
The most damaging mistake is extracting code while leaving the database shared, which recreates the monolith across a network boundary. Teams also skip observability and then cannot tell whether an extraction regressed performance. Avoid "big bang" splits; decompose incrementally behind a router. Do not let service boundaries follow the existing code structure when they should follow domain boundaries.
Related Resources
Review the strangler-fig pattern, domain-driven design, and the modular monolith approach as an intermediate step. The production-ready microservices checklist covers what each extracted service must satisfy before it carries real traffic.