There are 7 migration strategies organisations can use when moving applications to the cloud or between public clouds. It is imperative to ensure your use case has the right migration strategy and considers your teams skill set, business need, time investment and cost.
In this article, we discuss the meaning and importance of 2 of the 7 migration strategies: Retire and Relocate.
Retire
The retirement migration strategy is a relevant approach for applications earmarked for decommissioning. Although the decision may seem straightforward at first, determining whether applications can be retired can often evolve into a complex process, introducing a level of intricacy and associated risks. Organisations must diligently comprehend all dependencies to ensure a comprehensive understanding, especially considering the possibility of the application being utilised elsewhere within the organisation. This comprehensive assessment is crucial for effective implementation of the retirement migration strategy.
Retiring applications becomes a prudent choice under various circumstances:
Lack of Business Value
When there is no discernible business value in preserving or transitioning the application to the cloud, opting for retirement ensures a strategic allocation of resources. This decision aligns with a focus on efficiency and cost-effectiveness.
Cost Reduction and Technical Debt
The goal of eliminating the costs associated with maintaining and hosting the application underscores a commitment to reducing technical debt. Retiring applications streamlines operations, allowing organisations to reallocate resources to more strategic initiatives.
Security Prioritisation
Prioritising the reduction of security risks is crucial, especially for applications running on outdated operating system (OS) versions or relying on unsupported components. Retiring such applications safeguards the overall security posture of the organisation, mitigating potential vulnerabilities.
Performance Metrics Unmet
When applications fall short of meeting the necessary performance metrics, retiring them becomes a proactive measure. This ensures that the organisation maintains a high standard of operational efficiency and user satisfaction, avoiding potential disruptions and inefficiencies.
The decision to retire applications is multifaceted, encompassing considerations of business value, cost-effectiveness, security, and performance optimisation. This strategic approach aligns with the organisation’s overarching goals of staying technologically current, secure, and operationally efficient.
Relocate
Utilising the “Relocate” approach, you have the capability to efficiently move a significant number of servers, encompassing one or more applications, from an on-premises platform to a cloud-based rendition of the same platform. Furthermore, this strategy enables you to employ the relocation method for transferring instances or objects to an alternative virtual private cloud (VPC), AWS Region, or AWS account.
As an illustration, it can be applied to execute large-scale server migrations from a VMware software-defined data centre (SSDC) to VMware Cloud on AWS, or to facilitate the relocation of an Amazon Relational Database Service (Amazon RDS) DB instance to another VPC or AWS account.
It’s important to note that the relocate strategy does not necessitate the procurement of new hardware, the need to rewrite applications, or alterations to your current operations. Throughout the relocation process, the application remains operational which minimises disruptions and downtime. This makes the “Relocate” strategy the swiftest method for migrating and managing your workload in the cloud, as it leaves the overall architecture of your application untouched.
Selecting an AWS Region
AWS EC2 is hosted in various global locations, including regions, availability zones, local zones, AWS outposts, and wavelength zones. Each region represents a distinct geographic area, and AWS currently offers 26 different regions worldwide, with plans for an additional eight in Australia, New Zealand, Canada, India, Israel, Spain, Switzerland, and the UAE.
An AWS account grants users the ability to launch Amazon EC2 instances in locations that align with their needs, but the specifics of the account determine which regions are accessible. Global or multinational organizations may be physically situated in one region but opt to deploy instances in Europe, for instance, to be closer to their European customers or comply with legal requirements.
Greg Cockburn, Head of Hyperscale Cloud at AC3, advises, “The recommendation is to place the workload where it is closest to the majority of its users.” As a result, most clients favour ap-southeast-2, the Asia Pacific (Sydney) region.
The other seven Asia Pacific locations are ap-east-1 (Hong Kong), ap-southeast-3 (Jakarta), ap-south-1 (Mumbai), ap-northeast-3 (Osaka), ap-northeast-2 (Seoul), ap-southeast-1 (Singapore), and ap-northeast-1 (Tokyo).
However, there’s a potential downside to hosting your infrastructure in just one location, which pertains to availability. As Cockburn notes, “If the whole region goes down, then nothing works, and all of the organisation’s workloads also go down.”
Multi – Region Approach
This potential vulnerability is the primary reason organisations may opt for multiple regions, primarily for disaster recovery purposes. In the event of an issue with AWS’s data centre network program or storage program, rendering the host region unresponsive, users won’t be able to access the servers.
An alternative infrastructure that replicates workflows, load balancers, and databases in a different region provides a script for switching to the next region if necessary. In essence, it acts as a safety measure, offering reliability and high availability.
The trade-off here is cost. Doubling the infrastructure means doubling the expenses. Cockburn illustrates this with an example: “One of our clients maintains five servers in its primary region but only one server in its disaster recovery region. If a switchover occurs, they can quickly scale up servers in the region to address the workload.”
However, it’s essential to because the need for a switch may arise unexpectedly. This entails continuous backups, database synchronisation, and application version consistency across different regions. Ensuring the same application version is crucial in each region.