In my experience, the code monolith doesn't need to be utopian/pristine in order to refactor to microservices, but it does need one thing: each (potential) microsevice MUST own it's own datastore.<p>If I have a widgets service, and it shares a datastore with my foobar service, things become very tricky to refactor. Furthermore, if every update to the widgets table requires an update to the foobar table, the unnecessary complexity is still there.<p>So before decoupling to microservices, I would try to refactor the monolith such that each future-service is storing its own data in a silo. This usually requires non-trivial changes to the way your apis are being consumed, and thats where the real work comes in. It also takes embracing some data design patterns that folks might be uncomfortable with (redundancy, inconsistency, etc). But once you jump those hurdles, you're usually good to go.<p>Hope that helps. It's not easy, by any means, but it is worth it (IMHO). But oh, yes, you're definitely going to need a strong devops/ops team to keep a suite of microservices running. Containerizing each service (such that the ops people don't have to maintain N different server types) is a good first step towards making their lives easier.