Eight Critical Success Factors for Cloud Migration

Migrating to cloud requires substantial time and commitment. Businesses with a long history in on-premises data centers and with substantial regulatory and compliance requirements need to act boldly and decisively to achieve meaningful outcomes. Cloud service providers (CSPs) offer documentation, adoption frameworks and resources to assist in this journey, along with advisory services, partners, and consultants. Despite this wealth of information and resources, many businesses fail to fully achieve their expected outcomes, or take much longer than expected, at a higher cost. This list of critical success factors provides a navigational tool, regardless of your expected outcomes, CSP(s), and partners. It’s an opinionated list based on my professional experience. I would love to hear from others, understand what I got right, what can be improved, and how to refine the list.

Factor One – Make a Big Bet

Make a big bet that matters to your business. What “matters” and who your business leaders are will vary from company to company. Define and clearly articulate your rationale for migrating in business terms. Invest enough money and human resources to make a measurable impact. The leaders of your business must be aware of the initiative, understand it (in business terms), and support it financially and organizationally. Quantify the business benefits of success and the consequences of failure.

Contrary indicators

• Leaders outside of the IT team are not aware of the initiative or see it as technology-led, rather than business-driven
• There are no defined business outcomes for which business leaders are accountable
• The defined outcome does not have a meaningful value to the business
• The initial size of the effort does not represent at least 20% of your IT annual change budget; this will vary depending on how your company funds change and overall budget size
• The defined business outcomes are not realistically achievable, for example projected cost savings or migration targets in the first few years are not commensurate with the scale of migration funding and planning
• Cloud adoption or migration is perceived as a “science experiment”, with a few distinguished engineers assigned to “kick the tires on cloud” or achieve a modest engineering objective
• Analysis paralysis – don’t just make a big bet, do something! If you have set your success metrics correctly, likely you won’t have this challenge, but don’t get stuck deciding how to bet

Factor Two – Pick One Provider

Pick one CSP as your primary cloud provider. Most likely this will be one of the “big three” (Amazon Web Services, Azure, Google Compute Platform), but there are emerging competitors such as Oracle Cloud and Alibaba that may suit your needs better, depending on your requirements and markets. The key is to understands your needs, pick the provider that comes closest to meeting them, and commit to building competency in that ecosystem. Cloud provider services and capabilities are constantly evolving, so even if a provider may not meet 100% of your requirements initially, your partnership and feedback can help direct its evolution. It is very hard to build organizational competence around even one CSP. In larger companies, you may have contracts with multiple service providers, including cloud-based “software as a service” companies, such as Service Now and Workday. For any given capability, choose one provider.

It is also important to sensibly leverage the CSP’s “as a service” offerings for compute, network and storage, application building, operations, security, machine learning and AI, data analytics, automation, and others. Your provider choice should partly be driven by how well their strengths align with your needs. Do not succumb to the threat of “vendor lock-in” and pick technologies only if they run everywhere. In some cases, third parties offer “CSP-agnostic” services, but the same caveats apply. Industry regulators abet this behavior by insisting that companies have a defined “exit strategy” in the event their CSP becomes un-viable. In my opinion, assuming you’ve done your diligence in choosing your CSP, this is a black swan scenario that you should name and consider vs. developing detailed plans for, and you should risk-weight your investments when you can.

Very large companies have the luxury and in some cases the need to invest in multi-cloud capabilities and may even achieve good outcomes if they have a high level of cloud competence. While the CSP services are not perfect and you need to manage costs and prepare for resiliency carefully, you should be very thoughtful about when to “roll your own” vs. leveraging the CSP services. When weighing these options, think first of the business value. Avoid investing a lot of time and money building, maintaining, and operating abstraction layers that do not deliver tangible business value.

Contrary Indicators

• No decision at all (see Factor Nine, Do Something) or contracts with multiple CSPs that don’t deliver anything (Factor One, Make a Big Bet), or “switching” before anything is delivered
• Investing in or researching abstraction layers, such as container frameworks or open source databases, without clear rationale and endpoint
• Primary focus on “avoiding vendor lock-in” by using only commodity services (compute, networking, storage, full Kubernetes as a service, other open source “as a service” offerings)

Factor Three – Empower One Accountable Leader

Identify one leader with cloud expertise and empower that individual to lead and be accountable for your cloud initiative. You may be tempted to fudge this, because most companies beginning a cloud journey rarely have senior leaders with cloud experience, or they may opt to distribute responsibility to scale the effort or to offer challenging opportunities to their existing leadership team. Two reasons not to do this:

• The leader must have the technical acumen to make decisions that support the initiative; the leader can partner with a cloud-knowledgeable deputy or third-party advisor if they lack direct experience, while retaining accountability for the outcome
• The leader must have enough autonomy over program objectives, resources, and funding to drive the strategy as a single outcome-focused initiative

Setting up shop and operating in the cloud is substantially different than running in on-premises data centers. It requires focused engineering effort to open for business, and a realignment of skills, activities, and funding across the enterprise, not just in technology. If the leader is not cloud-knowledgeable or well-advised or does not have enough control over funding and resources, investments and technical activities will proceed less efficiently and effectively, and may potentially set the entire initiative up for failure.

Contrary Indicators

• ·??????The senior leader is not technical, or has no cloud experience, or both, and does not have a knowledgeable partner helping develop the strategy and guide decision making
• ·??????Multiple leaders or departments are responsible for different parts of the program, with no clear single accountable owner. For example, program management, cloud engineering, and application migration are run in separate departments with a parallel reporting structure into next level management rather than to a cloud leader
• ·??????Business departments are individually responsible for cloud migration funding and headcount, with no clear allocation and accountability for success vs. competing on-premises initiatives
• ·??????Initial cloud enablement activities, such as planning, education, security, compliance, landing zone setup, and automation are under-funded or under-resourced
• ·??????No defined, measurable, and tracked key performance indicators exist to measure progress and business value delivery; alternatively, too many KPIs, or KPIs that are easy to measure but are not relevant to outcomes
• ·??????Proposed investments or solutions that do not clearly leverage cloud in support of your business outcomes, with excessive reliance on lift and shift, co-location of non-cloud resources, overly complex architectures, or vendor offerings with limited cloud relevance or presence

Factor Four – Hire or Buy Experience

Hire or buy experienced cloud people and listen to them. A corollary of Factor Three (One Accountable Leader), expertise will inform hiring, planning, and delivery decisions. A successful cloud journey proceeds along multiple dimensions simultaneously, including finance, legal, compliance, platform engineering, and application delivery. To leverage the capabilities of the cloud to deliver value for the business quickly and correctly, you need to have the benefit of real-world experience. As with the leader, most traditionally on-premise companies do not have cloud-knowledgeable resources on staff (though with the maturity of cloud, this is changing). Key considerations:

• Use a “seed” model, where you allocate at least a 1 to 5 or 1 to 4 ratio of cloud-experienced resources to your existing staff, either as hires or contractors. Prioritize hiring full-time cloud-knowledgeable senior roles in key areas.
• Fast-track training and new roles for your best resources in all areas and partner them with your experienced seeds.
• For critical areas that must land quickly early in the journey (information security, compliance, landing zone enablement), prioritize hire of cloud-experienced senior leaders and allocate additional headcount and funding for experienced resources
• Invest in building cloud capability in all dimensions of the cloud adoption journey; not just technology but also finance, legal, compliance and business areas

Contrary Indicators

• Leaders in key adoption areas (information security, platform engineering) do not have cloud experience and rely heavily on consultants and contractors to deliver outcomes
• Headcount and funding in key adoption areas is underfunded, limited to low-cost providers, or otherwise constrained, and staffing targets in these areas consistently fall short
• Consulting partner recommendations are frequently sidelined by existing leadership for various reasons (cost, security, compliance, risk, etc.) without clear cloud-focused alternatives
• Reliance on manual processes or legacy tools to deliver key components of cloud enablement (information security, networking, provisioning, posture management, automation)

Factor Five – Accelerate Enablement

Establish a centralized enablement team to make decisions, direct resources, ?enable standardized landing zones, define migration patterns, and establish operating controls. Minimally this team should drive or perform engineering activities associated with environment and landing zone setup, validation, turnover, and operations. In larger and regulated companies, this team can also drive organizational transformation, training, and decisions for finance, legal, compliance, and project teams.?Success indicators include:

• Clear outcomes and timelines for establishment of landing zones and migration patterns
• Automated security, networking, and landing zone provisioning
• Rapid delivery cadence and escalation for delays, since enablement activities necessarily precede migration

Contrary Indicators

• No organized engagement outside of the IT organization
• Wild Wild West – departments (business and IT) create CSP accounts/projects/subscriptions on their own, with “the corporate credit card” (literally or figuratively). A good team may do a great job or deliver a quick win, but it’s easy to end up with a lot of risk, data leakage, operational cost, system outages, or reputational damage
• Doctor No – one or more groups (platform engineering, compliance, risk, information security, legal) effectively stops progress by saying no to some critical step (e.g. production deployment), but is not fully engaged with or accountable for enablement
• What About – Doctor No’s evil twin; a gatekeeper that has an undefined process for granting approval and seems to need one more piece of information, with no timeline or guidance for when these conditions will be satisfied
• No visible evidence of progress delivering landing zones and automation for 90 days or more – the enablement team should be iterating at a high velocity, even if they have limited release points; lack of steady progress is a major red flag
• Reliance on existing or manual processes without a clear short-term plan to change (see also Factor Four – Hire or Buy Experience)

Factor Six – Change the Organization

Invest in training and certification, and organizational transformation. Publicly reward individuals who achieve measurable progress and relevant advanced certification with additional responsibility and leadership opportunities. Make this a broad-based effort that covers all parts of your organization, not just technology. A successful cloud migration initiative requires contributions and collaboration from business leaders, finance, legal, compliance, human resources, and others, and results in the emergence of new leaders and roles across the company. Find the best training (often self-directed online in my experience) and monitor what works and what doesn’t, to invest wisely.

Don’t rely just on training by itself, however. You should also spend time on “organizational transformation”. How does cloud impact your job titles? Your salary bands? Your organizational structure? What do you need more of and less of? What can be automated that wasn’t before? How does cloud impact your regulatory framework or budgeting and financial models? Being thoughtful and effective in these areas requires training and investment in organizational change.

Regarding certifications, it is tempting to “just take the training” or “give a pass” to key engineers. Certification requires an investment of time and money. Some consider certifications as badges for test takers, rather than indications of competency. While it is true that a certification is an indication of a certain knowledge level rather than evidence of competency, the professional-level exams from the major CSPs are challenging and passing them requires the test taker to demonstrate a significant level of CSP-specific solution design knowledge. In my experience, I have heard “oh, I took the training but I never took the test” or see large groups attending expensive on-site training but not demonstrating competency. Training just for training’s sake is a waste of time and money. The certification shows a measurable level of basic knowledge and competence that is a good foundation for building experience.

Contrary Indicators

• No budget is provided for training and certification, or departments are expected to cover out of their existing training budgets
• Excessive reliance on “free” online resources
• No expectation that senior leaders and key decision makers demonstrate competency or achieve certifications
• Company conversations and presentations related to the effort don’t use correct terminology or reflect a lack of alignment with a well-architected migration strategy
• Leadership meetings and communications don’t mention the migration effort or aren’t aligned with the migration outcomes
• Solution designs skew to re-host and re-platform without clear justification; re-architect solutions are complex and do not properly leverage CSP capabilities for performance, resiliency, and cost management

Factor Seven – Expect Incremental Spend

Cloud journeys are frequently driven by a call to action – an end of life data center requiring an expensive refresh, or a security audit identifying extensive software and infrastructure remediation. The temptation (in some cases abetted by CSP marketing) is to promote cloud adoption and migration as a quick win that will save tens of percentage points off your technology spend. This save could be through reduced infrastructure costs, or refresh cost avoidance, or staff reductions due to increased use of “automated” software as a service cloud capabilities. Cloud adoption can in fact offer all of these things, but is in no way a quick fix, especially for companies with substantial on-premises environments and the surrounding staff and vendor contracts. When embarking on a cloud adoption journey, you should always anticipate and plan for at least three years of incremental spend, which means you need to be able to allocate change spend on top of your existing spend. Excessive optimism about when cloud benefits will start to accrue can lead to critical processes being starved of funding and headcount, and loss of momentum on the journey.

Contrary Indicators

• The business case for your cloud program shows a break-even or substantial savings in less than three years
• Business case success metrics are extremely aggressive, for example setting cloud migration targets, migration transformation work, hiring, and project funding at rates substantially higher than typical for your company
• Migration plans depend on a substantial backlog of program effort that does not have allocated staffing and funding, or for which substantial sacrifices must be made from other programs
• A large committed spend with the CSP without a clear funded plan for consumption, leading to migration plans driven from spend commitments, rather than business strategy and expected outcomes

Factor Eight – Prioritize

Prioritize your migration activities and workloads to achieve regular progress and avoid replanning and missed targets. Focus early-stage activities on establishing landing zones and automation and proving out solution patterns. It will probably take longer than you expect to address all information security concerns, establish a control landscape for your environment, and complete migration work for your applications. A complete solution requires re-alignment of application code, data, and operations activities for each capability you migrate; capability gaps in any one of these areas will slow your entire effort if you plan large migrations early in your journey. For example, if you don’t have a mature data program with well-classified data, expect migration of an application with confidential data or region-specific permissible processing and storage requirements to take much longer than you expected, especially in regulated environments. The same applies if you have a large data lake used by multiple business units. Front load simpler applications with fewer data requirements (public or non-confidential data classification, no proprietary vendor or in-house compute requirements, no complex or legacy relational database requirements.) Cloud can address all these requirements, but it will take time to establish solution patterns and scale your effort. Never underestimate organizational barriers to change, especially in heavily regulated environments.

You should also consider prioritization in the context of the other critical success factors – balance your workload migration plans with hiring, organizational change, and enablement. A successful migration requires you to operate well in all of these dimensions, which means you may need to go slower in one dimension to make progress in another.

Contrary Indicators

• Program metrics that focus primarily on workload migrations
• Workload migration plans that rely on rapid migrations of large relational databases or proprietary applications
• Front-loading migration of workloads that don’t have good information security, data classification, or operations governance