- Pranjal Mittal
While most newer companies and startups have been able to effectively leverage powerful cloud services and SaaS tools to achieve quicker growth, many enterprises have been slower to adopt and utilize these tools because a majority of their software and systems are deployed on-premise, on legacy systems which make it difficult to leverage modern services and SaaS products. However, with the expansion of possibilies within the cloud and the business advantages it brings to the table (which we'll talk about below) there has been an increased interest among large organizations to leverage the features and benefits of the cloud by migrating to it, either a part of their infrastructure (hybrid) or in entireity. Let's answer some of the question enteprise stakeholders face ask today.
How can migration to the cloud from on-premise benefit my company?
Cloud infrastructure allows you to scale infrastructure more flexibility on a need-basis and pay for what you use. Some cloud providers like AWS reward better capacity planning and offer further reduced costs (such as with Reserved Instances).
Many modern applications and tools are offered as SaaS services, and an organization may not be able to effectively utilize or integrate with these tools without being on the cloud.
Interoperability and Integrations with SaaS tools
Software today is less monolithic than it was a decade ago. Within individual companies different teams are now owning and deploying microservices that are utilized within other teams at the same company. At the same time, there is a growing need to utilize third-party software tools. Having software deployed on the cloud makes it more interoperable with other services and systems that are offered on the cloud.
Improved Security (Shared Ownership Model)
While a software and data system when connected to internet does add a security trade-off, that doesn’t mean moving to the cloud makes a system less secure. Almost all modern day systems including data-centers are either directly or indirectly connected to the internet to better serve their customers, and when we talk about a migration from an on-premise data center (which is already connected to the internet), to one of the cloud providers, there is no downside when it comes to security. Infact, in majority of the cases there is only upside because the well known cloud providers take responsibility of the security of the underlying infrastructure/physical layer of the systems and follow the rigourous security practices and undergo periodic audits to comply with regulations and meet industry standards and certifications. An enterprise after migrating to the cloud primarily needs to think about how to securre their application and virtual infrastructure they are provisioning in the cloud without worrying about the security of the underlying physical hardware.
While superficially it seems cheaper to procure hardware once and not have to pay for it again, the reality of on-premise deployment and software maintainence is different. Hardware too needs to be maintained and upgraded from time to time. On-premise maintenance comes with high capital (hardware upgrades) and operational (maintenance) cost. The top cloud providers today have already deployed resources and practices to improve opex in data-center maintenance. So unless your business is itself focused on offering Infrastructure as a Service, then migrating to a managed cloud provider will in many cases help you reduce both capex and opex.
Your organization may also save hundreds of thousands of dollars in software licensing fees when migrating to the cloud as often cloud providers have procured these licenses at better terms and/or are distributing the cost of these licenses across multiple customers.
What are the different cloud migration strategies?
We start with elaborating the AWS 6Rs of Cloud Migration which is a theoretical classification of migration strategies. In the next section we discuss which strategies are ideal and practical for large organizations.
Rehost: Lift and Shift:
Most cloud providers offer tools to automate migrating VMs from your data-center to the cloud. This is a no-tinker, no-re architect strategy to just move VMs from on-premise infrastructure to the cloud using the same underlying software packages. This strategy is beneficial in a few cases where an organization’s current infrastructure is already deployed on virtual machines or nodes that can be mirrored to virtual machine images that can be quickly exported and imported into the cloud. However, one may still need to think about the networking after applying a rehosting strategy and your native-datacenter services may not directly function as expected so at TaggedWeb we don’t recommend a blind lift-and-shift rehosting approach.
Replatform: Lift, Tinker, Shift.
In this approach along with migration of the VMs, there are some changes to the underlying platform such as utilizing a managed cloud service instead of licensing and deploying software directly. A specific example would be migrating your on-premise database to managed database service such as AWS RDS. Another example would be, migrating on premise file storage storage to the cloud in S3 or migrating your traditional servers to a managed service like AWS Elastic Beanstalk or Elastic Kubernetes Service.
This approach involves first re-thinking the architecture of the application for it to be cloud-native. Cloud providers provide several managed services and under this approach a plan is designed to architect the software the organization is currently running, for it to be cloud-native and then refactor it. This strategy involves careful planning and upfront decision making on understanding how different cloud-native/managed cloud services can be leveraged for an organization and how these services will interconnect and play together.
Repurchasing just refers to procuring a SaaS equivalent for your on-premise software. SaaS services are a category of cloud services. For example, if you deployed a custom CRM software on premise you may utilize a SaaS CRM and export your data to it
This isn’t really a migration strategy. There are some use cases for which a cloud migration may not make sense. For example, you already have a license for a software on-premise that is valid and paid for, for the next few years and you still see value in it. In this case it makes sense to retain that software or portion of your system on-premise while migrating other software to the cloud. Retaining some software on premise and migrating remaining to the cloud is called a “Hybrid-Cloud strategy”.
Like “retain”, this also isn’t really a migration strategy. During your incremental migration to the cloud some software doesn’t add much value and is already covered by another software in function that you will already be utilizing when you move to the cloud. In such cases the software can be retried.
An opinionated high-level cloud migration strategy by TaggedWeb Team
In our opinion at TaggedWeb, you should follow the following high-level steps irrespective of your organization:
(1) Map out your on-premise service architecture into a diagram and document it
This will include working with on-premise solution architects, system analysts and engineers to map out various system interactions into a diagram, preferably a directed graph of dependencies. This will help you identify components that are easiest and hardest to migrate and get a rough sense of the order in which these can be best migrated in. The components that are relatively easier to migrate are usually the ones with the least dependencies such as the compute layer components. Live storage such as real-time databases are often the hardest to migrate without impacting availability and need to be carefully thought through.
(2) Request a team of at least 2 experts, solutions architect + software/cloud engineer to collaborate and design a cloud-native architecture diagram for your infrastructure and software stack. During this process the team may communicate with you to understand whether you would like to retain any system/software components on pre-premise or have any preferences on procuring third-party SaaS services.
(3) If there are any SaaS recommendations in the above plan, understand if you want to procure/repurchase the SaaS option for that use case
(4) Finalize the architecture after review and then ask the team consisting of a solutions architect and atleast one cloud engineer to collaborate on drafting a clear step by step migration plan along with estimated hours. They will first determine the system component with the least dependencies and then create a steps to migrate it to the cloud and then move to the next system component. Also, understand if any engineering development effort will be needed to develop integrations to support the migrations. In many cases, there may be a need to develop custom automation solutions to migrate some of your resources to the cloud.
(5) Have a team of cloud engineers (at least two) review and approve the plan once it is finalized. After it is fully approved, the team (which many contain a few or many members depending on the scale of your migration) should be given a green-light to proceed with migration. Ideally the team participating in the migration (or a subset of the team) should also be involved in the planning to mitigate any surprises. The plan should also mention how the system health will be observed during the migration and must also define rollback strategies in the event there are unexpected issues during the process. The migration should have verfication steps after every few action steps. No data should be deleted on the on-premise systems until the end of the migration, before the health of the migrated system and the data in the cloud is verified.
(6) Run quality checks on the final system to verify that your migration has completed successfully.
About the author: Pranjal Mittal, is the Founder of TaggedWeb.com. He is a former Amazon Engineer, and an AWS Certified Solutions Architect. You can book a consultation on cloud migrations and AWS with Pranjal Mittal via the following booking link