A client has asked me to do a redesign of their website, an ASP.NET Webforms application that was developed by another consultant. It seemed like a relatively straightforward job, but after looking at the code, it's clear that's not the case.

This application was not written well. At all. It is extremely vulnerable to SQL injection attacks, business logic is spread throughout the entire application, there is a lot of duplication, and dead end code that does nothing. On top of that, it keeps throwing exceptions that are being smothered, so site appears to run smoothly.

My job is to simply update the HTML and CSS, but much of the HTML is being generated in business logic and would be a nightmare to sort out. My estimate on the redesign is longer than the client was aiming for. They are asking why so long.

How can I explain to my client just how bad this code is? In their mind, the application is running great and the redesign should be a quick one-off. It's my word against the previous consultant. How can I give simple, concrete examples that a non-technical client will understand?

Update

Thanks for all the responses.
The SQL injection attack demonstration makes sense and I will demo this in a test environment. 
That is just one part of many problems in this application. I was looking for ways to explain why other parts (such as html being generated in the data layer)
would need to be replaced with better practices in order for the html and css update to take place. 
There are many good suggestions here which I'll piece together when I talk with my client.

Non-techies aren't idiots (for the most part).  They can understand a technical argument if you keep it high-level enough.  Pick a task you thought should be simple, and walk them through why it's not.


  I expected this change to be one word in one file.  The most likely
  place to change it seemed to be here, but when I changed it there, it
  only worked in one place, and it broke these 7 other places.  When I
  fixed one, it broke two more places, causing a domino effect, so a
  change I thought should have taken 10 minutes ended up taking 2 hours.
  That's just one example.  There are a lot more unexpected 2 hour tasks in there.

