He (the client) is paying your salary. I guess that wins

But he's paying me to be the expert. As a consultant, I owe him the best recommendation in my eyes, looking to save money, increase productivity, allow supportability, and ease of use, etc.

"My recommendation is" "My findings are". It is their decision - no debate - no arguing. You have no authority based on expertise.

I disagree, Expertise is what's supposed to protect the client. I haven't made my claim as to why, and he doesn't know all the pros and cons, but through talking be seem like a back and forth. I think according to the answers I need to only make one claim and back it with evidence and data before complying to whatever the client wants. Of course it's always the client's decision, but he's also paying me to show him all the angles.

Sometimes throwing it all in the trash is a better way forward than trying to get existing systems working. Maybe your client realizes that the existing system may be more work to stabilize than a new system would be to implement properly. Perhaps they are looking at future expand-ability or being able to support other features that the current system won't allow. Are you sure you understand the clients viewpoint completely?

Because he's a new employee and "doesn't understand the system"

The best you can do is explain fully to the client that scrapping the software and starting over will cost X amount in dollars and time. After that, if they choose to do it anyway it's their call.

You never "argue" with a client. You either persuade, or not. If you don't like the what they are offering to pay you to do, accepting the job is not compulsory. As for "the client not understanding the system", I suspect they know that "working" and "unstable" are mutually contradictory descriptions of software, period - which might explain why they don't like the rest of your proposal.

But he's paying me to be the expert... how do you know he's not getting conflicting advice from someone else he considers to be an expert?

he's paying you to be the expert at developing, if he says rebuild from scratch, then do it. He's not paying you to make his business decisions for him.

You could also choose to not have him as client: if he wants a house without a proper foundation you don't want it to reflect back on you when it collapses

@RonBeyer yes, sometimes it's better to throw it all away. More often it's not. Every programmer wants to do that when they encounter a project that's not theirs to begin with. You get that urge to make it all new, because what the previous guys built is bad.............When you get that urge you breathe in....breathe out, toss that silly idea out of the window and start maintaining the existing project.

@Carson63000 that's a great point. conflicting advice from someone in-house, or even pressure from other end-users, etc..

you have a client who really wants you to rebuild from scratch instead of modify something old? paradise! and probably longtermsensible if he is using the application for long. And you, the developer, want to convince him otherwise? I call THAT a unique situation.

It's really simple: Yes, As a consultant, I owe him the best recommendation etc.. But the client owes you just money. He does not owe you to behave like you sugest, for example. That's just none of your business.

I'm surprised you "obviously" disagree with scrapping "unstable" software, actually. I suggest you think about the adage that "the customer is always right". You might not agree with that adage, but it became one for a reason. If you agree with it, there's your answer. If you disagree, you might benefit from being completely sure of exactly how and in which situations it doesn't apply.

Consider also that there could be non technical reasons for scrapping the existing working system, even if it is technically unwise. One example is if the existing system has potential intellectual property issues. Paying someone to reimplement the system from scratch is one way to resolve such issues. This may or may not be the case, but consider if it is the issue, the client is probably better off not discussing it with you.

Throw Joel at him!

There is a middle ground between the 2 extreme's you presented. Maybe it's just a matter of finding where both you and the customer is comfortable in that middle ground. Usually, from a customer point of view "THE UI IS THE APP". So perhaps slapping a modern and more friendly UI on top of the main application and getting rid of the bugs in the old app would be a good middle ground that would make your customer very happy.