At this point, 94% of enterprises are using cloud services. Adoption accelerated during the pandemic, with a staggering 61% migrating to the cloud in 2020 alone. It’s clear that cloud adoption isn’t going anywhere, and businesses are homing in on its capabilities not only to drive remote work, but also improve operations, cut costs, and encrypt data.
Some businesses already have a plan to migrate to the cloud, others are doing discovery and budgeting to find out if they can afford the migration they envision, and others are looking for advice on how to better align a hybrid mix of applications. Wherever you may be on your cloud journey, it’s important to approach the project thoughtfully. Here are five important considerations for cloud migration.
Question #1: What are our business requirements and how do they align to our cloud needs?
Why are you moving to the cloud in the first place? How will this transition better support your business?
Just as you scoped business requirements when you purchased your software (I hope!), you must similarly scope business requirements for the cloud migration. Doing this builds clear goals that can be aligned to strategies for how you approach cloud adoption.
The cloud isn’t one singular option, it can be implemented via public cloud, private cloud, multi-cloud, and hybrid cloud strategies. The one you choose depends on how much control you want over your data, the type of security features you require, how big or small your organization is, the budget you’re working with, etc. Here’s a little more detail on each of the options:
Public Cloud: Most people automatically envision the public cloud when thinking about cloud environments. A public cloud is essentially the internet, with a shared infrastructure that’s usually offered through a cloud service provider (CSP) like AWS. The CSP stores the data, runs the applications, provides development services, and more. Public clouds are cost efficient but can be limited in flexibility and security options.
Private Cloud: Private clouds are more easily customized than public clouds, but that also means they’re pricier. Only about 15% of enterprises opt for private clouds. These enterprises tend to be in industries with stricter regulatory or industry compliance standards. A private cloud is not shared with anyone else. It’s built in a private cloud environment with enhanced security features. However, the responsibility for managing the private environment falls on the organization itself, which requires additional resources and added costs.
Hybrid Cloud: Hybrid clouds are pretty much what they sound like – a mix between public and private cloud environments. Hybrid clouds help create a solution that has more dynamic usability for security, cost efficiency, and scalability, which is probably why 82% of large enterprises use them. With a hybrid cloud, businesses can take advantage of on-demand aspects of the public cloud while enjoying the control of a private cloud. However, the application mix of a hybrid cloud can lead to complex integrations that can sometimes become more costly over time.
Multi-Cloud: Amazingly, 92% of organizations currently have a multi-cloud strategy in place or are planning to get one. Companies using multi-cloud are using more than one public cloud service or setup at a time. This type of deployment can leverage different IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service), and SaaS (Software-as-a-Service) vendors and is usually implemented by larger enterprises with many moving parts who are looking to establish redundancy and a reliable system backup.
Question #2: Which Cloud Migration Strategy Should we Use?
There are different approaches that organizations can use to migrate to the cloud. There’s the lift-and-shift approach, the refactoring approach, replatforming, rebuilding, and replacing. It’s good to be familiar with each one as you consider which may be best for your budget and operating needs.
- Lift-and-shift: Also known as rehosting, lift-and-shift cloud migration is used by organizations who want to move their data center quickly. It does as the name implies: lifts the data stack from on-premises hosting and shifts it to the cloud. Data is moved as an exact copy of the current environment for quick and dirty ROI. However, lift-and-shift may not be well suited for long-term cloud strategies or organizations looking to build advanced cloud capabilities. It’s not a very scalable model. For it to work, workloads moved to the cloud must retain access to the same documents and data that were available on-premises.
- Refactoring: Refactoring is sometimes referred to as rearchitecting. It’s when you move applications to the cloud and modify them to better leverage cloud capabilities. Refactoring requires application code changes to the entire system or a large chunk of the system, making it more complex than some of the other migration strategies. The changes must be tested carefully, which takes time and advanced DevOps skills. If done correctly, refactoring for cloud migration can cut costs by precisely matching resource requirements to the cloud infrastructure. However, if done incorrectly, outages, delays, and added costs can rack up.
- Replatforming: Replatforming for cloud migration shares some traits of both refactoring and lift-and-shift. The difference between this approach and the other two is that replatforming makes minor adjustments to optimize for the cloud instead of simply moving everything over as-is or performing complex code changes. Replatforming modifications may change how a program interacts with a database or make minimal coding changes to enable better scaling in the cloud. It’s a cost-efficient approach that allows an organization to scale as needed, however for it to work, the organization must invest in basic automation to run it and remain focused on the core changes they wish to make. If they get caught up in building specialized components or making unnecessary changes, the migration can start to transform into a larger refactoring project.
- Rebuilding: Rebuilding requires completely rebuilding the application from scratch to match the cloud. As you might imagine, this is costly, relies heavily on experienced DevOps, and requires a huge time investment.
- Replacing: Replacing involves moving applications to a brand new cloud-native product. Most often this is an SaaS application. Organizations moving from outdated legacy systems often go this route, but the change also comes with a learning curve, as employees must be trained on the new system and its uses.
Question #3: Are we Considering all the Associated Costs?
Budget is a powerful driver when migrating to the cloud. It’s everyone’s job to try and stay within that budget to maximize the ROI of the project for the business. Obvious costs include things like the cost of adopting new platforms, migrating data, hiring developers, etc. Most of the major CSPs offer a price calculator that can help, but there may be a few cost calculations that are less obvious. Here are some questions you should know the answer to before you settle on your cloud migration budget:
- Do we have the skills to maintain these systems in-house, or will we use an outsourced IT provider? For example, if you’re rearchitecting a solution with complicated DevOps, are you hiring an outside entity or using an internal team? Once the solution is up-and-running who will be responsible for maintenance and support? There are long-term maintenance costs to think about when migrating to the cloud.
- Have we calculated our server requirements so we don’t buy more than we need? How much storage do you need? How much RAM? How many vCPUs per server? Making the most of the cloud investment requires proactive calculations on these things. It may be difficult to get a straight answer from a cloud provider or hosting company about what they recommend, so you’re going to have to do some legwork on your own.
- Will we need any auxiliary cloud services? Auxillary services can be valuable add-ons that help with workload and security as you move to the cloud, but they’re not always necessary. Depending on your project, you may opt to use content delivery networks, DDoS protection, or other auxiliary services to support your project. The more you add, the higher your costs will be.
- How much is the data migration going to cost? Best practices for migrating data suggest all migrations include a process of data cleaning for optimal results. Is that a separate fee, or is it included from your migration partner? If you’re moving massive quantities of data, or if you have any complex data sets, that will add to your migration costs.
- How much is consulting and IT labor going to cost us? As noted in the first cost question, whether you handle the cloud migration in-house or outsource is a cost factor. In most cases, even if you have the DevOps team available to do it, you still may need a consulting partner that specializes in cloud migration to guide your project effectively. If you don’t have the internal DevOps to migrate to the cloud, you’ll be deciding whether you want to make some hires or use a service. Either way, it’s a long-term cost you must consider.
- What’s our plan for data backup? Yes, cloud data storage is more reliable than on-premises, but it’s not perfect. You should always back up your data in the event of a major failure or outage. Will that backup be on-premises? Will you send it to another cloud? What are the potential recurring costs associated to that?
Question #4: Does this Approach Fit our Security and Regulatory Needs?
Does your organization follow HIPAA, GDPR, FERPA, etc.? Do you have strict data privacy standards, such as those in the financial services industry? The right type of cloud environment and the right cloud migration approach are linked to these standards. You’ll need to consider data classification and protection regulations to determine which systems and data can be migrated.
Your team also should analyze the potential CSPs to understand their security standards, data ownership, shared responsibilities, and other data security factors. Once you’ve chosen a route for your cloud data migration, you must think bigger picture on how the move to the cloud will impact your existing risk management, disaster recovery, and data governance standards. Managing security and compliance in the cloud will require updates to these processes and should not be overlooked.
Question #5: What is our Timeline and how will we Manage the Effects on Staff and Customers?
Even if you do a lift-and-shift cloud migration, the pre-cloud assessment, planning, and preparations still take time. The more extensive the cloud project you’re trying to undertake, the longer your project timeline will become. Along with that comes effects on staff and customers. Will these changes come with new training for your internal teams? How will the affects on day-to-day operations impact your customers in the meantime?
It’s important to consider how different departments will be affected during each phase of your project. Keeping everyone looped into what’s happening will help ease the transition, but you still need a larger plan for communicating the changes, training teams, and updating customer-facing processes to match the new cloud capabilities.
Your CIO should help outline a timeline with your CSPs that notes the major benchmarks of the project and when they should be accomplished. This way, you can clearly see the progress towards your end goals and the accomplishments in each stage of the cloud migration project. It’s also important to set expectations for downtime and worst-case scenarios so you have an action plan in the event that they occur.