Cloud Migration Considerations

Moving to the ‘Cloud’ (it’s actually ‘a’ Cloud’ but we’ll come to that later!) is something every organisation is wanting to do at the minute. I often speak with Managers & Directors who are about to embark on this journey and simply don’t know where to start. The overwhelming risk, choices, and strategic pitfalls plague every business roadmap and I’m often asked to help, advise or implement a company’s journey to cloud and help avoid problems which manifest along the way.

I wanted to break down the common conversation areas I have time & time again, and hopefully it’ll be useful context if you, are on a path to cloud. You can also reach out to me via email or Twitter, whereby I’ll be sure to get back to you!

Why move to Cloud?

There’s an almost infinite amount of reasons why an organisation would want to move to some form of cloud-based solution. Often its changing the cost model and subsequently leveraging cost reduction and that’s certainly what I see and experience in the boardroom. So that’s going from a traditional CAPEX (buy your equipment & infrastructure and take on the total costs regardless of usage) to a more OPEX model (only pay for what you use more like a typical commoditised service). Whilst the above example makes perfect commercial sense, the decision to move to the cloud in the boardroom vs the actual cloud readiness viability of the business is something often not thought about in enough detail.

Maturity Assessment

Moving legacy platforms and services to cloud is an often-problematic journey. Companies build out proprietary services and internal systems over time which have become bloated and sprawled across both infrastructure and processes. Often mission critical, these services or platforms can’t readily be lifted and shifted.  Occasionally, there’s even re-architecture or removal and replacement to consider, (we’ll talk about the 7R app rationalisation process later). But it’s not just systems to think about. Legacy IT teams experienced with providing support in-house to on-premise equipment aren’t always trained to deal with cloud vendors. Re-training and reskilling along with new hires to accommodate a move to the cloud aren’t always factored into the total cost of a cloud migration.

Performance & Applications

There’s often a lack of focus around where to start when it comes to moving to cloud. Companies should elect to pick their apps and workloads carefully and take into consideration smaller ‘lighthouse’ or quick win projects which help provide some much needed success in the early stages. Going through an app rationalisation sprint which includes the typical seven ‘R’s along with getting an understanding of the existing estate will pay dividends when it comes to selecting cloud vendors and overall cloud strategy.

The 7R’s are centered around the decision to (R)emove, (R)etain, (R)ehost (R)efactor (R)evise (R)ebuild or (R)eplace. Part of a good app rationalisation programme is to list out the application, service or workload estate and start answering these questions to get an idea of what is feasible within the organisation.  This will help decide on IaaS, PaaS, SaaS or something else entirely.

Moving to ‘a cloud’.

It’s not ‘the cloud’ it’s more ‘a cloud’. You see there are now so many providers on the market who provide cloud services, with differing variants of service, not to mention on top the actual business requirements from client to client also vary, whom may need a private secure cloud, one that’s geographically specific, or serve their services and workloads across multiple providers. We’ll talk about governance & security later in this article.

I did a talk in 2019 around how I thought the future of cloud as part of the digital backbone would see cloud provision become heavily commoditised to the point of organisations would simply switch from vendor to vendor based on things such as price, customer service or performance. Of course, the ability to do this will be dependant on organisations ensuring enough time and money has been invested at the start and into refactoring or rebuilding their apps, platforms and workloads to ensure they are simple and vendor agnostic. This is breaking each down into its simplest constituent parts taking away anything bespoke or proprietary and rebuilding where needed. Often organisations don’t think about this, and consider a move to cloud a ‘lift and shift’ job.

People

One of the first things I advise organisations tackle is who will be leading the migration from an architectural level. An architectural lead role, needs to be either defined or employed before anything further is done. This is not about having a ‘single throat to choke’ (something I’ll explain later when we discuss vendors) but more as part of the migration there’ll be a considerable amount of planning, technical decisions, and considerations which will all need documenting, reporting on and leading. Get this right as part of the project set up phase, and often an organisation will be in a better place because of it.

Choice of Cloud – This is cirrus business.

Whilst I’m sure you’ll excuse the pun, choosing your cloud vendor will often be based on a few factors including the business vertical and any regulatory requirements, and also the depth of cloud migration being conducted. Simple lift and shift exercises can be done with relatively simple planning so long as the project is simple, more deep cloud integrations spanning multiple vendors provides much more scope to consider. To help understand and measure migration success later, and to help justify any subsequent business case, I often ask organisations to consider benchmarking their project and considering the cloud KPI’s they may want to consider recording. You can also typically split these KPIs across business area and operating model, so for example;

IT & Engineering

• CPU utilisation
• Disk performance
• Network throughput & bandwidth

Customer Experience

• Cart Adds
• Conversion rates
• Page load times/lag

Application or workload

• Error rates/crashes
• Availability
• Etc

You’ll need tooling to start logging this and often the baked in tooling with each cloud vendor can be limited and biased, so robust and separated enterprise monitoring tools will need to be factored into your project costs and often they aren’t cheap.

During the same talk I mentioned, organisations will now start to need to think about how burstable PAYG and often unfathomable pricing tiers work and ensure they don’t get ripped off. Accounting and Finance dept’s previously used to annual billing cycles for licensing and infrastructure are going to experience new worlds of pain.  All the cloud providers are guilty of encouraging vendor lock in, with easy and often entirely free routes in with extremely low barriers of entry, to get your data and workloads in, but trying to get them out or decommissioned can become a nightmare. As a technology professional and former IT Manager, I’ve been guilty of spinning up Azure or AWS environments for Proof of Concepts only to forget them until after 90 days I suddenly got a rather large bill. The billing and performance metrics suddenly become more obscure in Cloud land and even more so when you’ve not defined your KPI’s, so its important to think about these things from the outset. And when considering data, remember there’s a cost to storage and also removing it (known as ingress and egress). That brings me neatly onto data.

Don’t forget the data

I’m staggered even though it happens time & time again, how many organisations fail to consider their data footprint when moving to the cloud. It’s not only database and application file sizes which need to be considered however, but also the quality of the data. In the case of customer records, time must be factored into cloud migration projects to cleanse this data and ensure it’s ready to be moved. The more data, the longer this will take.

Going back to data footprint size, there’s the consideration of how you move data to a vendor. The more data there is, the more complex this discussion can become. Think about if you have considerable amounts of on-premise data stored on local magnetic tape, will you have the time to read the tapes, cleanse the data, and then package it up? What where the overall volume is too large, how are you getting the data to the data centre of the cloud provider? Who will pay for this and what data governance laws are at risk during these this process? This is why the role of the Migration Architect (see earlier) is so important.

Cloud Governance

Cloud adoption is huge. The global public cloud computing market is set to reach $258b in 2019. A third of companies IT budgets are now going to cloud so it’s time to think about Governance. Some cloud vendors are surprisingly immature in this area, and to be honest everyone is making it up as they go along as the mandate & regulatory controls are still being defined. Organisations need to consider where their data will live and how it will be protected from cyber-attack and internal breaches. The misconception that on-premise is more secure doesn’t wash anymore though, and organisations don’t need to be paying large sums for in-house on-premise IT security as the cloud providers do it better, smarter and cheaper. That doesn’t mean that cyber attack risk isn’t mere folly and remains the no1 threat for organisations today. For example, by 2020 the average cost of data breaches will exceed well over $150m for large organisations so this is something which needs to be taken very seriously.

In Summary

• Get yourself a Cloud Architect role defined and filled straight from the off. Use independent and best practice consultancy to benchmark and sanity check your thoughts, conduct the application rationalisation programme and assist your in-house teams for a smoother transition. I often also find I’m needed to help redesign a future state target operating model to accommodate a full-cloud solution and from cost perspective, there’s some useful calculation tools below which can help you out;
• Amazon Web Services (AWS) Total Cost of Ownership (TCO) calculator
• AWS monthly cost calculator
• Google Cloud Platform pricing calculator
• Microsoft Azure’s pricing calculator
• Rackspace’s calculator
• IBM Bluemix’s calculator

• Get a project plan and define what’s being moved first. Ensure you factor in data considerations and bake in time to allow for training/re-training, data cleansing and ingress/egress fee’s along with some of the more opaque costs of cloud such as billing tiers and bandwidth usage.

• Map the migration strategy to business goals. Now is a good time to get these things into alignment and if you haven’t already, consider your existing operating model and how compatible it is with the future state. Define your backbone digital strategy. Will you need to change key areas, or build out an entirely new operating model? Will you need to employ new staff?

• Maturity assessments – really consider how truly compatible with cloud you may be, and run maturity assessments to see where you are on the curve. Factor time & money in to the project to get you up to operational maturity.

• Build relationships with vendors – trial and error, use small independent and isolated projects to test the waters, and fail quickly and then try again. It’s really important vendor selection and cloud service orchestration is done properly and you should consider vendor management and cloud orchestration services from independent consultancy to help you out for the first 6-12 months.