You could always replace it with a modular monolith in stead of microservices.
You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith.
In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).
Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.
That's a valid concern!
But surely there's a middle ground, maybe along the lines of: "okay, this is our main modular monolith codebase, but we'll make the decision to split this one vastly different type of workload in a separate service, since it adds 20 dependencies and we don't want to add that complexity in a codebase that's otherwise a fairly straightforwards RESTful API."
Yet, it's a bit odd, because people often talk about DDD and drawing domain boundaries, instead of "okay, so this group of functionality will need to export PDFs of bills and receipts, so we'll extract that and all of the related functionality because of technical considerations, whereas we don't care about adding 10 more API endpoints to our main codebase, because there's another 200 there already."
Instead, everyone seems to go "ohh, we'll have users in our system, so that's UserService (myproject-locksmith), we'll have orders in the system, so that's OrderService (myproject-bookkeeper), there's also bills so let's make BillService (myproject-scribe)" and so on.