First, the client might be right. Even expert consultants are wrong often. There should actually be no need to erase totally all existing code. It's very likely that many procs can be retained. The client may easily agree that much may be salvaged, or refactored.
Next, is there evidence of 'instability'? If so, then perhaps the client's confidence in outside expertise is already strained. Unwavering opposition will strain whatever the current status is.
It's not clear what the current project covers nor the scope of it, so it's difficult to suggest a truly valid action. But I have had to insist to some customers that they were wrong.
A case that worked for me:
The big case that comes to mind was a regular and often recurring error message out of one of our network security products at one customer's site. They were in New Zealand; we were a few miles south of Seattle, WA. A few conference calls for remote support led me to realize that they had a minor TCP/IP configuration problem.
I recommended that it be changed, but the response was that it was correct as it was. The group on the call was mostly their 'security' group, so I asked if they would bring one of their networking admins into the call. The response was that it wasn't necessary because they already knew it was alright. After all, they had out-sourced the initial network configuration to "experts".
Inside, I was thinking, "Idiots." I was also furiously thinking how to get past this mess.
We closed the call with a basic agreement on how we'd proceed with resolution even though I knew it wouldn't help. During the rest of the day, I wondered how to convince them to make the configuration change. That got me thinking about how to detect that such a somewhat obscure change should be made before our products were ever installed.
I started coding a reasonably high-level TCP/IP configuration analyzer. It retrieved basic info about adapters, interfaces, IP addresses, etc., did a set of standard DNS APIs, checked existence of loopback/localhost, etc.
It also did a few extras like checking how aliases were associated with host names and some peripheral elements of the configuration. None of it exceptionally deep, but it did some general cross-referencing to ensure that a given interface was both active and had an IP address that matched a valid host name for the system. After grabbing configuration bits and doing the cross-referencing to ensure that all parts fit together properly and coherently, it not only printed what it found, but it also gave recommended changes when anything looked out of place.
A few days later, we sent it to them and asked them to run it. Of course, it found exactly what I expected and printed the same as I recommended during the last conference call.
They made the recommended change. The original "problem" with our product disappeared. And all was well from that moment on.
Why? Well, I don't really know.
But there was something extra-authoritative about seeing output from a fancy-shmancy "Networking Configuration Analysis" program that they ran themselves on their server. (Even though I wrote it...) It seemed to have sufficient expertise to convince them. Perhaps it helped that every detail of output exactly matched their configured values. At least it wasn't simply bogus.
Not your situation unfortunately. But it might indicate that you can find a way to appeal through some other avenue that leads to agreement. Other consultants perhaps? Any client staff that can be leveraged? Any analysis tools that give guidance?
Any chance the client is right? I've seen software that was better being rewritten than merely refactored. (I've written some in a 40+ year career, generally my first efforts in unfamiliar system environments.)
With more question detail a better answer might be possible. It's difficult at best, but it seems that the question boils down to whose 'opinion' is right. Metrics are possibly hard to come by.