2) How to derive the most value?

There was a classic comment on the Windows XP migration blog, “If you are thinking about moving your enterprise off Windows XP NOW- you are already too late.” This was April 2013 when there was a year still left for MS to support XP.

Very often, licensing agreements run till the end of the calendar year which coincides with the reporting and real-time information needs of the business. If the operations or technology people cannot guarantee the up-time of the warehouse and the relevance of its data, the business folks cannot depend on its predictive analysis and risk assessment of marketing or sales strategies.

Timing your migration with a view and in cooperation with the business team is critical to ensuring the success of your migration.

Moving from one ETL platform to another is a time-consuming process that needs thorough planning and execution. At Bitwise, some of the critical migrations we have been involved with have ranged from 18 man-months to 240 man-months. What can help reduce the effort is building platform reassessment into the life cycles of the applications using the tools and planning moving across vendors based on these reassessments.

Adding value by cutting costs (and not corners) is the way forward for today’s lean enterprises. This is challenging the set paradigms for design and architecture to offer solutions that don’t necessarily reinvent the wheel – but do away with it altogether.

It is forcing stakeholders like analysts, modelers, and design and development teams to leave the silos they work in and come up with an integrated approach. Like the separation of critical business SLAs on proprietary products and leaving non-critical functions on open source. The integration of the two then takes on its own criticality and needs to be treated with the same respect the SLA-linked business functions get.

3) How Do I Curb My Costs?

Before jumping on any new platform it is essential to run a scaled-down version of your enterprise application in a Proof of Concept.

Furthermore, it would be a good idea to break down the application into segments that need to be migrated vs. elements that can easily or seamlessly be ported over to the new platform. Scripts that are used by the Enterprise-authorized batch scheduler and XML Metadata that can be parsed to generate Source to Target mappings are a few of the examples of elements that are easily ported. However, custom scripts that are specific to administration or managing the execution of the product in your environment do not port easily and are better redone from scratch.

Metadata management and Data Lineage tracking is a key elements of any enterprise Data Integration/ETL solution and the most appropriate platform for your enterprise should be including this as a focused offering. Besides the help it provides the Analysts, having effective data lineage in place reduces the time required for setting up test data for the migration team.

As is with every critical system, budget for extensive testing and data validation while also allowing parallel execution of the old and the new systems with the same input data sets for Production validation.

To efficiently get this done, it may be a good idea to seek out tools/services that can automate such migration and associated testing from source to The target platform. Having a data validation suite in place that can be used by both the migration team as well as the end business users helps reduce turnaround time for the UAT.This would save the efforts of manual conversion and bring in efficiencies both from a cost and Time-to-market perspectives. Bitwise’s ETL Converter is a good candidate for such an automated migration service offering which can serve as your starting point.

And, with a view of assessing the platform you are migrating to in a couple of years down the line, ensure the thought process behind a particular course of action is as well documented as the action itself.

People are scarce

People that know the legacy languages are becoming difficult to find and retain. Younger staff are reluctant to learn “legacy” languages because it does not appear to advance their long-term career.

The underlying platform is hard to support

Many legacy systems run on legacy hardware systems. Such hardware systems are becoming more expensive to maintain, and personnel that know these systems are also more difficult to find.

Legacy software does not integrate well with other IT systems

The architecture of legacy languages often does not lend itself to building bridges to other IT systems that have grown up around it.

Challenges

Migrating large software applications needs automation. The need to migrate mainframe software is often motivated by a mixture of motives including:

• The high cost of operating the mainframe
• The shrinking pool of IT personnel that understand the mainframe system languages and structure
• Need for faster application evolution in response to changing requirements by use of more modern software engineering methods
• The need to integrate the application and its data more effectively with the balance of the organization

Yet most of the legacy software performs an extremely valuable function that must not be disturbed by a migration. Hand-migrating large applications by re-coding from scratch usually causes huge management overheads when the migration team attempts to re-validate the requirements with management. Hand-migrating by translating line for line introduces errors by damaging implicit business rules, and suffers from scope creep. In addition, there is a continual war between the application maintenance staff, which must keep the application running during the migration process, and the migration staff, which does not want to see any change during the lengthy migration process. As a consequence, many manual migrations fail or run significantly over time and cost budgets. Offshore hand-migration suffers the same problems as well as communication and coordination problems.

Strategies/Planning

Many organizations face the problem of having to modernize their existing software systems by migrating to more capable systems. Modernizing legacy software systems is a complex engineering problem that includes most aspects of traditional software development with more constraints. A successful migration effort requires both a sound development plan and a sound migration plan.

A development plan addresses the selection of the appropriate software processes, methods, tools, and hardware and software platforms. A migration plan created in conjunction with the development plan is necessary to help ensure that the operational transition to the new system goes smoothly.

A good migration plan should weigh programmatic and technical drivers for system development against customer priorities. Because of this, the plan may impact system development and certainly should impact system deployment. Iteration among the key stakeholders is necessary for an effective migration effort. Like development, migration planning involves tradeoffs among cost, schedule, risk, and resources.

Legacy system modernization is often a large, multiyear project. Because these legacy systems are often critical in the operations of most enterprises, deploying the modernized system all at once introduces an unacceptable level of operational risk. As a result, legacy systems are typically modernized incrementally. Initially, the system consists completely of legacy code. As each increment is completed, the percentage of legacy code decreases. Eventually, the system is completely modernized. A migration strategy must ensure that the system remains fully functional during the modernization effort.

Making of software modernization decisions is a process within some organizational context. “Real-world” Decision making in business organizations often has to be made based on “bounded rationality”. Besides that there exists multiple (and possibly conflicting) decision criteria, the certainty, completeness, and availability of useful information (as a basis for the decision) is often limited.