Step one: high-level acceptance tests. Does the system as a whole do what it should do from the end user perspective? Add your highest priority cases first: the functionality that if we it breaks, your business is at risk. Keep adding more cases.
As for many services, are these to separated out to help teams from stepping on each other? I firmly believe that if you have many teams running their own services, that each service should control its own data store, and any communication that does not need an immediate response should happen through a message bus of some sort. If the response is real time, a network call makes sense. However! If you have micro service hell and it is not for scaling teams, you might benefit from going back to fewer services doing more things with shared data stores (but well defined data boundaries and packages). If you have a tangled mess of services calling each other and services dependant on other services and cyclical dependencies, something is wrong. Dependencies should be one direction. If two services share many dependencies, it is worth asking if they should be combined to one service.
Is there an API gateway that allows one place for requests to go? That could help with the confusion of where to find data.
Whatever the desired architecture is, migrating to it requires refactoring and that requires tests. You need to be confident that a change does not break the system.
