Modernizing a Classic ASP Web Application to .NET

Posted on Updated on

I’m currently working on a classic asp system started in the late 90’s. It was developed in ASP using Sybase. The system consists of a classic asp application, Windows PowerBuilder application, Windows PowerBuilder Batch applications, and Java Batch applications. The windows server is 2003 and Sybase is 12.5. The primary reason the database hasn’t been upgraded is because of the PowerBuilder applications. We’re in the process of rewriting the batch applications and the single Windows application by adding the features and capabilities to the web application.

It’s my understanding there have been two attempts to rewrite the system in Java, both attempts failed. Why did they fail? I’m not sure, but I believe it was because it was taking too long and the users were not happy with the UI. Based on my experience, doing a rewrite on a large system rarely succeeds because the tendency is to redo everything.

In the early 90’s there was an initiative at the company I was working to rewrite some DOS applications used by their sales engineers with a development team of three programmers. The initiative called for a new Windows 3.1 system to be developed in PowerBuilder. It was going to take 18 months to completely rewrite and deliver the system, seven years later was the first released. It was called a success, but I think it was management’s spin on something they couldn’t let fail.

Another time, I was asked to estimate a rewrite on a project that was written in Microsoft Access. My basic estimate was that it would take three developers about 3 to 4 years or 10 man years. Executive leadership went with a consulting firm because the effort was going to take too long and the consulting company could do it cheaper and faster. In the end, it took two full time developers (on-site) around six years to deliver the first release.

I’m not saying you can’t do a complete rewrite of a large legacy system, what I’m saying is that stopping everything and doing a complete rewrite is usually destined to fail. It’s no fault of anyone involved in the project, it’s a matter of expectations and what it takes to rewrite a large system. The time and resources required to redesign and rewrite a legacy system is significant and usually the task is grossly underestimated because management insists it can’t take that long, it’s only code.

Given that small rant, I believe any organization wanting to modernize their system needs a good plan in place and needs to look at how they can achieve modernizing a system without rewriting the system all at once. One thing I’ve noticed over the years is doing development in small chunks and delivering often (3 or 4 times a year) seems to work the best. Management likes it and users accept small changes easier than having everything change at once.

At my current place of employment, I believe we’re on a good track for rewriting the current asp system because we’re not trying to do everything at once. It’s going to take time and project management is trying to lay out the order of everything, but we’re doing small pieces for each release which allows us to make adjustments as technology and requirements change. We made the GUI look and work the same as the legacy system to make the rewrite as transparent as possible to the end user. So far, things are working out very well.

The basic architecture for the new system is to create restful web services for backend processing and use .NET MVC 5 with AngularJS for client side pages. It’s not complex and Microsoft has made it easy to create restful web services, which is helping the process. The biggest problems we have are related to Sybase and how Sybase works with the ORM (Dapper). As a whole Dapper works really well, except it does have issues with Sybase which (based on reading the internet) do not seem to be happening with SQL Server or Oracle.

How does the architecture look in the new system? In order to keep things short I’ll write about that in my next post, which could take a while.

Leave a Reply

Your email address will not be published. Required fields are marked *