In addition to the other great answers here, you need to keep in mind all the variables (no pun intended) that go into the creation of a solution. The original developer may have written awesome, innovative code for 8 years ago. (Keep in mind that ASP.NET MVC was just releasing version 1 8 years ago https://en.wikipedia.org/wiki/ASP.NET_MVC, and even then there were pieces of it that needed work before it was widely usable.) The Onion Architecture paradigm was first posted on Jeffrey Palermo's blog in July of 2008 (I'm a fan of this.)
Your code today may only be mediocre. It could still be better than the old code, but that's because we have new technologies, up to 5 newer versions of MVC to choose from, third-party support/extensions for MVC via Nuget, etc.
You also have a working product, so you could potentially take as much time as you want to rewrite it; the business doesn't have to switch to your version immediately. What was the previous developer's timeline? Were they in a crunch to get things working ASAP in order to support a start-up or a new product?
It doesn't matter how good you think you are. What matters is how well you can work with others. If the other developer reviews your code and says things like, "I like this! It's better than what I did," then you can pat yourself on the back. To just assume your code is better will make you enemies.
The best approach is to ask the other developer to look at your code and the finished product. "I was asked to do x. How does this look?" is a decent enough question to invite the developer to look at the new code.
If a rewrite was truly in order, sharing knowledge during development is another good way to incrementally show new features to other developers: "Hey! Check out this cool thing I found!", or, "I didn't know about this [language, framework, etc.] feature! Want to see this?". Going the entire development period without feedback is most likely a problem, since potential issues could have been found before they were tightly wound throughout the app.
Another way to prevent issues during development, and incorporate the previous developer, is to ask about things that seem odd. Not all code is commented, and there are likely reasons behind the way things are built and/or working the way they are after 8 years of development and maintenance. You could potentially lose functionality or introduce bugs into the business logic if you are asking these "Why?" questions, unless you had a new backlog of business requirements to work from.