A cloud migration project can be a relatively simple exercise, where a single applications is migrated ‘as is’, to gain benefits such as elastic capacity and utility pricing, but without making any changes to the application architecture or business model.
Or it can act as the catalyst for a wholesale digital transformation, where an entire estate of applications are not only migrated, but also re-architected to support an entirely new digital business model.
Planning Cloud Migration
Therefore the first step of a Cloud Migration project is to determine what scope of exercise is needed.
As the ADM ‘Horseshoe’ model articulates, as described in this Carnegie Mellon article, a migration project can be considered with three distinct tiers of scope possible, increasing the size and length of the project with an increasing level of associated business benefit.
1. Technical architecture – The application is migrated as is to a new hardware infrastructure service without modification.
This delivers infrastructure-centric cost and performance benefits, such as autoscaling of capacity and utility pricing, addressing specific pain point scenarios, such as utilizing IaaS for disaster recovery, with the business case being the move off of obsolete hardware.
2. Application and Data Architecture – The application and data structures are also upgraded as part of the process.
This can enable the software development team to adopt Enterprise DevOps methods, achieving faster time-to-market for new innovations that wasn’t possible with the previous legacy software. The software can be re-architected from hard to modify monolithic software to change-friendly designs such as Microservices, and achieve a more integrated state that better utilizes shared services like Digital Identity sign-on and key modern features, like web front-end access.
3. Business Architecture – The business model is also transformed. The new software capabilities can then make possible new digital business models, changing how the pattern of how resources are organized to deliver new services.
Moving to Cloud can actually represent activity on all three fronts:
- (T) Virtualizing the platform to simply improve the underlying hardware usage. This begins at a technical migration, meaning the application is migrated ‘as is’ to a new hardware infrastructure service without modification.
- (A) Application Modernization, from simple re-writes to make use of native Cloud services such as AWS auto-scaling, through to wholesale transformation, such as converting COBOL code to Java. It can even enable a shift from a procedural software development method to an object oriented one.
- (B) Business model transformation – Changing business processes to a new operating model that best exploits these new capabilities.
As the horseshoe describes, these increases in scope mean a larger project that takes longer, because each is delivering a larger scope of business benefits, impacting a larger group of stakeholders and requiring a larger business transformation exercise, such as:
Legacy modernization best practices can address these issues, delivering business benefits including:
- Untangle and map legacy application complexities – Build a basis of understanding of existing application and data architectures to establish more intelligent IT planning concepts in line with business and technical demands. Developers with no experience of the legacy software can be enabled to implement changes in line with business needs.
- Extend the life of legacy applications without the risks of greenfield COTS projects – Numerous reports highlight how a COTS (Commercial Off The Shelf) approach to modernization is very high risk with expensive failure rates.
- Align user interfaces and back-end application and data models with modern business processes – Modernization can be used to achieve IT objectives such as SOA, Cloud migration and Web-enablement of applications.
- Leverage new technologies and tools – The overarching benefit is the transformation of software that is now resistant to change and thus innovation, as the required skills have long since retired and/or the suppliers are no longer in business. By moving it to a modern software platform new tools and techniques like ‘DevOps’ can be implemented to speed the rates of innovation.
Cloud Adoption Framework
- Rehost – Often referred to as “lift and shift” migration, this no-code option lets you migrate your existing applications to Azure quickly. Each application is migrated as is, which provides the benefits of the cloud without the risks or costs of making code changes.
- Refactor – Often referred to as repackage, this cloud migration strategy involves some change to the application design but no wholesale changes to the application code.
- Rearchitect – Modify or extend your application’s code base to scale and optimise it for the cloud.
- Rebuild – Rebuild an application from scratch using cloud-native technologies.
Determining whether to migrate to IaaS (“lift and shift”) or PaaS highlights the value of the first Digital Transformation planning process, to identify whether the benefits sought are purely related to the replacement of server hardware, or if transformation of software development and business process are also key goals.