The last 10 years has seen a marked change in IT strategy and platform hosting strategy across business sectors as companies have moved to cloud based services. This article provides a simplified view of three different cloud migration paths. At the time of writing this update (Feb 2020) it appears that most businesses have now moved away from on-premises to the cloud and many of these business are now considering further migrations in search of optimisation or performance improvements. Other drivers for migration can be a change in strategy, a merger or an acquisition.
Much has been written about selecting the best strategies as migration is often complex and can appear daunting. By breaking down the project into logical units of work and taking a step-by-step approach, even the most complex migration paths can be simplified and de-risked.
Migration will deliver a good return on the investment.
Below are overviews of three popular cloud migration paths (1) Lift and shift (i.e. purely a re-platform exercise), (2) Re-architect and shift (aka ‘refactor’) and (3) Total redesign and new operating model.
The three biggest players in the hosted services market at the moment Amazon, Microsoft and Google, though there are plenty of other smaller vendors out there providing excellent services that may align more closely to your particular business needs and offering greater flexibility and/or more preferable cost models. Success will come from adopting the migration path and selecting the right hosting partner for your business / application.
Three popular migration paths to choose from:
- Lift and Shift: This involves physically moving all applications and data from one platform to another. The current (as-is) apps and data may be located on legacy architecture either on-premises or hosted by a third party. Target platform is typically an Infrastructure as a Service (IaaS) solution that enables the apps and date to be copied or moved completely onto the new platform with minimal technical changes. Particular attention will be applied to the capacity management and contractual arrangements for auto-scaling depending on load/demand requirements. The business case may be contingent on improved operational costs and will almost certainly rely on some kind of ‘elasticity’ to cater for peak loads. Functionality, features, user experience will all remain the same as the entire application and data set will have been replicated across to the new platform. If the migration is to a Software as a Service (SaaS) vendor then it is unlikely that some degree of refactoring will be required.
- Re-architect and Shift (refactor): Most SaaS vendors will offer a set of unique selling points which can align to specific business and technical requirements such as capacity, elasticity, global reach, out-of-the-box user features and code generators. Re-architecting or refactoring will involve significant development. Either some or all of the existing functionality may be replicated on the new platform and may be augmented by making use of the services, features and functions provided by the new SaaS platform. Migration project activities will include development, application integration, data cleansing and migration, code optimisation and lots of testing.
- Total Redesign and new Operating Model: The content, data and various feature-sets will be moved to a completely new application tier . There will be a new user experience, for customers and business/operational users and technical staff. In this scenario, the online service is being changed and moved to either a completely new build or a pre-existing product or application stack (such as AWS). User experience improvements and technical changes will be supported by varying degrees of operational and business change to support the way the online product or service is delivered, supported and maintained. This could be part of a wider business change (for example an acquisition or new line of business) or a digital transformation (eg; customer insight /big data programmes, multi-channel to omni-channel programmes, customer self service / call-centre optimisation programmes, etc ).
Using cloud-based services reduces project ramp-up times and initial deployment costs, mitigating much of the risk associated with the early project stages using on-premise infrastructure. IaaS (Infrastructure as a Service) also delivers scaleability, enabling the business to increase (or decrease) infrastructure capacity inline with fluctuations in demands. Cloud-based services are great for agile delivery projects, encouraging early test-and-learn cycles and delivery of minimum viable products in short timeframes. The financial model for cloud-based services s completely different from on-premise solutions as the supplier will recover the infrastructure costs through on-going service charges. So the business case for cloud-based services may see a long-tail of heavier operational costs
The two most significant benefits of deploying into the cloud on project I have been responsible for have been:
- Risk reduction (on the technical delivery)
- Development time reduction
Translation to business benefits: The reduction in lead-times to launch a new product or service enables the business to recognise an early confirmation of the predicted benefits-case and ROI. Cloud services have enabled my customers and employers to get to market much quicker with their propositio than alternative on-premise solution options.