Cloud utilization has exploded over the past decade as companies have pivoted to compete with heightened customer expectations and an evolving business landscape that relies on data-driven intelligence and product agility. This has propelled cloud adoption to top of mind for many IT leaders going into the new year. The path to the cloud is nuanced and depends on the goals, resources, and present state of the organization. Early design decisions define how IT systems will operate and how they will evolve to capitalize on the “ility”s of the cloud such as elasticity, scalability, and durability. Taking the wrong path can have serious repercussions on total cost, efficiency, and even reputation if there is a security incident. As a result, IT leaders should lean on an experienced team to drive detailed conversations with all company stakeholders to ensure a well-reasoned and strategic approach to cloud adoption.
There are six common strategies of cloud migration outlined in this article. We often recommend a combination of these approaches when migrating an organization. For example, a lift and shift with targeted optimizations might balance a mostly lift and shift migration with investments in rehosting or refactoring to drive strategic goals like high availability or run cost savings. Here are some of the common approaches:
For companies with servers running packaged software, applications without an active roadmap, or when you need to move fast, rehosting moves existing physical and virtual servers into a complementary Infrastructure as a Service (IaaS) architecture. This “lift and shift” strategy balances migration investment against long term optimization and is a great strategy when the key motivator is CapEx avoidance on aging hardware or as an early step in a long-term evolution.
For those intending to change their OS and database engine, upgrading to the latest release of an application, upgrading their OS or upgrading their database, re-platform may make the most sense. Specific updates are made to the deployed application during the migration to bring it in line with current standards. Sometimes these version updates are enough to allow companies the option to leverage cloud-native services to optimize aspects of the workload. An example of this would be updating a document sharing application to a version that supports AWS S3 as a backend object store.
For companies that intend to replace whole applications, are undergoing a data migration, or would like to purchase a cloud-compatible license, the refactor approach is very flexible and provides opportunities to embrace cloud-native technologies and their benefits like cost optimization and scaling.
Companies that have changing application requirements sometimes prefer a SaaS offering, commercial off-the-shelf product, or would like to purchase a cloud-compatible license, replacing an application. A SaaS product sometimes makes the most sense. In this migration option, companies benefit from a fully managed solution.
In any cloud migration project, IT will likely discover a dataset or set of applications that are no longer needed or fail to justify their overhead. For such instances, retiring these portions of the IT portfolio emphasizes good discernment. For companies that find these applications no longer serve the company’s interests or goals, it not only saves IT costs; it reduces complexity and reduces the attack surface.
Indeed, sometimes external circumstances could mean that some applications must “wait for later” in going to the cloud. Retaining an application or two as-is for the interim allows for your team to keep a portion of operations running outside the cloud for the short term, while migrating the rest of your systems to the cloud. Sometimes cloud just isn’t the right fit due to a strategic focus elsewhere or complexity of moving those assets. For this reason, retaining applications should always be kept as an option.
Taking the Right Approach Demands a Strategic Focus
Cloud migration isn’t a one-size-fits-all move for most organizations. Too often, IT teams fail to plan for the complexities of refactoring and optimizing applications. When companies realize these intricacies in a post-migration phase, it means a level of technical debt until those applications can be enhanced for the cloud. It can also cause delays in migrating other applications, thereby preventing a full environment migration. Better to plan well in advance. Many businesses realize long-term tangible benefits from engaging an experienced team to develop a plan that addresses the priorities, end-state goals, management philosophy, tool-chain, and even the mechanics of the migration itself.