AWS Cloud Migration
Some of the key drivers to moving to cloud is
- Operational Costs - Key components of operational costs are unit price of infrastructure, the ability to match supply and demand, finding a pathway to optionality, employing an elastic cost base, and transparency
- Workforce Productivity - getting up and ready in seconds and various service availability.
- Cost Avoidance - eliminating the need for hardware refresh programs and constant maintenance programs
- Operational Resilience - increases resilience and thereby reducing organization's risk profile
- Business Agility - react to market conditions more quickly
Cloud Stages of Adoption
- In the project phase, execute projects to get familiar and experience benefits from the cloud.
- After experiencing the benefits of cloud, build the foundation to scale the cloud adoption.
- This includes creating a landing zone (a pre-configured, secure, multi-account AWS environment), Cloud Center of Excellence (CCoE), operations model, as well as assuring security and compliance readiness.
- Migrate existing applications including mission-critical applications or entire data centers to the cloud as you scale your adoption across a growing portion of the IT portfolio.
- Now that the operations are in the cloud, focus on reinvention by taking advantage of the flexibility and capabilities of AWS to transform business by speeding time to market and increasing the attention on innovation.
Phase 1: Migration Preparation and Business Planning
- Determine the right objectives and begin to get an idea of the types of benefits you will see.
- Starts with some foundational experience and developing a preliminary business case for a migration, which requires taking objectives into account, along with the age and architecture of the existing applications, and their constraints.
Phase 2: Portfolio Discovery and Planning
- Understand the IT portfolio, the dependencies between applications, and begin to consider what types of migration strategies needed to meet the business case objectives.
- With the portfolio discovery and migration approach, you are in a good position to build a full business case.
Phase 3 & Phase 4: Designing, Migrating, and Validating Application
- Move focus from the portfolio level to the individual application level and design, migrate, and validate each application.
- Each application is designed, migrated, and validated according to one of the six common application strategies ("The 6 R's").
- Once you have some foundational experience from migrating a few apps and a plan in place that the organization can get behind - it's time to accelerate the migration and achieve scale.
- AWS provides migration services that help for moving applications and data from on-premises to AWS - AWS Server Migration Service (SMS), AWS Database Migration Service (DMS)
Phase 5: Operate
- Once applications are migrated, iterate on the new foundation, turn off old systems, and constantly iterate toward a modern operating model.
- Operating model becomes an evergreen set of people, process, and technology that constantly improves as you migrate more applications.
Application Migration Strategies
Migration strategies depend upon what is in your environment and the what is suitable for the portfolio, taking into account the business and technical requirements.
Below are the Six common migration strategies employed and build upon "The 5 R's" that Gartner outlined in 2011.
1. Rehost ("lift and shift")
- Moving your application as is to the Cloud.
- helps to quickly implement the migration and scale to meet a business case
- provides better opportunity for re-architect the applications once they are already running in cloud, with the organization having already developed cloud skills and the application with its data is migrated and handling traffic.
- Rehosting can be automated with tools such as AWS Server Migration Service, or can be done manually
2. Replatform ("lift, tinker and shift")
- Moving your application to the Cloud with optimizations, without any major changes.
- Replatform helps achieve some tangible benefit without changing the core architecture of the application. For e.g., using RDS for database or Elastic Beanstalk for applications.
3. Repurchase ("drop and shop")
- Dropping the application and Moving to a complete new Solution
- More of an Buy in a Build vs Buy model, might be expensive in short team but faster time to market.
- Move to a different product, which likely means the organization is willing to change the existing used licensing model
4. Refactor / Re-architect
- Moving the application to Cloud, with major changes.
- More of a Build in a Build vs Buy model, and would take time.
- driven by a strong business need to add features, scale, or performance with agility and improvement in business continuity that would otherwise be difficult to achieve in the application's existing environment.
- Decommission the applications, not needed anymore.
- Identifying IT assets that are no longer useful and can be turned off will help boost your business case and direct your attention towards maintaining the resources that are widely used.
- Keep the applications as is in the current environment
- Retain portions of the IT portfolio, which have tight dependencies, difficult, not in priority or ready for migration
- AWS documentation - Cloud Migration