|I see this all the time. A few years ago I was contracted by a company to convert their Clarion application to .NET. The inhouse devs were all Clarion programmers with no knowledge of the .NET framework and no knowledge of any .NET language.
The database was non-normalized, and even worse, fields like (I'm making one up, but you get the idea) "sky_color" that obviously mean one thing had been hijacked to "season of the year" because "sky color" became obsolete and it was too nasty to go back into the Clarion code and fix it and the database, so instead of the label in app for "sky color" was changed to "season."
The business logic was smeared across Clarion client code and PL/SQL, and, for an app that was responsible for records management of local and state government services, none of the business logic that had evolved over the years was documented.
Oh, and I did mention that no one was using source control, so you could even see the evolution of the work?
And it was a huge application with hundreds of screens and tables. And that was one app, which "integrated" via the data it manipulated with other apps.
When I did an estimate (and a very optimistic one at that) of how long it would take to simply get a baseline document of "what and how" (gleaning the why was an impossible task) of the existing application, no new code, simply documenting what the current app did, I came up with a 3-5 man-year estimate. Actually, I didn't come up with the estimate, I led the senior management through the process. Quite simple actually:
Q: "So, how many forms do you have?" A: X
Q: (to devs): "So, how long do you think you need to document what this form is doing?" A: Oh, about a week for each form.
Conclusion: "So, you're telling me it will take X weeks to simply baseline this product?"
Result: Shocked looks by management. But the answers came from their own employees!!! And they never bothered to ask those questions until I came along.
Then of course, was the realization that they couldn't normalize the database because of the interdependencies with other apps. So the idea of a "data bridge" was proposed, which would shuffle data automatically between the legacy DB instance and a normalized DB instance. That concept didn't even manage to taxi onto the runway, let alone take off, before...
...the whole project was killed, the company bought an upstart competitor (including their dev team) for a couple million dollars. Who knows where they are now?
So, I hear your pain. As others have posted, my advice is be up front and honest. Explain the situation in non-technical terms, time and money is usually the best approach with management, suggest options, and let them decide how they want to proceed. And be prepared that the people in charge of the failed project will be defensive, confrontational, and unsupportive. In my situation, I was faced with the cronies who originally started the company, and like sheep, they flocked together in their denial. Ultimately, besides me, one of them was sacrificed to the wolf and no longer works there.