Migration to Cloud - It’s not another IT project…

I’ve been building, operating, migrating and optimising cloud workloads since 2010. I first realised the benefits of cloud computing way back in 2010 when I was looking for a place to run java workloads. My wife and I were well on the way to full digitisation of our work and personal lives back in 2010 and the last thing we wanted was to have to run our startup on physical servers.

It didn’t take me long to understand why cloud computing is fundamentally different to running servers or operating a data centre. I, like most of us, followed the usual path of running workloads on Amazon EC2 as if I was running a server under my desk. I quickly discovered Amazon RDS for MySQL which aligned with our preference to always run open source software, and avoid the punitive licensing, latent defects and bloatware that is too often baked into propietary software. But, it was only when I discovered Amazon SQS[1] that the fundamental difference and unique benefits of cloud computing became obvious. At AWS we often talk about removing the burden of the undifferentiated heavy lifting of digital capabilities.[2] With cloud computing I can do things differently and focus on delivering business value.

It’s now nearly 13 years since my first successful migration to cloud, but in nearly every case today I see cloud migrations that are setup for failure. There is a real dichotomy in how born in the cloud startups (builders) leverage cloud and in how traditional organisations (buyers) apply inefficient and inappropriate transformation methodologies. The following sections of this post are me being opinionated. At the end of the post I provide links to key AWS resources for successful migrations.

I’m going to be particularly blunt in this post, to provide readers with clarity and experienced based guidance free from FUD.[3] I’m using DO or DON’T to summarise. Therefore if you want to skim read; then just read those one liners.

Builders versus Buyers

There are three recurring issues I see with traditional organisations (buyers not builders) and their cloud migrations. We’ll explore these in more detail; but here’s the starting list:

  • Procurement
  • Business Cases and Project Management
  • Risk Management

All these issues seek to be fully formed before any procurement or migration, but the benefit of cloud is all in the output. Builders move fast and burn down risk and unknowns leading to rapid delivery of business value. Buyers generally seek to avoid risk, simplify procurement and don’t consider the business value bigger picture.

Procurement - Assets versus Capability

Procurement

Traditional procurement is anchored to assets and not capability. Cloud computing is a capability that aligns directly with delivering business value. There is no asset. If I’m procuring simple assets then traditional procurement is adequate, but as soon as I’m acquiring complex assets that have through life dependencies, integrations with other assets and systems, or requires support then I’m procuring a capability, and not an asset.

DON’T apply asset procurement approaches to cloud computing

Contract Variation

With cloud computing I have the additional benefit of being able to change, modify, adapt and even switch to using completely different digital services to what I originally ‘procured’. Any procurement approach that limits flexibility in what Cloud Computing services you can use is not going to add value to your business.

Another unique cloud computing migration benefit is the ability to migrate patterns and not just unicorns. Traditional migrations of servers tend to have enough unique aspects that there is little benefit in migrating more efficiently. I’m frequently ’lectured’ by traditional IT experts that cloud is more expensive and less featured than [insert any tech or business feature here]. But in every successful migration I’ve delivered, or observed, costs, server counts and operational burden has reduced by between 25% and 65%.

DO leverage Agile approaches rather than using inefficient contract variations DO migrate patterns not unicorns and measure migration velocity

Business Case and Project Management

Migration Scope

While I see most enterprises undertake some form of portfolio analysis prior to migration, the insights are rarely used to make hard decisions about what to migrate and how to migrate. The 7 Rs[4] defines all possible migration options, but the real power of the 7 Rs is in forcing decisions that deliver optimal business value. Key questions that are too infrequently considered are:

  • Workloads that don’t meet minimum requirements for security, operability, licencing and usability should never be migrated. They can be classified as Retain or Retire and removed from the business. Too often I see decision makers unable, or unwilling, to make the tough decisions that will deliver business value. Frequently customers will expect ’the cloud’ to magically fix legacy vulnerabilities. While there are many ‘strangler patterns’ that can leverage AWS services to ‘ring fence’ or layer security and observability around vulnerable systems; this approach will increase costs and operational burden.
  • Data has value but many legacy systems have little value, and often introduce significant risk due to latent defects, poor usability and high effort support. Rarely do I see data classified with business context. Each week we see another news article on a hack or leak; the concerns are always around the data. Data typically remains coupled to legacy systems that hold that data. This ‘virtual machine / server’ solution for everything ignores a key cloud computing benefit of loose coupling which is crucial to managing costs, business continuity, operational complexity and security.
  • Consolidation of workloads is an opportunity to remove much of the duplication and overlap that creeps into enterprises over time and that manifests itself as exponentially rising IT costs.

DO Look at data independent of software and servers and consolidate ruthlessly DO challenge vendors to modernise their offerings; otherwise they will be excluded from usage

Business Case

Even in 2022 I see significant delays and analysis paralysis in getting signoff on cloud computing migration business cases. In 13 years I am yet to see a ‘buyer’ business case that includes success criteria based on business value or any metrics that seek to leverage the unique benefits of cloud computing.

DO focus migration outputs on business benefits DO foster experimentation using agile methods to verify and validate assumptions about running legacy workloads in the cloud DON’T include unproven assumptions as known and quantified facts in business cases. Leverage AWS Cloud Economics specialists

I’m still amazed how so many customers struggle with cloud cost optimisation. I understand the reasons why:

  • Asset based procurement
  • Silo’d ownership
  • Few enterprises have a continuous improvement culture
  • Lack of system thinking in root cause analysis - cause, effect, latent defects and emergent properties of systems

But when I raise the topic of cost optimisation and whether there is a continuous improvement approach I’m often faced with blank stares or bewilderment. When I’m asked to validate or calculate costs as inputs to a business case then I frequently see overly expensive core services (compute, storage, database, networking) but no consideration of operational costs like observability, CICD, security and business continuity. Customers who are buyers struggle costing AWS services; they are more comfortable buying a business solution or perhaps costing functions and use cases. You need to be a builder to do this. Hence the buyer / builder dillema.

DO cost migration to cloud that includes operations, not just procurement DO engage AWS specialists to help you quantify actual, realistic and costs necessary to deliver business value; not to just procure a cloud ‘asset’

Project Management

Migration to cloud computing is not well defined serial activity like building a bridge. Agile approaches that seek to deliver value in small increments quickly and consequently burn down uncertainty and risk are key to success. Traditional procurement and project management also considers migration the goal and what happens after is someone elses problem. This approach is high risk and is often perceived by the business owners of the migrated environments as a negative.

DO focus on delivering capability and not just servers DON’T use traditional project tools and methodologies that are isolated from migration data to status

Risk Management

I really struggle with many business executives and IT managers views on risk and risk management. I’ve been in the military, in motorsport, have extensive remote and high risk testing experience and have taught risk management as part of an Engineering Management and Professional Practice stream to multiple university engineering faculties. I see a preponderance on risk avoidance and not risk management.

I see positives when executives have a strong technical background and where IT departments have a strong DevOps culture that is aligned to delivering business value. Technical risks are readily mitigated with the myriad of cloud computing services available.

DO ensure your executives are well educated about cloud computing; and they aren’t swayed by vendor or internal FUD. AWS Specialists can be leveraged to educate your organisation in cloud computing. This is a proven risk reduction technique.

Programmatic and schedule risks tend to be baked in with traditional procurement and project management. Migrations should accelerate when using patterns and this is a key success measure to keep track of weekly, daily or hourly. I’m yet to see a successful migration that didn’t leverage a strong agile approach where key measures of success are tracked. The data for these metrics should also be generated as a result of having migrated and not an artifact created in isolated project management tooling.

DO leverage the AWS Cloud Adoption Framework at your executive level

Another negative of migrations that is rarely considered is that migrations, in and of themselves, deliver absolutely zero business value. Migrations are disruptive, duplicative and destroy what is comfortable. Therefore all migrations should be completed as quickly as possible. Remember it’s the outcome of a migration that delivers value. I’ll admit that I shudder every time I here of a migration plan that is many years long. The first few migrations to AWS I delivered in 2015 were numbered in months and included many hundreds of servers. I delivered a joint presentation at ReInvent 2016 with an AWS customer where we described how they were mobilising hundreds of teams to migrate thousands of workloads. They were ultimately successful and survived Covid because they migrated as quickly as possible.

DO measure key success criteria and ensure all are accountable. Gamify this data and communicate to all DON’T avoid risk. All risks - programmatic, schedule, technical, business, people, procurement, etc should be burnt down as migrations are completed. Validation is only valid when the business is realising value. Be wary of procurement and contracts that end when migrations are complete but before business value is realised.

Closing Argument

There is lots more to be discussed in migrating to cloud. In this post I’ve focussed on key observations and not just reframed existing migration best practice. I’ve included some links below to key resources and methodologies[6] from AWS that are key to success. Here’s why they are important:

  • AWS Migration Readiness Assessment (MRA)[5] is your executive roadmap that leverages AWS Partners and tooling, AWS specialist global expertise and also financial supports
  • 7Rs[4] categorises all your migration options. It’s a migration taxonomy.
  • Well Architected is AWS way of providing all customers with the collective knowledge and expertise of hundreds of thousands of migrations. It is not a one size fits all checklist, it’s adaptive, comprehensive and it allows you to understand your environments and baseline them in an agile fashion.
  • The Great Stall is a data driven analysis of migration blockers. Eric Tachibana’s Linkedin post titled ‘Beyond the Great Stall - 10 Secrets to a Great Cloud Transformation’[7] is a must read before you start migrating.
  • The AWS Cloud Adoption Framework[8] describes the six perspectives that all executives should own
  • AWS has several options for assessing migration readiness. This is readiness of people, teams and your org; they are not technical like the 7Rs. You’ll see terms like Cloud Adoption Readiness Tool (CART)[9] and Migration Readiness Assessment (MRA). These methods are go / no go and provide you with an opportunity to ’left shift’ and capability uplift a team before they tackle migrations. This is a key programmatic risk that is often overlooked.
  • AWS specialists are unique in helping customers reduce and optimise cloud computing costs[10]

I have lots of data and customer examples I can deep dive on. I haven’t included them here because I don’t have approval to share certain information. I also pick and chose based on specific context rather than just dump random factoids into the discussion. Reach out to me if you want to discuss how to migrate to AWS successfully at https://au.linkedin.com/in/leftbrainstuff

I have significant experience with migrating customers, AWS, Amazon and working with internal service teams on many of the capabilities mentioned in this post. Some relevant examples are:

  • Amazon Database Freedom - kickoff ProServe Practice Manager
  • AWS CAF Author V1.0 and V2.0
  • AWS Well Architected Kaizen adding fifth pillar for Operational Excellence
  • AWS MRA Customer Alpha
  • AWS ProServe Customer Alpha Lead for AWS DMS, ADS, SMS and AWS Migration Hub
  • Amazon 143 Well Architected in 2 weeks
  • One of the first Amazon Aurora MySQLproduction deployments for Silicon Valley stalwart
  • First global customer using Amazon Managed Services (AMS)
  • Dozen successful mass migrations AWS ProServe 2014 - 2017

Continue reading articles in my Amazon Web Services series

[1] Amazon SQS was the zeroth AWS service and was in use way back in 2004. Amazon S3 is usually considered the first AWS service circa 2006. [2] AWS Well Architected describes cloud computing design principles like undifferentiated heavy lifting https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-dp.html [3] FUD is an acronym for Fear, Uncertainty and Dread and it refers to all the misinformation, waffle and unnecessarily opinionated confusion in the digital space. [4] TODO 7Rs [5] https://aws.amazon.com/migration-acceleration-program/ [6] https://aws.amazon.com/prescriptive-guidance [7] https://www.linkedin.com/pulse/beyond-great-stall-10-secrets-cloud-transformation-eric-tachibana [8] https://aws.amazon.com/professional-services/CAF/ [9] https://cloudreadiness.amazonaws.com/#/cart and https://cloudreadiness.amazonaws.com/bfd2391ccfbac30513c6cc8b5c40e3ae.pdf [10] https://aws.amazon.com/aws-cost-management/aws-cost-optimization/ and https://aws.amazon.com/architecture/cost-optimization/?