Rewriting a monolith from scratch as microservices is a well-known way to spend a year with nothing shippable at the end of it and, often, a system that still doesn't work as well as the one it replaced. The strangler fig pattern (named after the vine that grows around a host tree, gradually replacing it) is the standard incremental alternative: extract one piece of functionality into its own service at a time, routing traffic for just that functionality to the new service while everything else continues to be served by the monolith, unchanged.
1. Monolith handles everything: Orders, Users, Payments, Inventory
2. Extract Payments into its own service; a routing layer sends
Payments-related requests there, everything else still hits the monolith
3. Monolith now handles Orders, Users, Inventory; Payments is fully independent
4. Repeat for the next module worth extracting, when (and only when) it's
actually earning its keep as a separate service
This keeps the system fully working and deployable at every intermediate step — there's no "big rewrite" moment where nothing works until it's all done — and, importantly, it forces the decision of which piece to extract next to be a deliberate, individually justified choice (this specific module has a real, current scaling or ownership problem) rather than an assumption that everything eventually needs to become its own service. Plenty of systems reach a stable, healthy point as a strangler-fig migration that's extracted three or four genuinely justified services and left the rest as a well-organized remaining monolith — that's a legitimate destination, not an unfinished migration.