Years ago, when I started to develop Intranet MVC 5 web applications for a small business, I would host one MVC app on a dedicated IIS port. In other words:

• Web App #1: http://sampleServer:4000/Home/Index
• Web App #2: http://sampleServer:4001/Home/Index
• Web App #3: http://sampleServer:4002/Home/Index

However, the clients did not like it because “they didn’t think that way” and wanted “one single website”. So I refactored and used only one MVC application hosted on a single port. I used the Areas feature to organize the code. So now, I have something like this.

• Web App Homepage: http://sampleServer:4000/Home/Index
• App 1: http://sampleServer:4000/App1/Home/Index
• App 2: http://sampleServer:4000/App2/Home/Index
• App 3: http://sampleServer:4000/App3/Home/Index

So that I don’t have to keep writing and debugging internal links, I use the Nuget package MvcSiteMapProvider.MVC5. The sitemap provider makes it convenient for me to manage links because I have all my links in one and only one file rather than hand-coded all over the place.

However, over the years, this single app has grown. Because it’s now a larger project, if I need to deploy a fix in a controller. I need to deploy the whole application, which takes a few minutes due to its size and Intranet traffic.

Is there a strategy so that I can split the MVC app into smaller MVC projects? From what I’ve read use of “Areas” seems to be the prevalent method. It’s why I used Areas to organize my project. I see the benefit of breaking the project into distinct projects — as it was in the very beginning — but giving the users the illusion that they’re looking at a single website.

Are there any approaches I can use to provide the users the “single website” illusion on the client-side while allowing me to spit one large MVC app into smaller apps?