The code generated by an automated conversion tool should be easily maintained in the new environment. The architecture of the applications generated by the automated conversion tool should be multi-tiered to provide flexibility in the new environment. The conversion vendor should be able to guarantee performance and functionally in the new environment.

Create a checklist of the factors important to you and your organization. Review the vendor’s generated converted code before selecting a conversion strategy. Check the background of the conversion vendor and measure the vendor’s success rate with conversion projects. Talk to references. Ask questions. Be sure you’re comfortable with the vendor’s level of expertise and project management style. A process-oriented vendor with a high level of automation can provide a fixed bid for your conversion project and you should insist on that.

The downside of an automated conversion is minimal if:

The goal of the project is to keep the application functionality the same while eliminating the legacy technology.
The correct conversion vendor and vendor solution is selected. (The downside is huge if the wrong conversion vendor or wrong solution target are selected!)
 

Summary

Organizations have options for addressing and replacing the aging technologies around which their business is built. Business and technical goals should drive the solution selection.

Purchased packages and rewrite projects can be viable options. Today’s automation makes data and application conversion both technically and economically feasible and even desirable.

The value of the data locked in legacy applications and databases is huge. The investment in the design, development and maintenance of these legacy applications and databases is also huge. These two factors alone create a powerful incentive to preserve the proven processing capabilities through conversion rather than re-creating the functionality through purchased packages or rewrites.

If your existing legacy applications perform efficiently and effectively meet business needs, then the “life after conversion” for these legacy applications may well be another 20 or 30 years! Converting legacy application and database designs to newer technology, with newer tools and more robust processing capabilities, will extend the life of these systems well into the future.

4 Pages