The problem microservices actually solve
Independent deployability for independent teams. When six teams contend for one release pipeline and every deploy needs cross-team coordination, service boundaries let each team ship on its own schedule.
That is an organisational problem with a technical solution. If you have one team of eight engineers, you do not have that problem, and splitting the system will make daily work harder rather than easier.
What you pay
Every network hop introduces latency, partial failure and a retry policy someone has to think about. Debugging moves from a stack trace to distributed tracing across five services. Local development needs orchestration. Data consistency becomes eventual, and every place that assumed a transaction now needs a compensating action.
These costs are real and permanent. They are worth paying when the organisational benefit exceeds them, and not otherwise.
The better first step
Modularise inside the monolith. Enforce boundaries in the codebase - separate modules, explicit interfaces, no reaching into another module's tables. Enforce it in CI with dependency rules.
This gets you most of the maintainability benefit with none of the operational cost. It also means that when you genuinely do need to extract a service, the seams already exist and extraction is a deployment change rather than an archaeology project.
A reasonable trigger
Extract a service when a specific part of the system has a clearly different scaling profile, a different compliance boundary, or a dedicated team that is measurably blocked by the shared release cycle.
Extract it because of a named constraint. Not because the architecture diagram would look more modern.