The migration process consists of choosing a strategy ("6 R's") and executing a 5 phase plan. The 5 phases are: Opportunity Evaluation, Portfolio Discovery and Planning, Application Design, Migration & Validation, and Operate.
Phase 1: Opportunity Evaluation. What is the business case or compelling event that will drive your migration to the cloud? Examples: data center lease expiration, policy (e.g. FDCCI, DCOI, ADDCP), access to services or features, reduction of expense (increased opex is more beneficial than initial and recurring capex), developer productivity (e.g. reduced wait time for infrastructure provisioning and access to services that don't need to be built), availability, content caching, backups, disaster recovery.
Phase 2: Portfolio Discovery and Planning. What's in your environment, what are the interdependencies, what will you migrate first, and how will you migrate it? Inspect your configuration management database (CMDB), institutional knowledge, and/or deploy tools (e.g. AWS Discovery Service or RISC Networks). Understand licensing arrangements. For security and costing purposes, it's useful to know:
Phase 3 and 4: Designing, Migrating, and Validating Applications. Each application is designed, migrated, and validated using one of the 6 migration strategies. Common infrastructure and security solutions should be design and used, for example identify management (e.g. Active Directory), log collection, configuration management, backups. Low-complexity, low-interdependency applications should migrate first. Have the application owner monitor the migration and validate the results while monitoring costs.
Phase 5: Modern Operating Model. As applications are migrated, iterate on your process(es) and foundation, decommission old systems, and continue to look for opportunities to achieve efficiencies and/or improvements in cost, labor, and security.
This article has a nice graphic showing 6 migration strategies (although 2 don't count):
Phase 1: Opportunity Evaluation. What is the business case or compelling event that will drive your migration to the cloud? Examples: data center lease expiration, policy (e.g. FDCCI, DCOI, ADDCP), access to services or features, reduction of expense (increased opex is more beneficial than initial and recurring capex), developer productivity (e.g. reduced wait time for infrastructure provisioning and access to services that don't need to be built), availability, content caching, backups, disaster recovery.
Phase 2: Portfolio Discovery and Planning. What's in your environment, what are the interdependencies, what will you migrate first, and how will you migrate it? Inspect your configuration management database (CMDB), institutional knowledge, and/or deploy tools (e.g. AWS Discovery Service or RISC Networks). Understand licensing arrangements. For security and costing purposes, it's useful to know:
- What information type(s) are going to be received, processed, stored, transmitted, and/or displayed in the cloud? Refer to NIST SP 800-60 Volume II for guidance.
- What is the footprint for applications that will be re-hosted or re-platformed? This information can be used for cost estimation.
- Are performance metrics available? This information can be used to right-size the environment. Because the cloud has a pay-as-you-go model, there's no need to over provision resources. The architecture can be designed to support the minimal performance requirements and expanded as additional resources are required.
- Consider data gravity. What data belongs with what application? Where the data lives will drive where the application lives and/or how that application access the data. If a large data set is going to be used to perform sporadic analysis work in the cloud (by spinning up 100s of instances), then analyze whether it makes sense to store this data permanently in the cloud, or move it in/out over the wire or via Snowball. If you don't have the bandwidth and the volume is large, the copy/mail (Snowball) approach will be more efficient than a wire transfer.
- What volume of data needs to be transferred into our out of the cloud? This information is needed to design data transfer solutions (e.g. over the wire or out-of-band using Snowball) and also estimate costs for data egress.
Phase 3 and 4: Designing, Migrating, and Validating Applications. Each application is designed, migrated, and validated using one of the 6 migration strategies. Common infrastructure and security solutions should be design and used, for example identify management (e.g. Active Directory), log collection, configuration management, backups. Low-complexity, low-interdependency applications should migrate first. Have the application owner monitor the migration and validate the results while monitoring costs.
Phase 5: Modern Operating Model. As applications are migrated, iterate on your process(es) and foundation, decommission old systems, and continue to look for opportunities to achieve efficiencies and/or improvements in cost, labor, and security.
This article has a nice graphic showing 6 migration strategies (although 2 don't count):
- Re-host (lift-and-shift)
- Re-platform (lift-and-reshape)
- Re-purchase (replace-drop & shop)
- Re-architect (re-writing/decoupling applications)
- Retire/decommission
- Revisit/retain
References:
- AWS Cloud Enterprise Strategy Blog: Considering a Mass Migration to the Cloud? November 1, 2016.
- AWS Cloud Enterprise Strategy Blog: A Process for Mass Migrations to the Cloud. November 1, 2016.
No comments:
Post a Comment