Your basic problem is that the client technologies are fundamentally different - one of the key drivers for the evolution of Silverlight was to put "rich" client capabilities into the browser.
What this means in practical terms is that the interactive nature of a rich client app is not available in a simple MVC app given that (notionally at least) you're serving relatively static pages.
However one of the reasons for the demise of Silverlight is that you can now build rich client applications in the browser using JavaScript and MVVM patterns / frameworks. So your application would then be a JavaScript (or better TypeScript if you're a C# developer) front end SPA (single page application) talking to a Web API back end.
There are a scary number of choices for building the front end (Aurelia, Angular, Ember and many others that encompass some or all of the layers needed to do MVVM in the browser).
You're still going to need to work out what logic belongs on the server (whether any that was in the Silverlight client should be moved) and what now needs to be re-written.
Addendum
Bear in mind also that "single page" doesn't necessarily mean everything has to be in a one single page/app rather - if there are logical separations you can build smaller, less complex pieces that encapsulate one set of functionality.
.cshtmlfiles for the views so you can use C# in the views. Though I personally can't stand backend code in the view so I tend to only use.htmlfor mine.