remote
     synthesis

Migrating Legacy Apps to OO (CFObjective Session Summary)

Posted on Mar 20, 2006

Matt Woodward gave this session. He defined a legacy application as one that has been in service over several years and/or one that doesn't work on CF7 (i.e. it is potentially in need of a compatibility update at the very least). Matt emphasized the need to balance business needs with our "geek desires." By this he meant that, as developers, we are constantly drawn to using the "latest and greatest," and in the ColdFusion world right now that means building applications using frameworks and an object-oriented approach. However, what makes great code sense (and sounds interesting and cool), may not make much business sense (i.e. if it ain't broke...). Along these lines, Matt laid out some reasons to migrate.So why migrate?

1. Your legacy application is becoming difficult or expensive to maintain
2. It can't interact/deal with modern technologies (for example: xml, web services, Java)
3. The application is fragile and prone to breaking
4. The application lacks documentation and the original developers are no longer available
5. You have to update for regulatory reasons (for example for Sarbanes-Oxley compliance - which I am familiar with in my job)
6. The application is no longer meeting the needs of the business

We need to remember that upgrading an application is a business decision and not a technology decision. In almost all cases, a lot of time and money has been spent on the application. Plus there is the cost involved in upgrading, which is often more than any equipment, software and labor costs, but may extend to "opportunity cost" (basically that when you are working on this you are not working on something else - like a new revenue generating initiative for your company). However, once you have determined that a migration is necessary, an object-oriented approach is recommended because it follows standard practices and offers low-impact maintenance.

Matt discussed an application that he is currently migrating (which was two applications combined in a single directory of about 1500 files). He discussed some lessons he has learned and some knowledge he has been able to leverage to help run the migration process effectively.

One strategy is to be sure to pick your battles effectively. Break your application up into logical chunks and decide where to start and migrate section by section. Another is to be sure to understand the risks involved in any migration plan and have a fall-back plan. Two general strategies identified were:

1. Start with what is most necessary
2. Identify general opportunities for refactoring
   • Rework redundant code
   • Organize - make code easier to understand

Some steps to follow are:

1. Divide the application into subsystems (conceptually)
2. The next subsystem you have to modify becomes your first candidate for migration
3. Preserve existing functionality
4. Test!
5. Repeat this process until you have the application completely migrated

Matt suggested that a good MVC framework can help as well, in part by offering a consistent and documented way of doing things. He also recommended creating a roadmap, keeping in mind a couple of final principles:

• Don't change too much at once
• Be realistic - you cannot fix everything at once

Prior summaries are available: Objects and Persistence, Subversion, Positioning ColdFusion, Duck Typing and Using Factories and ColdSpring AOP.

Comments

There are currently no comments for this entry...be the first!