Only 30% of digital transformations are successful, yet, cloud spend is growing 20% annually. Why are organizations chasing what looks like a high-risk gamble?
The benefits of cloud adoption are undeniable, providing potential cost reductions, flexibility, scalability, and access to innovative technologies. For many organizations the choice is out of necessity, to meet compliance, be competitive or access new services that enable market disruption. How do you improve a 30% success rate and have your cloud projects be high-return investments?
Table of Contents:
- Choose a Cloud Adoption Framework
- Retire
- Retain
- Rehost and Relocate
- Repurchase
- Replatform
- Refactor
- Your Cloud Migration Decision
Start with a Cloud Adoption Framework
No need to start from scratch. All cloud platforms publish well-defined migration frameworks.
- Amazon Web Services: AWS Cloud Adoption Framework
- Google: Google Cloud Adoption Framework
- IBM: Cloud Adoption and Transformation Framework
- Microsoft: Cloud Adoption Framework for Azure
These frameworks help form your strategy and ensure key perspectives are considered in decision-making. They are not step-by-step instructions you blindly follow for guaranteed results. Your cloud journey is unique to you, influenced by your starting point, constraints, skillsets, and objectives.
A crucial first step is gathering information on your infrastructure, applications, and storage, and evaluating against the 7 migration strategies known as the 7Rs. This helps determine your readiness to develop a migration roadmap.
Migration Choice is a Micro Decision with Reaching Impacts
Plenty of blogs define the 7Rs and their usage. Many present as if you are moving a single application in isolation. Cloud migration is a journey with multiple steps, performed sequentially or together if practical, while continually reassessing strategy, trade-offs, and impacts.
Even if your plan is to move a single application to the cloud, your choice on migration will influence future decisions and options. Let’s examine by reviewing each migration strategy and cover some key considerations.
Retire
Retire applications you no longer need and plan to decommission. After identifying applications for retirement, you should broadcast this information to everyone. Why?
• It can remove networking and code requirements for integrated components on applications being migrated
• It may simplify architecture decisions if the application had unique requirements
• It can reduce your data footprint if building a centralized data store
• It can indicate disinvestment in a particular technology and skillset, that could influence strategic decisions
The date you plan to retire an application can also influence the migration order of others. For example, the effort to migrate one application may be reduced significantly when other dependent applications retire.
Retain
Applications you plan to keep in their current environment for the foreseeable future. Common examples include legacy applications with little justification to migrate.
Like the retirement case, broadcast this information to everyone! Why? It will bring attention to networking, latency, and security requirements with integrated components. You want to avoid discovering a dependency post-migration that destroys your expected performance or scalability benefit.
You also want to revisit your retain decisions frequently, particularly after adding new cloud capabilities. Coupled with the high-frequency cloud platforms are adding new services, there is strong justification to recheck whether the cost-benefit balance has shifted to a new outcome.
Rehost and Relocate (Lift and Shift)
Move infrastructure or applications to the cloud without making any changes. A common approach is to move from an on-premises server to a virtual machine in the cloud.
Why choose rehost and relocate?
- Cheap and fast path to get the application into the cloud
- Realize immediate benefits of cloud compute, scalability, resiliency, and integration with cloud services
What are the implications? Ask these questions as a starting point.
- Does the decision impact your future cloud technology choices?
For example, if you rehost Oracle to the cloud, do we continue using Oracle for net new cloud databases or a cloud platform native option? - What are your costs to maintain the application? Rehosting to the cloud does not eliminate maintenance demands.
- What do you give up by not going cloud native? Does it make sense for you to build the service now if you have plans to use it with future projects?
- Can you maintain security and compliance? The cloud has services to address these requirements. After lifting and shifting, can your application use them? If there are limitations, does it create vulnerabilities that will require a custom fix?
- Examining future migrations, should you revisit the decision down the road? For example: Another migration will enable capabilities that justify a change in approach.
Repurchase
Switch to a new product. Use the opportunity to drop an existing product (or a custom application) and purchase a SaaS model offering.
No two products are identical in their capabilities. Reality is closer to:
When using the repurchase strategy, you could examine:
- How much can you customize the product? This is important if you are moving away from a custom application where you had full change control. Is the product’s flexibility going to match your desired expectations after adoption?
- How easy can you replace or remove the new product? Having an estimate to replace the product with native cloud services provides you options at hand. Cloud platforms are constantly evolving. Like the retain case, revisit the estimate after adding new cloud capabilities to re-evaluate the product decision.
- Does the new solution allow you to remove scope from future migrations, by shifting the functionality to the product? Does it require building net new abilities in other applications for lost functionality? In both cases, it can influence the scope of other migrations and potentially change the migration order of other applications.
- How does the product integrate with both your cloud and on-premises investments? An expected outcome with cloud is unlocking capabilities that are shared across the organization. It is counter intuitive to make a new investment, which requires unnatural integration feats to function within your ecosystem. Technology decisions must be supported by clear integration and compatibility requirements.
Replatform (lift and reshape)
Move an application to the cloud and introduce modest revisions to take advantage of cloud capabilities. Example: Migrate your on-premises database to Amazon Relational Database Service (Amazon RDS) in AWS Cloud.
Compared to Rehost and Relocate, this option is a step up in effort and involves greater cloud-enabling customization. When making this decision, you should ask the same questions listed in that section.
- How does it impact your future technology decisions?
- What’s your tradeoff of not going cloud native?
- What’s your cost to maintain?
Refactor
Rebuild the application using cloud-native designs and technologies. This can be the costliest option, but with the greatest potential of optimizing your investment.
Some attributes that make an application a good refactor candidate:
- Services business-critical functionality with expected longevity. If making the investment, you want to maximize the application lifetime.
- Operational inefficiencies exist. There are opportunities to redesign for improved efficiency and automation.
- Scalability, resiliency, and performance concerns. Your usage is expected to grow significantly over the application lifetime or requires a flexible environment and design to support volatility in resource demands.
When refactoring for cloud adoption, you will naturally unlock new capabilities you can scale and manage. Each investment should be considered an opportunity to support other applications and use cases in your organization.
For example: refactoring results in the deployment of a cloud-based streaming service. The service can scale based on throughput, comes with granular access control, and uses automated redundancy to create resilience. You now have the potential to provide further value by shifting all event handling functionality and ultimately all event-based applications.
With appropriate planning, refactoring steps, while costly, can have a transformative impact on your overall migration initiative.
Your Cloud Migration Decision
In typical projects, you make broad decisions upfront, and as the project proceeds, your decisions become granular. In contrast, the dynamic nature of cloud adoption makes migration to the cloud a different type of undertaking.
In a cloud project, you will likely need to
• migrate one or more applications,
• contribute to an integration solution space (supporting multiple departments) and
• implement on a platform with constantly evolving and/or new services, all at the same time. No wonder only 30% succeed!
You can overcome the odds by embracing the dynamics, revisiting past decisions with discoveries, and forming an adoption strategy appropriate for your cloud journey. Remember, like cloud platforms continually evolving, so does your strategy, with purposeful decision making, re-assessment and discovery.
You can overcome the pitfalls that have challenged so many others with a practical approach that involves thinking holistically, migrating incrementally, and recognizing that different strategies can be optimized for different application components. Each step in your journey provides the opportunity to build upon your past investments, invest to support the future, and adjust the course of your overall strategy.
If you want to discuss further the challenges and surprises of cloud migration, you can reach me on LinkedIn or by email.
If your organization is looking for help on getting started (or tried and are now dealing with constant fire drills), don’t hesitate to reach out and grab 30 minutes. I enjoy the opportunity to be a sounding board, collaborate and learn more about your experience or upcoming challenge.
2630 Bristol Cir #100 Oakville, On L6H 6Z7
+