For this particular instance and company, no. Not because microservices can't work, but instead because of the coordination required between services/api/database that doesn't appear to exist at all in this company.

This said, depending on your application and how it's split up quite often there are easy wins. An example I've seen is a company that had a huge batch reporting jobs for reporting at fixed intervals. Hammered the hell of out production, so was moved to pull data from a read only replica.

It really depends on what they are doing. At this stage, I'd suspect it needs some major rearchitecture, but they accumulated so much tech debt it's difficult to say what next steps could be. As was pointed out by others, starting by introducing some strong governance practices would be a good start.

My department was in a bad single-DB position like this. The only way out was big rewrites, and generally each team had one service with its own DB in the end. Dunno if you'd call that microservices or not.

I would if they can have their own release cycles.

Then yes

The important thing in these convos is to be clear each time what you mean by "microservices," because there isn't a solid definition for that. I've seen too many debates at work over whether we should use microservices, where both sides already agree on the actual design.