ASP.NET MVC applications are compiled. This means that you can't just upload the changed files, like you do with a PHP website, for example. This also means that when you'll start to update the site, current users will be thrown away (lose their sessions, for example).
There is also much more to do than simply update the files: you have to handle:
Permissions
The new version may require a different set of permissions on the server.
Configuration
The new version may require the Distributed Transaction Coordinator (MSDTC) service to be installed, or may want to use a different SMTP server, or have access to Active Directory, etc. This involves changing both the configuration of the application and of the server itself.
Dependencies
For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.
Data
What if database schema changed, and the application uses an ordinary SQL server instead of NoSQL? How to perform the change in the schema? How to keep the data correct during the change?
Handling the transition between an old and a new version of the application is a hard task. A few years ago, it was one of the issues, where a new version of application was ready, but took days or weeks to system administrators to deploy. DevOps addresses this issue, but requires for the developers to describe (through code or configuration) the system which will host the application.
The larger is the application, the more complicated is this task.
For a tiny web app, copying source files to the server is enough,
For something larger, you have to have an automated process which deals with the update process, and the rollback in case something goes wrong,
For systems even larger, at every new version, new VMs are created and deployed, and old ones are recycled, ensuring seamless transition of the users from the old to the new version.
Compiled applications simply force/encourage to automate the process earlier.
the business contacted us to update some of the text and add a link to a new pdf document. The rest of my team were quick to say that this should not be done because the site is now live
IMO, there are no real technical reasons for this refusal; they just want to avoid doing it, because, if not automated well, the task is error prone.
What usually happens is that:
The application is deployed for the first time.
The team spends a few hours tweaking the configuration to make it work. Since the team was expected to deliver three weeks ago, everybody rushes, and nobody takes the notes of the changes.
The application is now up and running.
For a few weeks, months or years, some random people change some random stuff on the server: for example they moved a database to a different location, or the SMTP password changed, causing the changes in Web.config.
If you update the new version now, you're back to the first step, and it may take days to recover the correct configuration. Since the website is live, this should be avoided at all costs.
Best Answer
Webforms vs. MVC seems to be a hot topic right now. Everyone I know touts MVC to be the next great thing. From my slight dabblings in it, it seems ok, but no I don't think it will be the end of webforms.
My reasoning, and the reasoning as to why webforms would be chosen over MVC, has more to do with a business perspective rather than what one is better than the other.
Time/money are the greatest reasons why webforms would be chosen over MVC.
If most of your team knows webforms, and you don't have the time to get them up to speed on MVC, the code that will be produced may not be quality. Learning the basics of MVC then jumping in and doing that complex page that you need to do are very different things. The learning curve is high so you need to factor that into your budget.
If you have a large website written all in webforms, you might be more inclined to make any new pages in webforms so that you don't have two very different types of pages in your site.
I'm not saying it's an all or nothing approach here, but it does make your code harder to maintain if there is a split of both, especially if not everyone on the team is familiar with MVC.
My company recently did three test pages with MVC. We sat down and designed them out. One issue we ran into is that most of our screens have the View and Edit functionality on the same page. We ended up needing more than one form on the page. No biggy, except then we wouldn't use our masterpage. We had to revamp that so that both the webforms pages and MVC pages could use the same masterpage for common look and feel. Now we have an extra layer of nesting.
We needed to create a whole new folder structure for these pages so that it followed the proper MVC separation.
I felt there were too many files for 3 pages, but that is my personal opinion.
In my opinion, you would choose webforms over MVC if you don't have the time/money to invest in updating your site to use MVC. If you do a half arsed approach to this, it won't be any better than the webforms you have now. Worse, you could even be setting this technology up for failure in your company if it's messed up, as upper management might see it as something inferior to what they know.