Well you're not asking me but this is a forum so off I go anyways. This can only be done with serious investment, so you need to ask your management if they are serious about the long term future of your product. If they are there's basically two options.

The first option is to develop an API layer over your old system, that is supported by a full integration test suite, and then either build a new frontend using that API, or port the old frontend over to that new API. As this effort progresses, your integration test suite and well defined API allow you to replace/rewrite portions of your backend as well.

The second option is to look at your most valuable customers, discern what features they use and rely on, and design a fully separate clean slate implementation of only those features in a new "V2" product.

In either case, what you're describing is a very tough situation, and any solution would be very risky. Management usually is not aware of tech debt, they might not know they've accrued a million dollars or more of engineering debt that they will have to pay off to solve problems like being able to quickly respond to new market developments, retaining high quality engineers or ballooning customer dissatisfaction.

I have never done what you describe, and so I can't say "from my experience".

However, I would say that Job #1 is to identify what the end users (and the customers if the two are different) think this does. Reproducing the system they use/ paid for is the important goal of the rewrite, by definition if you can't fill that role you failed. Technical considerations (it would be nice to have Continuous Integration, it should be in C# not Java, it should run in the Cloud) are necessarily less important.

If you currently have little or no documentation this process produces valuable documentation and it concentrates you on what's important versus unimportant in a way that studying the existing software as a programmer does not. The trickiest code in the software could be so vital that without it your rewrite is useless or equally never used and you can't figure that out by staring at the program's code.

Once you have that high level you're in better shape to drill down and then I think you're in a better place to figure out if a rewrite is appropriate versus maybe you can refine the existing software.

Not the OP you're asking the question to, but I was in exactly his case. I hate rewrites and joined a new company (this was 5 years ago) that was failing their rewrite(6 months in, 4 "verticals" to port, only half-way the first one). The original code was a PHP/JS mess done in the Philippines that worked but was insanely awkward to change/deploy/monitor: think all the fad you learn at uni about micro service/design pattern/latest devops but no experience to tie it all in in a logical way - which is fine, startup, successful nonetheless, VERY cheap devs yet motivated.

So, the rewrite was a failure because the new team was smug, very smug. They were in Hong Kong, elites of Asia, trying to rework the "shit" done by the remote guys, and so they... well they over-engineered a monster from scratch in Grails (argl, I nearly died, having joined to do Java), and were hitting the limits of their Grails abilities (no tools, no debugger, no experience, no support, a new version just out the month before they started that change all documented paradigms, an architect who only wanted Grails and nothing else and didn't care whether the product did anything or not).

So well the thing we did to eventually move the mess to production (so we have a dying Philippino software we can't maintain because we fired all the devs there prematurely ofc, and a 25% done product in a state that's going to the wall even faster than the old one):

- Unsmug the team: teach them Grails (sadly, I was... the most experienced grails developer myself, against my will, having been a victim of it in all my previous jobs), isolate the most damaging devs

- Re-hire the PH team and move them to Hong Kong to fully maintain the old software, for 2 years, while they also learned Grails and moved to the new system with their precious new skill (they never thanked us, weird)

- Learn the old system: respect its decision algorithm that were not simple, understand why it was slow/ugly/messy whatever, rather than say it's because the devs were inferiors: we slowly realized they were not

- Slow move everything to the simplest possible technology rather than beautiful one-pager bullshit like Grails or Angular or whatever.

So my advice to you is: embrace the fact you will not do better. You will do worse or the same. Rewrite for a business reason, and if possible smaller parts. Do not be so smug as to say "bloated code" or "without any planning for a maintanable design". All it takes is 2 months of money making pressure to entirely destroy any code base, and guess what, people will want your software to make money, not just be beautiful.

Start a new company and eat the old bloated ones business...