CIOs in financial services series 5

Application platform migrations have increasingly become a common phenomenon in IT over the past few years. Changing large back-office applications, such as an administration system, has a significant impact on the internal organisation and all its stakeholders.

Staff, clients, finances, strategy, business processes and operating models are all affected by a large scale migration and, as a result, application migrations are high-risk projects and remain near the top of the list of spectacular IT project failures. Considering this, there remains surprisingly little literature, methodologies, courses and training available on how to run an application migration successfully.

While each migration will have its unique challenges, it is worth highlighting some of the most common problem areas that CIOs should be aware of and prepared for:

* Expectation management: The most common cause of project failure is the significant underestimation of the impact of a large-scale migration on the entire organisation. The business case is often done by people who not only have limited experience in platform migrations, but who are also unhappy with the current system. This combination of factors heightens the urgency for the migration to take place, which is followed by a project plan that commits to unrealistic deadlines, and a project that is under-resourced and under-skilled. A pressured start ensues.

* Poor business case: The business case often expects a new system to provide the solution to problems that are not exclusively technology system problems. Ineffective management, poor staff performance, badly designed processes and poor data input are a few examples of the reasons for poor system output/results. By not considering these additional influences, certain of the benefits attributed to the system migration are over-stated, especially as far as efficiency improvements are concerned.

* Opportunity cost: Migrations are seldom transformational in impact, yet absorb management and staff attention for months on end, effectively stagnating innovation over that period. The business case needs to reflect the impact a migration will have on the organisation's ability to re-invent itself during the migration period.

* Insufficient evaluation of alternatives: It is important to be very clear as to why the migration is required. Is it to reduce the costs of maintaining expensive legacy systems, to rationalise multiple legacy systems onto a single platform, to enable a new product or service, or to introduce efficiencies and streamline the business? When the reasons are clear, alternatives to platform migration need to be fully explored before concluding that an approach of 'out with the old, in with the new' is required, as there may well be lower impact solutions available that achieve the desired outcome.

* Staff attrition: The perceived performance failure of key staff members often caused by unrealistic initial deadlines, results in poor staff morale and ultimately staff attrition. Time will also need to be factored into the project to cater for the learning curves of newly appointed staff. Staff typically start working long hours for extended periods to 'rescue' the project, already perceived as a failure by the business. Staff morale plummets and burnout can easily occur and the downward spiral continues, often with highly paid and experienced consultants being brought in to save the migration project, adding to the cost pressure of the overall project. When even they cannot manage the steep learning curves and unrealistic deadlines, the project is either abandoned, or implemented prematurely under high-risk conditions.

* The “iceberg” effect - the application being migrated is really the only “visible” part of the migration work - but in reality it is the tip of the iceberg - underpinned by a substantial technology platform. The application is linked to many other aspects of the organisation that will also need to undergo significant changes during the migration, and sometimes at great cost to the business. These could include issues such as:

* The investment in processes, training and knowledge of staff with regard to the current application;
* Integration, where the impact on related systems is underestimated;
* Systems interdependence issues, like the impact on the full technology stack;
* And even client or other stakeholder issues, where clients are trained and comfortable with the current method of operating, and a change is now being imposed on them.

* The implementation methodology - with the lack of industry standards in migration methodologies, migrations are often tackled with no methodology, or an inappropriate methodology such as a standard SLDC methodology. This becomes a problem as the nature of an application migration requires a different approach from a standard project development in a number of key areas.

Given the complex challenges that need to be overcome, here are some suggestions worth considering when tackling a large-scale application migration:

* Ensure that the business driver is clear, and that all alternatives have been fully evaluated before making the final decision to migrate to a new application platform. For example, if the driver is purely cost, or to manage risks associated with an old technology, then consider migrating the underlying technologies, rather than the full application platform. If the driver is to accommodate a change in architecture strategy, consider “wrapping” the legacy platform with SOA architecture, and then building additional functionality on the SOA architecture.
* Ensure that the migration opportunity cost, and the potential impact on business innovation, is explicit in the business plan.
* Don't embark on the project without senior members of the migration management team or advisors who have experienced similar migration projects.
* Be ultra conservative with any timing and cost estimates, to minimise expectation gaps and maximise the potential success of the project.
* Ensure that business management is made aware of the extended organisational impacts throughout the migration period, so that there are fewer surprises when problems are encountered.
* Understand that the migration will absorb the majority of management focus for an extended period, so don't commit to other large-scale business or IT projects in parallel.
* Work according to a test-driven implementation methodology, which involves all stakeholders impacted by the migration. The approach should be designed to identify the challenges and problems at the outset of the project life cycle. Phase the implementation if at all possible, and if not possible, ensure that the parallel testing effort is of sufficient quality to manage the big-bang implementation risk.
* Pay close attention to basic implementation disciplines, such as; scalability testing, parallel testing, backlog management, migration data quality, staff training and risk management.
* Like any large project, there will be pressure to deliver. The sponsor and project management team need to manage the pressure that the staff will experience, to avoid staff burnout. Treat the project as a marathon, not a sprint.

Many of these suggestions are basic implementation disciplines, which are often understood in theory by the decision-makers. Yet many application platform migrations remain less than successful. These words of wisdom should be carefully considered:

“In theory, theory and practice are the same, but in practice, they are not”.