Retain
The ‘retain’ migration strategy is designed for applications that you intend to keep in your current source environment or applications not currently ready for migration, but you might consider migrating them in the future.
Common scenarios where the retain strategy is applicable include:
- Security and Compliance: Retaining applications may be necessary to stay compliant with data residency regulations, ensuring data remains in a specific geographic location.
- High Risk: Applications requiring a thorough assessment and careful planning before migration might be retained temporarily.
- Dependencies: When other applications depend on one that needs migration, you may choose to retain it until those dependencies are resolved.
- Plans for Software as a Service (SaaS): You might opt to retain an application until a SaaS version becomes available from the vendor. This is a common approach for vendor-based applications.
- Performance Considerations: Applications may be retained based on their performance characteristics, including “zombie” or idle applications in the source environment.
Of the seven migration strategies, “retain” is one of the two passive responses. Unlike strategies like refactoring, re-platforming, rehosting, relocating, and repurchasing, retaining means making a conscious decision not to migrate an application to the cloud. However, this decision can also take the form of a temporary “point-in-time” strategy, indicating that the application’s migration status will be reassessed later.
Reasons for retention may include:
- Planned Retirement: The application is nearing its planned retirement date, and the organisation aims to maximise its financial benefits before decommissioning.
- Extensive Re-Architecting: The application requires significant re-architecting to make it suitable for migration.
- Cost Constraints: The cost of migration exceeds allocated budgets, making retention a cost-effective choice.
- “If It Ain’t Broke, Don’t Fix It” Approach: The application is performing satisfactorily, and there’s no compelling business case for migration.
- Compliance Obligations: The organisation or industry must adhere to strict compliance regulations necessitating on-premises data storage.
It’s crucial to note that these reasons for retention may evolve over time, prompting the need for reassessment. Regularly revisiting application usage every six months allows for a fresh evaluation, considering changing circumstances or new information that may influence the migration strategy.
Rehost
This strategy, often referred to as “lift and shift,” entails moving applications from the source environment to the AWS Cloud without making any alterations to the application itself. In essence, it involves migrating an application stack from an existing on-premises environment to the AWS Cloud.
Rehosting offers several advantages, including the ability to migrate a large number of machines from various source platforms (physical, virtual, or another cloud) to AWS without concerns about compatibility, performance disruptions, extended cutover periods, or long-distance data transfers. Applications can continue serving users during the migration process, minimising disruptions and downtime, with the extent of downtime depending on the chosen cutover strategy.
While rehosting allows for a quick migration, it doesn’t inherently leverage cloud optimisations that could potentially save time and costs. However, once applications are running in the cloud, they become more accessible for optimisation or re-architecting, thanks to easier integration with AWS services and workload management.
Import/Export can facilitate rehosting. This strategy is often considered the simplest and least risky path to cloud migration.
Possible Pitfalls:
Despite its speed and simplicity, rehosting has trade-offs. It may lead to underutilisation of the new environment’s native features if not adequately considered. This can result in higher costs without added value.
Before choosing rehosting, a thorough understanding of the technologies involved is essential. Certain elements, such as shared storage area networks, may not be compatible with rehosting, necessitating individual component evaluation.
Consideration should be given to disaster recovery (DR) strategies, especially if they rely on specific technologies or procedures that may not seamlessly translate to the cloud. For example, clustering software designed for physical nodes in close proximity may require adjustment for cloud deployment. Licensing issues should also be addressed, as some vendors have licensing agreements restricting where their software can run.
Use Cases:
Rehosting may be suitable in scenarios where organisations seek a swift and straightforward migration process. Some use cases include:
- Quick Migration Needs: Organisations with time constraints, such as the end of a data centre contract, can benefit from rehosting’s speedy execution.
- Hardware End of Life: When faced with aging hardware and the reluctance to invest in replacements, rehosting provides an alternative solution.
- Skillset Alignment: If the IT team’s expertise aligns more with traditional migrations to virtual machines, rehosting can be a suitable choice compared to more complex cloud-native approaches.
- Cost-Effective Transition: Rehosting can be a cost-effective way to migrate applications that are compatible with minimal modifications.
Rehosting Best Practices:
Successful rehosting initiatives typically involve the following steps:
- Secure Buy-In: Engage stakeholders early to explain the benefits of rehosting and address any concerns.
- Thorough Planning: Conduct a comprehensive audit to understand the environment fully. Identify redundant components that may be retired instead of migrated.
- Cloud Preparation: Ensure the cloud environment is adequately provisioned and prepared to accommodate potential changes in activity and scaling.
- Cloud Provider Selection: Choose a cloud provider based on existing equipment and services, considering blueprints and planning tools offered.