We argue that choosing the best strategy for your legacy modernization initiative is primarily a business question, not a technical question, except insofar as technology directly impacts the business. Just like any other investment decision, legacy modernization issues can be categorized under assets, liabilities, cost, risk and business value. Furthermore, there is no single path from where you are to where you want to go, if indeed you have identified your destination platform.  Instead, there are often multiple alternative paths, and no single alternative may constitute the obvious choice.  Each path will have advantages and disadvantages, and each must be weighed appropriately in the context of your unique organization. There is no one-size-fits-all answer.

The most typical destination platforms are:

• Java in a J2EE environment, frequently with Websphere as an application server
• C# in a .NET environment

Both will usually include a relational database management system (RDBMS) as the primary data store, but in some cases an object database may make more sense.

However, these are hardly the only destinations. Open source alternatives to proprietary environments are becoming robust enough to constitute significant competition for proprietary vendors, though the majority of sites stick with proprietary products for mission critical applications. Rules engines, or business rule management systems (BRMS) as they prefer to be known, are gaining traction in application architectures. Business Process Management (BPM) platforms can have an adjunct or a primary role as well.

Large mainframe sites are often times not ready to abandon the security of the mainframe for newer architectures, and are running mixed CICS/COBOL and Java/Websphere environments, either on z/OS with zAAP processors for Java or on z/Linux using inexpensive IFL engines. The substantial economic advantages of using these specialized processors, with CPU & software costs a tiny fraction of general purpose CPU & software costs, is not always fully understood by staff who focus on technical issues.

Our legacy modernization consulting services are designed to help you frame your decision on future architectures, and provide you with clear, business based parameters for deciding on the best path to transition from where you are now to your chosen destination.  Many times, vendor products and vendor services can ease that transition, but in other cases a site is perfectly capable of doing the job internally.

This essay on methodology focuses on how we derive the decision parameters for the transition. There is usually not a big decision regarding in-house versus outside vendor services. Most (but hardly all) sites that are not under a deadline would prefer to do the job themselves, perhaps with some judicious assistance or tooling where appropriate. Others would prefer to outsource the learning curve and the project risk.

When we discuss costs of each alternative transition strategy, we utilize the preferred approach, whether it be in-house, outsourced, or mixed. On request, we can cost both approaches to the same transition strategy, given fully burdened cost information and productivity information on in-house resources. Although the methodology discussion following assumes that all alternatives will be evaluated, if any path can be eliminated a priori (e.g., there are no candidate COTS packages), then that step in the methodology is bypassed.