IT Strategy on Ulitzer

As organizations modernize to meet computing demands, they face enormous challenges when it comes the topic of retiring old applications. Consigning old applications to the backburner in favor of newer, safer, more stable, and more user-friendly systems is never as easy as it sounds. Most CIOs and tech department heads share this challenge – and the problem is more pronounced when the confines of regulatory, budget, and time requirements are taken into consideration.

Due to the tricky nature of retiring legacy systems, managing the retirement of these systems must be completed in stages, and not by adopting an overly simplistic unplug-and-play approach. So how should a legacy application retirement project proceed? While there are in fact no hard and fast rules, here are some general tips for you:

1) Consider why you are retiring an application in the first place. While it is easy to "say" that retiring an existing legacy application is necessary, nearly every move on the "tech side of things" has a corresponding cost in terms of time, money, knowledge, and people. Perhaps some of the items that an organization should consider include: whether vendor support for the application has discontinued, how the solution manages data, how difficult it is to customize the solution, and whether users experience problems with the application. Regulatory requirements and maintenance costs should also be considered.

2) Review the application and the business data that will be retired. Obtain an intimate understanding of the application's functions within the organization – along with its features, and most importantly, the data that the application manages. You should also identify the application's user base, the nature of access, and any related systems that will be affected when the application ceases to be in use. Will there be a need to consolidate related applications? What licenses should be discontinued? What networking and hardware resources should be put in place or cut off altogether?

3) Have a plan for retired data. Government and security regulations require that legacy data be held for certain periods of time. Thus, just because people will not use an application, does not necessarily mean that the people will stop using the data that the application holds. That said, it is wise to plan out how employees and other stakeholders will access the old data - by identifying data storage locations, accessing systems and policies, and creating a retention period.

4) Consider the learning curve. The transition period between old and new systems is the best time to orient staff, business partners, and other stakeholders about the replacement applications. How soon they learn how to use the new application could very well affect the schedule for implementing the new system and disconnecting the old one. This time period is also an excellent time to figure out end-user's problem spots - as well as to determine the new application's weaknesses before the new application is in place.

5) Consider the cost. Like all projects, retiring legacy applications must be completed within a set schedule and budget. As you initiate the application retirement project, consider trimming down the budget by scheduling a cut-off for support licensing and vendor maintenance for legacy systems.

• Seagull Software Unveils LegaSuite Transformation Methodology(TM) for Service-Enabling Legacy Applications
• ZANTAZ(R) Named Top Five Provider in Socha-Gelbmann 2005 Electronic Discovery Survey
• Axis-izing Legacy Applications