Drawing boundaries in a legacy monolith before you split services
· Lindiwe Mokoena
Teams often feel pressure to decompose everything before a cloud move. In practice, lifting a well-understood monolith into a managed runtime—and splitting later—beats a rushed extraction that breaks transactions.
Follow the data writes
Map tables or collections that receive writes from more than one module. Shared write paths are seams you should not cut in the first migration wave. Mark them as “co-migrate” in your diagram.
Identify synchronous chains
Long in-process call chains that cross business areas are candidates for module-level packages first, HTTP later. Note timeouts: what is acceptable inside the process may fail across a network.
Use feature flags as boundary drills
Before extracting a service, route traffic through an interface inside the monolith and toggle implementations. If behaviour diverges under load, you learn early without new deployables.
When to stop drawing lines
If the team lacks automated tests around a module, boundary work belongs after test harness investment. We say so plainly in architecture assessments rather than selling a premature split.