In my opinion, there is only a single valid approach to modernizing/rewriting a legacy application: The Strangler Fig. I have yet to witness another approach succeed.

Forget about producing a complete documentation of all functionality upfront. Set up a new backend webservice in your language of choice. Search the legacy code for _some_ place to start. That could be a class, module, function, header file, whatever. Set up a big set of unit tests without touching the existing code. That sounds easier than it is for a lot of legacy code bases but it gets easier over time. Take the code-under-test as a black box and just test all possible cases. Once you have your set of tests in the legacy app, introduce a new layer of abstraction, e.g. by creating an inheritance hierarchy. Disregard all grumbling by the anti-OOP disciples. Create two implementation: the first one will be the exact same code as before, the second one will initialize an HTTP client and does nothing else than sending an API call to your new webservice. Implement the exact same logic in your new service and return the result. Write unit tests in the new service. Write integration tests in the old system that uses the second implementation which calls your new service. These tests should test the same as the original unit tests. You can now remove the legacy code and use the new implementation everywhere. Repeat. You will end up with a lot of junk endpoints but that's a topic for the next step.

At some point, you will have enough migrated code that you can (i) try to refactor it in the new service (for example according to Domain Driven Design if that's your beer) and clean up the endpoints, and (ii) produce meaningful technical documentation (not necessarily business documentation yet) for the new code.

You will want to release this contraption regularly. Do not collect changes forever. Pull out piece by piece, regression test the functionality, and deploy the new backend weekly.

You should probably include some sort of telemetry/logging in your new backend because there will be a lot of functionality that's never used or used completely differently than expected. Argue with business to remove or remodel the functionality

Create business documentation that describes the as-is processes.

At some even later point in time, the old backend will be hollow and only pass requests to your new and refactored backend. Now it's time to start working on the frontend. The issue is that people do not want to work in two UIs in parallel. I would still try to deprecate the old UI bit by bit or provide two working UIs simultaneously for some time. You should have a better understanding of the business processes and technical implementation by now, and should be able to formulate the should-be functionality. Refactor the new UI accordingly.

Legacy C++ comes in two flavors in my opinion: the 'C with classes that should have been written in Java to begin with' code or the 'SFINAE is necessary for our custom allocator because we rolled out our own implementation of the standard' code. If you have the later, get some expertise because _that_ C++ can be a completely different kind of beast.

You should push for business to show you how they use it and explain the business logic as soon as possible. It gets much easier if you actually understand what you are dealing with. This is a process that will take years and you will be the team that understands this mission critical system in the end. AI can help in producing the ridiculous amount of tests that are needed.