If you are planning to maintain an application for more than a decade then be careful.
I'm in middle of a case of modifying an ASP.NET WebForm application back to 2006 so 10 years old from now. This application is live for now and it is running for no problem. One month ago we migrated its hosting from Windows Server 2003 to Windows Server 2012 R2 successfully. I can imagine if no modification is needed it would be live for another more decade despite vast changing world of web development and .Net.
But our current problem is different than relocating it from a 2003 windows to a 2012 one. We want to modify it so change or add behaviors to it. Some modifications are easy to apply. For example if an HTML/CSS change is wanted it can be done by modifying ASPX/ASCX files easily. But modifications in code behind ASPX.CS and ASCX.CS file are not easy. Because our application is compiled and no CS file exists in hosting IIS. So changes must be applied in source code then published and converted to DLL files then deployed on the hosting IIS. Our application has dependencies to other assemblies like AjaxControlToolkit 2006 and we have not exact version of them currently. So our application simply wont build and wont publish easily.
At first glance I thought the only choice that we have is to upgrade all dependencies to current version that is impossible. From ten years ago til now many of third party libraries have been discontinued or have many breaking changes. Even ASP.NET itself has been changed very much. Fortunately I got a good solution. That was simple and trivial but I didn't noticed it before. We had published version of the application that means we currently have needed assemblies that are referenced from application. No matters if they are very old or we have not access to their source code. They are valid and executable .Net assemblies that can be referenced from any .Net application.