In my travels, I have noticed many companies are sitting on legacy applications that are good candidates to migrate to .NET.

While many of these applications run fine right now, eventually they will become obsolete due to changing business requirements, new operating systems, missing source code, etc.  Upgrading to .NET offers significant advantages, but the time to start upgrading these applications is *before* they become obsolete.

Planning for Obsolescence

Planning for the end of an application's life should be a part of your overall IT strategy in your company. Does this mean you lose all the investment you put into this application? Not necessarily. Hopefully the application has provided value to your company.  There are plenty of business rules, screen elements and other valuable assets in the existing application that can be leveraged in the migration to .NET.

Starting the Migration Process

One of the first steps in any migration process is to identify which applications should be migrated first. Once you decide on this, you should find any old specifications or requirements documents that describe the old system. If you can not find any, then create new ones. The goal is to create a new document that describes what the new application will do, what its goals are, and what the value proposition (ROI) will be to the company.

The next step is to prototype the screens in the new technology. Either ASP.NET web forms, or maybe Windows Forms. This step should be fairly easy since you have an existing application that you are designing from. However, you might want to the opportunity now to update the look and feel of the application to some of the newer ways people like to view applications.

When you are doing the prototyping, you should look around on the Internet for any tools that might help you migrate the screens and/or code to the newer platform. While the code may not migrate perfectly, it can be a help to identify business rules. We always recommend re-writing code as opposed to using code that is converted, but we need to find all the buried business rules in the existing code.

As you prototype the new application, you should also be updating the specifications and requirements document with any new business rules, fields and additional screens that will be added to the new system.

Using a Framework

Before you begin any serious coding, you should have a Framework in place. As most of you know PDSA is a strong proponent of Frameworks. We believe that if you don't have a Framework in place, you should purchase one (preferably ours!), or create one. A proper Framework is essential to ensuring your application development is done correctly, quickly, efficiently, consistently and ensures a lower Total Cost of Ownership over the life of an application.

If you look at many of your legacy applications you will most likely find the same routines written in each one. Take the time now to find/create a Framework that creates these routines in one DLL and can then just be re-used as you migrate each application.

Write the New Code

Now that you have created the prototype, created a specification document, consulted with the users of the system, convinced management of the ROI of the application, put your Framework into place, you are finally ready to start coding! Now is the time to look at other tools that can help make your job more efficient. For example, are there third-party tools that will make your UI design better, quicker, more efficient, and take you less code to write? Use CodeSmith, or the PDSA DACGen (from the PDSA Framework) code generators to develop the CRUD (create, read, update, delete) logic for your database calls.

The goal of developers today should be to reduce the amount of code you write and to focus on the business rules of the application. How the application manages the business is most important, not how many cool, wiz-bang routines you wrote. Those programmers that write applications to save the company money or reduce costs are the programmers that are most valuable to the company.

Summary

While migrating legacy applications does take time, money and resources, the upsides are tremendous. You will keep your programmers skills up to date, you will get better documentation, you will get a better, more robust system that is able to grow with your business, you will get a chance to put standards and a framework in place that will help with all other applications you migrate and create from scratch.

My company (www.pdsa.com) have done many migrations over the last few years. While it is never a "slam-dunk", once it is complete, the upsides for our clients have been huge. I have posted many samples that can help developers migrate their applications up on my Inner Circle at www.paulsheriffinnercircle.com.