Creating A Successful Cloud Migration Strategy

—and Leading at Scale

7 min readJun 12, 2023

Businesses embark on a cloud journey for various reasons, including competitive advantage, speed, access to modern technologies, and reduced CapEx. While the technical transformation part of the journey is crucial, there is much more to consider for large-scale successful cloud migration. This article examines the essential components of developing a migration strategy and the approaches that might help businesses avoid errors and setbacks.

Transformational change

Understanding the type of organizational change helps us prepare for more focused execution. For the discussion in this article, we categorize the changes as improvement, transitional, and transformational. When the change improves an existing system, we focus on toolsets. To make a transitional change, such as redesigning or moving to a new system, we must address the tools and the skills involved. When a change is transformational, such as a major system-wide shift to a new operating model, not only do toolsets and skillsets need to be adapted, but there is also a need to focus on shifting the mindset.

Cloud migration is a transformative change that requires a comprehensive and holistic strategy that addresses all three aspects of the shift — toolset, skillset, and mindset — in a balanced and cohesive manner. We will remember this as we outline the core stages -preparation, experimentation, the statement of intent, and execution- involved in the migration and the key aspects that should be reflected in the strategy below.

Phase 1: Preparation

Preparation is the most critical phase for the smooth progress of the subsequent steps. The upfront investment in this phase will reduce potential resets or reluctance to proceed. We might need to return to the stages to address what was missed. The initial exit criteria are high-level awareness and readiness to experiment.

Have a good understanding of the current state of the system. — Create a workload inventory and categorize them based on their active development status, business criticality, level of performance, and stability issues.
Create a draft application rationalization using the inventory and strategic goals of migration. Mark applications to be kept, replaced, retired, or consolidated. This categorization is an ongoing iteration, but having the initial version as early as possible is good.
Enumerate processes and tools. — Determine what is still applicable and what needs to be updated, integrated, or acquired. — Remember the need to change the toolset.
Identify current values, principles, and how work is getting done. — Determine what will be the most disruptive to the day-to-day process. Use this information to manage risk later in the action plan.
Prepare the workforce. — Training, organizational design, aligning leaders, and adapting hiring strategy are essential here. — Remember the need to change the skillset.
Build a migration center of excellence team to guide all technical aspects of the transformation. — This team would lead foundation components, architectural blueprints, and cloud best practices. It can also identify a few product teams likely to be early adopters and partner with those in the early experimentation and execution phases.
Define how cloud transformation plugs seamlessly into the organization’s change management.

Phase 2: Experimentation

This phase is critical to gaining experience, identifying blockers and gaps, and building prototypes to showcase the value of the migration. A few points to take into consideration in this phase are below.

Pick a few workloads that would benefit the migration the most, as identified in the preparation phase. Build prototypes and test them with production-level traffic.
Focus on key business metrics showing clear wins on performance, latency, availability, and TCO.
Communicate the results with key stakeholders such as technical leads and business leaders.
Clearly outline blockers and needs early on. — There will be many of them initially; how we communicate, unblock, and staff will substantially impact the migration’s progress and outcome.
Identify automation needs. — The common tasks and repeated steps will be more obvious after a few migrations. These are great candidates for automation.
Evaluate different technologies. — When using cloud services, teams often must choose alternatives for similar functionality, such as self-managed, managed, or serverless alternatives. Evaluating and creating comparison matrices for these during the experimentation phase can tremendously help during execution.
Try out different migration paths and outline the pros and cons. — When it comes to large-scale migrations, there is no one-size-fits-all solution. Depending on the workload's characteristics, we might rehost, refactor, or replatform. Experimenting with different options for common workload patterns and sharing learnings and trade-offs across diverse dimensions, such as performance, scale, and cost, will be invaluable for executing teams.
Have a plan for cost management and visibility early on. Leverage cloud provider or third-party tooling dashboards to track cost across multiple dimensions. This will help evaluate different options and pivot as needed.

Phase 3: The Statement of Intent

After gaining enough confidence in the technologies and different migration options and identifying and resolving significant blockers, it is time to broaden the audience and communicate the intent for migration. How this communication is done largely depends on the organization and its current dynamics, but some general principles can be outlined as follows.

Create a shared understanding by clarifying the “why.” — A cloud journey with a defined north star, a vision, will likely be better received than one without. The vision artifact will explain the value, the motivation, and the common goal the teams work towards. Have a few clear business metrics driving the change. Help teams understand how the migration will help meet future business goals. A motivating story and a sense of a final destination will bring everyone along in the journey.
Have a technical vision. — In addition to business justification, present a technical vision that paints the final state of the technology stack, including considerations of how the hybrid stack will work. It is a landing zone for teams and all stakeholders to stay informed. Create opportunities for others to contribute to the vision directly. High-level decisions on technologies among alternatives should be documented and backed by analysis and experiments carried out earlier.
Get feedback. — Understand the key stakeholders’ needs and concerns, and be ready to answer questions like “How does this impact me? What support will I get?”.
Recognize the reluctance to change, address the reasons, and include them in the action plan. — Remember the need to change the mindset.
Define the initial action plan. — Outline the major milestones of the migrations, tooling, and resource support from the central team. Set clear expectations and define the separation of responsibilities of the product, central, and foundation teams. Share estimated migration effort with assumptions and breakdown by workload buckets and different categories of migrations.
Create migration guidelines for groups of workloads based on the experimentation phase and keep this up to date as the execution continues.

Phase 4: Execution

The production workload migration can begin after the exit criteria are met for the first three phases. During this phase, some of the steps in the previous stages need to be revisited as the execution progresses. While there will be much to learn during the actual migrations, the process will become simpler and faster as teams gain experience and expertise and foundation components and automation are built.

Build foundation components with security and compliance requirements in mind. — Cloud foundation teams, infrastructure, operations, and security should own these.
Consider the strangler pattern. — When we are migrating large monolith systems, we can try to lift and shift, or to unlock the benefits sooner, we can adapt the strangler pattern where we are working through the system from outer components to inner components to migrate to the cloud. This way, we simultaneously move to the cloud and towards a microservices architecture.
Automate, automate, and automate. — We cannot emphasize enough how important it is to make automation a vital part of the strategy. Any repeated, manual task will have a multiplying effect on the migration effort and increase the risk of downtime. Leverage open-source or vendor-provided tools instead of building your own.
Create a central repository of migration tools and make it easily discoverable.
Evaluate if vendor-supported migrations are suitable for the business. — Looping in experienced migration staff can lighten some of the load. However, there might be limitations depending on what vendors can access. Therefore, tooling and automation-related work might be more suitable.
Revisit your application categorization and identify migration paths for each: rehost, replatform, refactor, etc.
Define migration waves as prepared by teams and carry out migration in waves. Each wave should contribute to the central repository of tooling and blueprints as it applies.
Evaluate frequently and pivot if needed. — Use the key business metrics and migration goals identified earlier to assess the progress. The assumptions made at the beginning might not hold anymore; therefore, adapting the strategy is the key.
Check in with key stakeholders regularly and address patterns of concerns immediately.
Manage risk and share learnings as migration continues.
Become proficient in one cloud provider before moving on to more, rather than attempting multi-cloud initially.

Recap

This article discussed methods and principles for a successful cloud migration strategy, considering a multi-phase migration and balancing critical aspects of the change. We hope you find it helpful in your cloud journey.