Cloud and Your Core Systems White Paper

Introduction

Migrating applications to the cloud offers many advantages to organizations including an ability to pay for hardware and software as you use it and providing an ability to ramp up resources for high demand periods while reducing resources required when demand is low. This provides the nirvana in that the organization is only paying for what they need, when they need it. To the delight of the CFOs (and the rest of management) this becomes Operational Expenditure (OpEx) as against Capital Expenditure (CapEx).

While some IT suppliers give the impression that moving an application from an on premise implementation to the Cloud can be done at the ‘push of a button’, this is far from the truth. There have been many failed Cloud migration projects. This document discusses how using an evolutionary Cloud migration strategy (sometimes known as a hybrid Cloud strategy) can eliminate much of the risk that is associated with using a revolutionary Cloud migration strategy.

Revolutionary Cloud Migration

The revolutionary approach is where a full replacement of an on premise application is planned and the intention is to roll it out as a complete replacement for the existing system. There are a number of issues to deal with including:

• Legacy systems written in COBOL or other older languages will rarely, if ever, transfer directly to the Cloud.
• Many applications have inter-dependencies on other applications which cannot be supported by simply moving one application to the Cloud while leaving another on premise.
• Often it is difficult to understand existing functionality and transfer directly to an application in a new language.
• If there are many users of the existing system, training and moving staff to the new Cloud application in one bold move is a massive challenge.

Disadvantages to the Revolutionary Approach

This approach has a number of disadvantages:

• It represents a ‘big bang’ approach where one day a new system is turned on and an old one is turned off. Experience has taught the industry that this should be avoided at all costs.
• It requires that staff is trained in advance and all required to move to the new system on the same day.
• It is often difficult, even impossible to properly test for the full load of a total switch of personnel from the older system to the new system.
• If application interdependencies have been missed, it is only clear after the switch that other applications are no longer functioning correctly. It is better that this is found early as the longer things go before a problem is detected, the larger the problem and the more difficult the recovery.
• All new systems have teething problems no matter how well planned and tested before use. The big bang approach leads to a more intense and pressurised environment to get these resolved as it becomes business critical.

After all the industry has learned over the last number of years, wouldn’t you expect organizations to avoid all of the above if it were possible?

An evolutionary Cloud Migration Approach

Using an evolutionary approach, it’s possible to reduce risk and move forward in a more controlled and planned way allowing for potential problems at each stage. The following proposes just how such an evolutionary approach could be implemented.

Phase 1 – Make the data available securely

Access to the existing data should first be made available securely to the Cloud instance where development of the new application will take place. Sharing the application data as a starting point ensures that development can occur in parallel to the running system and use test or masked production data from your existing system.

Phase 2 – Build/Configure the Cloud Application

The application can now be built or configured to use the secure data access points made available to the existing data.

Phase 3 – Deploy and Test the Cloud Application

The new application can be deployed and tested against the existing dataset in parallel to ongoing testing of the existing application. This will determine quickly if the new application is causing issues with the existing application.

Phase 4 – Migrate users to the Cloud Application

Once the first version of new application has been completed and tested, an initial controlled release can be made available to a limited number of production users. This allows for the correction of teething problems with limited pressure simply because there are a small number of users who can easily revert back to the original application if necessary. Remember the majority of the users will continue using the existing application at this point.

There may follow a number of releases of the new Cloud application until the project is satisfied that the teething problems have been resolved and the application is ready for the ‘big time’. At this point, users can be moved across using a phased approach through a ‘train and move’ effort based on a plan that ensures the continued, efficient operation of the business.

Phase 5 – Decommission the original application

Eventually, all users will be moved to the new Cloud based application which can facilitated the decommissioning of the older application. Note that the Cloud application will continue to use the existing data so this involves simply ensuring the old application code is retired.

Phase 6 – Optionally move the data to the Cloud

Many organizations are quite happy with this ‘hybrid’ approach where their data continues to reside on premise and the application runs in the Cloud. There are advantages to this as procedures around the data for backup and recovery are likely to have been built up and perfected over many years. If there is a desire to move the data to the Cloud, this can then be achieved as a final step to ensure the complete migration of the application to the Cloud. Sometimes this is desired so that the on premised data centre can be decommissioned.

Advantages to the evolutionary approach

There are many advantages to this evolutionary approach:

• At each step, it’s possible to review and revise plans based on what is learned from the completed step.
• No ‘big bang’ approach is required thus removing risk and ensuring problems can be addressed in a calm and orderly fashion.
• Staff can be trained in the new system on an ad hoc basis that suits the business as both old and new applications can run in parallel for as long as necessary.
• Planning for full load becomes a lot simpler as users are added to the new application, patterns can be measured to determine what total capacity will be required based on the performance of the system.
• Application dependencies will be detected at a much earlier stage and, in many cases, are based around shared datasets thus if the data remains on premise, this removes this issue entirely.
• Teething problems in the new application can be found and addressed with a small subset of users thus ensuring less pressure and that the system is fit for purpose prior to the majority of users moving across to the new application.
• This approach is far more comfortable for many organizations who, as yet, do not trust the Cloud with their data. With this hybrid approach, they can benefit fully from the Cloud while ensuring their data is adequately protected and secure.

How can Ostia help?

Ostia have many years of experience with core IT systems and understand their strengths and weaknesses. We have also had much experience with traditional integration stacks and the models that have built up around them but now offer an ability to provide adaptive integration solutions in the timeframe required for agile projects. Ostia are able to do this because of their Portus data integration technology they have developed over the last 10 years. It has taken 10 years for Ostia to get to the front of today’s technology. We can help you stay there.