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.
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:
This approach has a number of disadvantages:
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?
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.
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.
The application can now be built or configured to use the secure data access points made available to the existing data.
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.
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.
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.
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.
There are many advantages to this evolutionary approach:
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.