AngularJS makes it easy to migrate an existing Classic ASP to ASP.NET MVC without a total rewrite!
There are so many technology options these days and multitudes of trendy Web Frameworks – like Ruby on Rails, PHP, J2EE, etc. This article, however, is focused on AngularJS build against an ASP.NET MVC 4/WebApi service. It is probably the easiest choice for our purposes here because you can migrate an application through a series of minor updates.
Reasons for choosing to add AngularJS and the ASP.NET framework to your Classic ASP app:
- Small commitment to new technology
- Costs of hosting is similar to Open Source frameworks
- Ample knowledge resources
- AngularJS supports AJAX better than JQuery.
- Allows you to move toward more loosely coupled modules
Let’s start with the assumption that the Classic ASP application is using VBScript, and connecting to an Access database or other ODBC-based relational database, and is running on Windows Server 2003 with IIS 6. The first thing to consider is moving the site to the latest Servers supported by Microsoft, which as of this writing, are Server 2008 R2 (with IIS 7.5) or Server 2012 R2 (with IIS 8.5). Also consider using the latest version of Visual Studio which at this time is 2013. There are also some MVC 4 project templates available for Visual Studio 2010.
To solve this problem, the proposed architecture is to create an ASP.NET MVC/WebApi application and host it in a folder underneath the Classic ASP application. This way, both applications are within the same domain and security and certificates are not an additional issue. Also, if we were to have the new service hosted on a different domain, this would present a security issue called “Cross-Origin Resource Sharing” (or CORS). This is a built-in security restriction in all of the latest browsers. There is actually a way to CORS-enable your WebApi service, but it is out of the scope of this article since we are focused on a simpler solution.
The technology that makes this solution easy is AngularJS. It goes a long way towards providing a framework when using Ajax and Json. So, the proposed migration technique is to begin moving features out of the Classic ASP application to the new application. Start by building an ASP.NET MVC project and include WebAPI. This way, the two Controller types (MVC and API) are included in the same application. A service layer can be built using API Controllers and new UI Pages can be created using an MVC Controller.
Before attempting to migrate any existing features or build new ones, it is suggested that you install the new service application and the ASP pages modified with AngularJS to the production environment sooner rather than later, so that minor issues like security, permissions, and operating system upgrades are resolved early. These minor issues could complicate a future install – plus it is easier to back out changes by turning off the new Web Application.
The next step is to plan the migration. An example sequence of tasks might be to move user management services and peripheral data services like look-ups first. Then, you can continue to move other existing features, as well as add new features that have been created in the new MVC application. To handle user authentication between the two layers of this solution, you can pass the Request object when switching between the two sites.
We also feel that by taking this approach, companies can stick with the trusted Microsoft Technology Layer that they have already based their solutions on and invested in heavily, without having to risk investing in the many “trendy and temporary” tools out there that gain the fancy of many developers.
1. Are there any automated tools available on the market that can automatically convert Classic ASP to ASP.NET or Angular?
Unfortunately, it isn’t this easy. While there are some tools out there that can change a few things here and there, the two platforms (Classic ASP and ASP.NET), and the more modern toolsets such as AngularJS are too fundamentally different for any tool to know how to automatically convert them. If you do a quick search on Google, you’ll find that most tools out there might solve 15% of the problem, but the automatically generated code the migration tool creates probably isn’t very high quality, and needs to be fixed anyway. And while it may be tempting to outsource the ASP migration to cheap developers overseas, the quality you’re going to get from that is also going to be very low. The only way to effectively do it is with a real migration plan and developers who really know what they are doing.
2. Is Angular/ASP.NET MVC a better option for my migration than something like Ruby on Rails?
While you certainly could “migrate” your Classic ASP app to Ruby, it’s going to be much more of a re-write and less of a migration. Veering away from Microsoft technologies into the open source world is going to mean there’s a lot less opportunity for code re-use. Plus, it also means you may have to move from Windows to Linux on the server side (or at least it would be recommended to do so if you were going with a Rail stack), and not to mention, your existing developers are going to have a much harder time picking up Ruby than they would ASP.NET.
3. Is there a Classic ASP Framework I can move to that is more modern than the version I am on? When does Microsoft stop supporting or sunset Classic ASP? How old is Classic ASP anyway?
Classic ASP 3.0 came out in November 2000, and was included in IIS 5.0 – that’s the most recent version. Technically Windows 8 will support Classic ASP until at least 2025 – though your operating system supporting a technology is a very different thing than the web browser you are using rendering those pages well. As a note, Windows 2016, which will include IIS 10.0, is expected to be released in early 2016 – so if you are running ASP 3.0 pages right now, you are running software that was developed for an IIS (Internet Information Services) version SEVEN (7) versions old – and 16 years old. For some perspective, in 1996 when the internet first began, what was the ability, power, and maintainability of software that had been written in 1980?