The term cloud migration has been gaining traction for years now. But in order to chart out a robust cloud migration strategy for a successful cloud journey, an organization needs to understand the driving factors and the various strategic steps that the process entails. With this blog post, we shall explore the possible pain points a legacy organization may endure while shifting to the cloud.
Any cloud journey starts with two key factors– efficiency and agility. Efficiency ensures that an organization optimally utilizes its resources and infrastructure for the maximum output. On the other hand, agility is correlated with the ability of an organization to adapt to the fast-changing needs of the market, or the time. A successful cloud transition would focus on these two factors and bring about a slew of changes in and around the organizational ecosystem such as-
- Updating application portfolios
- Simplifying operating environments
- Reducing overall costs of ownership with smart strategies
- Reducing footprint of applications
- Increasing accountability for managed services (reduced hand-off points)
- Improving operational efficiency
- Achieving future business capabilities in an easier and quicker manner
The following are the most important steps for an enterprise to consider while formulating a cloud migration strategy and advancing toward a connected cloud structure:
Bringing key stakeholders together to formulate the strategy for connected cloud
A simple but very important first step is to ensure that each of the below roles is involved in the decision-making process:
All these roles play a crucial part in defining the roadmap for the migration of applications.
- Enterprise Architect: Layout the future of applications aligning to enterprise roadmap.
- Cloud SME: Ensure the vendor is involved right from the beginning.
- Enterprise Portfolio SMEs: Extremely important to have their inputs and buy-ins to ensure Cloud roadmap is aligned to portfolio roadmap.
- Enterprise Security Team: Framework should be defined upfront to ensure all the compliance and security standards are being considered.
Proper due diligence and fitment analysis of the target cloud platforms
- Some of the applications, portfolios, or technologies which are on .net and others which are on Java may have to be shifted to different cloud platforms (Azure and AWS as examples).
- A pilot should always be conducted to determine the best approach to target a cloud platform.
Defining the guiding principles for cloud migration very clearly
- It’s extremely important to lay out the guiding principles before starting on detailed analysis of applications, platform architecture, and design.
- Below are some of the key considerations for enterprises contemplating cloud migration:
Defining the selection criteria for the candidate applications in the pilot and the criteria to logically group them into Release Tranches for the future
- In addition to the technical details, it’s important to select a mix of “business-critical” and “less critical applications” for the pilot to be able to show some quick wins as well as get an indication of the complexity of migration for the critical applications.
Key solution consideration: Resilience of the entire ecosystem is important
- At this stage, two things should be defined– the architecture and design of the cloud platforms and how the connectivity from cloud to on-premises systems will be established.
- Resilience is one of the key expectations for any migration project. In addition to the design of the candidate applications to be resilient in the target state, it’s also important to consider all the surrounding aspects of the application. This can also be termed as “ecosystem resilience”.
Right cloud governance and structures for analysis (with the incumbent vendor)
- It is important to follow the cloud governance and team established during the inception phase to the next stages of execution.
- Next is extending the team to the analysis phase and finding the right treatment plans.
- And setting the analysis team outside the team which is not working on actual migration.
- If the number of applications are high, the analysis needs to be broken into two parts i.e. pre-analysis and detailed analysis.
- Pre-analysis should help in creating the program and migration plan along with releases.
- Detailed analysis should be used to crystallize the treatment plan and migration plan.
- The responsibilities of the architecture squad need to be mapped.
Right governance and structures for analysis (with a new vendor)
- This is not an easy situation to be in and without understanding the complete landscape of applications and dependencies in-depth, planning the migration is a recipe for disaster.
- It is important to have two phases of analysis since the knowledge of the landscape is not with the new vendor.
- It is important to have automation tools as per the need of the landscape and do the pre-analysis work.
- A second and deeper level of analysis can be done while formulating the treatment plan for the applications.
- The right escalation path should be in place to avoid longer times and delays in getting clarifications.
Evolving strategy makes more sense and it’s better to learn from ongoing analysis and design
- It is important to have the feedback mechanism from execution team back to the architecture team to ensure learnings of execution are being fed to the enterprise cloud Strategy.
- Patterns will emerge with more analysis-data being fed back to the architecture strategy team.
- Adding the patterns based on types of applications and treatment plans is imperative. Also, there should be no restriction to high-level treatments such as “life-and-shift”, “re-architect”.
- E.g. Extend the high-level patterns further into technology type and target cloud
- Pattern 1: Re-architect a Java application with integration points into AWS IaaS
- Pattern 2: List-and-Shift a .net application with no integration points into AWS IaaS
Scaling teams for cloud migration
With the right governance and structures in place, it’s possible to scale the team for migration to cloud. The following governance and structures should be followed holistically
- Architecture Squad: Responsible for strategy, architecture, design, and analysis
- Platform Squad: Setup environments and platform engineering aspects
- Program Governance: Program directors, managers, and sponsors
- Execution Squads: To scale up the migration and have multiple applications being migrated in parallel
Defining the success criteria
It’s important to ensure that success criteria are thoroughly communicated to the stakeholders along with information regarding the measurement of the criteria:
What to measure
How to measure
Mean time to analyze
Mean time to place an application into the “pipeline candidates” queue for migration should be standardized first and then optimized.
Design and build
Mean time to build and release
Mean time to put an application into production (post the analysis phase) for any specific pattern should be standardized first and then optimized.
Cost to migrate
Cost per application for a type of pattern
Cost should be standardized for the specific pattern.
Before and after migration
Based on the pattern and specific NFRs captured, migrated application should behave accordingly in the target state.
By default, like-for-like NFRs will be the expectation.
A comprehensive migration strategy based on these points would beget a successful cloud transition for an enterprise. It would serve organizations well to partner with an experienced vendor who can walk them through the onerous and elaborate stages with diligence and perfection that ensures that the enterprise can take a firm and assured step into the cloud-enabled future.