October 5, 2020updated 31 Mar 2023 11:08am

Planning a cloud migration? Here are 27 things to consider

From peak CPU and peak RAM, to decommissioning costs, there's more to think about than TCO.

Mario Thomas, who heads up “Experience Based Acceleration” for Amazon Web Services in EMEA, has migrated more than 400 applications to the cloud in his previous incarnation as an AWS customer. Now a poacher turned gamekeeper (or is it the other way around?) he leads on the cloud provider’s “Experience Based Acceleration” programme, working with strategists, technology leaders, line of business leaders, and executive stakeholders to drive alignment around accelerating cloud adoption. He joined Tech Monitor to talk about the nuts-and-bolts of migration planning for the enterprise.

How can you assess (at a detailed level) whether migrating X application to the cloud is going to make sense for your organisation?

Start with a business case for the move that articulates the cost and business value benefits of the migration to key stakeholders. This is because a narrow focus on TCO will miss the cost of adopting the cloud, the cost of decommissioning the old environment, and the business benefits of adopting cloud. For the cost analysis part of the business case, there are three areas of cost that need to be considered: migration cost, operations cost, and decommission cost.

Migration Cost — the migration cost will typically include such things as the cost of effort to perform the migration (this boils down to the individuals actually doing the migration; either your existing staff or a consultancy paid to do the work, or running the business while your existing staff do the work), dual-running costs (current environment, plus test and production environments in the new location), training, development, and other staff-related costs, additional licencing costs, data costs (backup, transportation, and restoration), and audit and compliance costs for the new environment.

These costs will be experienced whether or not you opt for a cloud or on-premises deployment. Sometimes you will hear of these costs as the ‘migration bubble’ and it is the required initial investment needed to get the migration completed. One final cost for consideration as part of the migration cost is a potential ‘transformation cost’. As part of the migration, a decision may have been made to refactor an application to take advantage of the cloud, for example, moving from a monolith, to a service–oriented architecture using serverless micro-services, including, but not limited to, AWS Lambda, Amazon API Gateway, Amazon S3, and Amazon Dynamo DB.

Operations Cost — many customers will want to perform a total cost of ownership (TCO) analysis of the cloud (or their new on-premises environment) compared to their current environment. The operations cost represents this TCO analysis. The issue we see with TCO analysis is that it typically only includes operations costs and does not consider migration or decommission costs – missing these vital cost elements of migrating to AWS does not present the full picture to decision makers. For this reason, we work with customers to develop a business case that encompasses TCO as just one element of the overall picture, thereby ensuring the complete picture is presented. There may also need to be multiple operations cost calculations performed. For example: compare the cost of doing nothing to the cost of moving to the cloud; compare the cost of doing nothing to the cost of moving to an alternative on-premises solution; compare the cost of moving to the cloud to the cost of moving to an alternative on-premises solution.

The operations cost includes all of the costs for actually running the chosen environment and should include: data centre leases; servers; hypervisor licences; software licences; power and cooling; local and wide-area network; labour costs for managing all aspects of the data centre; patching and system administration functions; and storage.

Decommission Cost — many business cases for migration go on to fail to deliver the promised savings and business outcomes because there was no workstream which included decommissioning the old environment. Decommissioning the old environment typically has several barriers. Firstly, it may be difficult contractually to cease service of the old application or there could be a long data centre lease which has years to run. So, while it isn’t being used anymore, the contract persists for several months or years after migration. Timing of the migration and involvement of incumbent third-parties in the migration and ongoing cost can often mitigate the impact of this. Secondly, people often feel they need the security blanket of being able to ‘go back’ because of the fear of some unknown potential threat to the new environment. The simple answer to this is to perform the decommission; while the old environment exists, people will continue to feel this way. Finally, there may be a requirement to retain access to data once generated by the old environment for compliance or even just curiosity’s sake. In this situation, it makes sense to plan to move that data to a data lake using AWS Lake Formation and take advantage of the benefits of a data lake including reduced storage costs, increased analytics capabilities, and reduced management overhead.

Content from our partners

Unlocking growth through hybrid cloud: 5 key takeaways

How businesses can safeguard themselves on the cyber frontline

How hackers’ tactics are evolving in an increasingly complex landscape

Once the cost analysis part of the business case has been built, we turn to analysing and understanding the business value benefits of the migration. A cost analysis will focus only on the comparison between what is happening now (the ‘as-is’ cost) versus what will happen if we migrate (the ‘to-be’ cost). This narrow focus misses all of the additional benefits that could be gained from the migration which will deliver longer, more impactful benefits to the organisation.

In my work with customers, I have identified 27 business value benefits that come up regularly and should be considered for inclusion in the business case. These value benefits will vary by customer, by customer industry, and by migration method (migration, or transform). Also, for each of the value benefits, customers should ask themselves “can we achieve this outcome in an on-premises environment” or “is it desirable for us to be able to have this business outcome”:

Cost avoidance — by adopting cloud, what costs can the customer avoid? A data centre or hardware refresh, license renewals, expanding headcount, a fine, lease renewal or extension, etc.
Decreased downtime — by adopting the cloud, can the customer decrease their downtime, and what impact does this have on the cost analysis as well as the user experience?
Enter new markets and industries — by adopting cloud, is the customer now able to enter a new market or a new industry that previously was impossible or might take too long to break into? Could they gain first-mover advantage for a new market? Could they bring forward revenues which would otherwise have taken months to realise in a traditional solution?
Faster experimentation — by adopting the cloud, can the customer perform experiments at low cost and high speed? Can they validate ideas, and ‘fail fast’?
Increased agility — by adopting the cloud, can the customer push out new features, new products, new services, improvements in shorter timescales? What effect does this have on the backlog and end-user satisfaction?
Increased collaboration — by adopting the cloud, can the customer raise the level of interaction and collaboration between teams in the business? Can they interact with and service end-users in new ways?
Increased customer insights — by adopting the cloud, can the customer change their relationship with their customers by having better insights into their customer interactions, customer needs and desires, customer future interactions? Can they predict what customers will ask for next?
Increased customer satisfaction — by adopting the cloud, can the customer create a completely frictionless experience for interactions with their customers?
Increased innovation — by adopting the cloud, can the customer increase the pace of innovation within the organisation? Can they reorganise into a product-led and product-focused factory, one which answers to product owners? Can the cycle of the business/IT relationship be broken?
Increased mergers, acquisitions, and disposals velocity — can Private Equity (PE) and Venture Capital (VC) businesses increase deal velocity? Drive up sell-side transaction values, increase buy-side value, assimilate merged or acquired businesses more quickly, dispose of businesses more quickly?
Increased mobility — by adopting the cloud, is your customers’ workforce more mobile? Is the whole organisation more socially mobile than before? Can it continue to function when it is no longer possible to get to the office?
Increased product quality — by adopting the cloud, is product quality improved, because testing can be automated, or carried out more quickly? Or does automation improve product quality, by removing human factors?
Increased revenue, margin, and profit — by adopting the cloud, is the customer seeing increased revenues, margins, and profit? Is cloud adoption helping to drive this? Is this being realised through new business opportunities not possible outside of the cloud, resource efficiencies brought about because of cloud, or both of these things?
Increased security posture — by adopting the cloud, can customers improve their overall security posture? Does the ability to automate previously manual tasks increase security and reduce risk? Does the introduction of automation remove the ‘human factor’ or at least reduce it?
Increased speed to market — by adopting the cloud, can customers take advantage of first-mover advantage, or if they are in a disrupted industry, can they become a fast follower, where previously they have lagged behind the leaders in their industry?
Increased sustainability — by adopting the cloud, can customers make their businesses more sustainable, more environmentally friendly, more socially responsible? Is cloud able to drive these outcomes for your customer?
Optimised operating expenses — by adopting cloud, can your customers optimise their operating expenses, cutting waste and becoming more operationally excellent in the process? Does this lead to increased customer satisfaction levels, better quality of work (leading to lower error rates) and increased throughput?
Reduce cost per x (transaction, acquisition, interaction, etc.) — by adopting the cloud, can customers reduce their cost per x-factor? Can this increase their profitability?
Reduced capex and opex — by adopting the cloud, capital expenditure will reduce (because customers are no longer kitting out their own on-premises environments) and operational expenditure could reduce because of the reduced overheads and efficiencies brought about by operating in the cloud.
Reduced complexity – by adopting the cloud, can customers reduce application and system complexity? Can this lead to increased uptime, lower overhead and maintenance costs, and better outcomes for users and customers?
Reduced defects — by adopting the cloud, can customers reduce software defects and increase overall software quality? This leads to better user and customer outcomes.
Reduced marginal cost — by adopting the cloud, can customers reduce the marginal cost of acquiring new customers, or produce additional goods and services using the same capital employed?
Reduced opportunity cost — by adopting the cloud, can customers ‘have their cake and eat it’? Can they increase the benefit from the option chosen to cover the loss of benefit from the options not selected?
Reduced disruptions — by adopting the cloud, can customers reduce the disruptions they experience and therefore improve the overall customer experience, maintenance and support overhead, and incident response? Can customers stop planning for disaster recovery and get comfortable with disaster avoidance? What benefits does this bring to the customer?
Reduced risk — by adopting the cloud, can customers reduce the risk profile of their organisation? Can they avoid a data breach, could they avoid a fine, could they avoid loss of goodwill?
Reduced support overheads — by adopting the cloud, can customers reduce the cost of supporting the organisation and its systems and processes? Can this reduced overhead cost be assigned to other more meaningful endeavours?
Resource efficiency — by adopting the cloud, can your customer be more efficient with its people? Can they use those people to do important, meaningful, high-value work which gives them an ‘innovation dividend’?

Once the customer has selected the business value benefits that are important to them for their business case, we typically then work with the finance function of the organisation to agree and implement a way of measuring the outcome in reportable business performance terms. Armed with our cost analysis and our business value benefits analysis we then provide the customer with a detailed business case for migration to AWS. We include the net present value (NPV), modified internal rate of return (MIRR), return on investment (ROI), and payback period for the project to help inform the customer and their final decision.

Best practice tips on operations cost analysis?

There are some things to be mindful of when performing the operations cost analysis:

Ensure you consider peak CPU and peak RAM of the current environment when right-sizing your compute requirements. Often, we see customers using averages which means when they land the application in the new environment it could be resource constrained. This leads to a need for more compute, and this then breaks the business case that was based on averages.
Be sure to consider the disposition of your environments; production vs. staging vs. testing vs. development. This should inform which Amazon EC2 instances you use, but also their purchase type e.g. On Demand vs. Reserved Instances/Savings Plan vs. Spot.
Consider which region works best for you from a latency and data sovereignty perspective. If you have the flexibility to be in any AWS region, once latency has been considered, look to the region with the best pricing.
TCO should demonstrate the maximum cost you would pay AWS for the application under consideration – this is because when you land the application in AWS you should immediately start cost-optimising and taking advantage of volume discounts; thereby driving down your costs below what the TCO forecast said.
Ensure you embark on continuous hardware refresh. AWS is different to the on-premises environment. New instance types and new instance families come out all the time; you should take advantage of this and refresh your Amazon EC2 instances regularly. This will give you better performance, on newer hardware, with lower costs per cycle.
Ensure that your Cloud Business Office has a finance function and delegate responsibility for TCO, business cases, AWS account management, bill management, forecasting and budgets, and cost optimisation to that function.

We hear a lot of concerns about data repatriation cost (to on-premises…)

Customers have multiple options for moving data to and from AWS. They can quickly move data over the Internet, via AWS Direct Connect, or via our AWS Snow Family of services to their on-premises environments and back again.

Customers choose to do this every day and for different reasons including compliance, processing which can only take place in an on-premises environment, and because it makes sense for their business.