Ahead in the Cloud – A Migration perspective using AWS Migration Approach use case.

A Migration methodology is built on iterative and continuous progress.

The migration process balances the business and technical efforts needed to complete a cloud migration. Identifying key business drivers for migration and presents the best strategies for planning and executing a cloud migration may include asking a few questions from a client’s perspective such as:

• How do I build the right business case?
• How do I accurately assess my environment?
• How do I learn what I do not know about my enterprise network topology and application portfolio?
• How do I create a migration plan?
• How do I identify and evaluate the right partners to help me?
• How do I estimate the cost of a large transition like this?
• How long will the migration process take to complete?
• What tools will I need to complete the migration?
• How do I handle my legacy applications?
• How do I accelerate the migration effort to realize the business and technology benefits? 

I take reference to AWS Cloud Adoption Framework (AWS CAF) but you may choose any other as the methodology is pretty consistent across Cloud Service Providers. CAF helps organizations understand how cloud adoption transforms the way they work.

Assessing migration readiness across key business and technical areas, referred to as Perspectives, helps determine the most effective approach to an enterprise cloud migration effort.

- AWS CAF is organized into six areas of focus, which span your entire organization. Described below are the areas of focus as Perspectives:  Acronym GOBS – P2

1.   Business,

2.   People,

3.   Governance,

4.   Platform,

5.   Security, and

6.   Operations

 areas of focus helps in determining the organization’s readiness to migrate thereby creating a set of migration execution workstreams the business impacted by cloud adoption, it’s important that we create a migration plan which considers and incorporates the necessary requirements across each area to remain on track.

Below are References from AWS CAF (Cloud Adaption Framework) to get the definitions right.

Impact of Culture and management using OCM (Organization Change Management): Understanding the OCM is key to successful migration and should NEVER be overlooked.

Business Drivers: Below is an examples of common Business drivers that you consider as part of the business case presentation. Getting the definition right helps you make a good business case. [Reference again AWS]

• Operational Costs – Operational costs are the costs of running your infrastructure. They include the unit price of infrastructure, matching supply and demand, investment risk for new applications, markets, and ventures, employing an elastic cost base, and building transparency into the IT operating model.
•  Workforce Productivity – Workforce productivity is how efficiently you are able to get your services to market. You can quickly provision AWS services, which increases your productivity by letting you focus on the things that make your business different, rather than spending time on the things that don’t, like managing data centers. With over 90 services at your disposal, you eliminate the need to build and maintain these independently. We see workforce productivity improvements of 30%-50% following a large migration.
•  Cost Avoidance – Cost avoidance is setting up an environment that does not create unnecessary costs. Eliminating the need for hardware refresh and maintenance programs is a key contributor to cost avoidance. Customers tell us they are not interested in the cost and effort required to execute a big refresh cycle or data center renewal and are accelerating their move to the cloud as a result.
•  Operational Resilience – Operational resilience is reducing your organization’s risk profile and the cost of risk mitigation. With 25 Regions comprising 80 Availability Zones (AZs) as of May 2021, With AWS, you can deploy your applications in multiple regions around the world, which improves your uptime and reduces your risk-related costs. After migrating to AWS, our customers have seen improvements in application performance, better security, and reduction in high-severity incidents. For example, GE Oil & Gas saw a 98% reduction in P1/P0 incidents with improved application performance.
•  Business Agility - Business agility is the ability to react quickly to changing market conditions. Migrating to the Cloud helps increase your overall operational agility. You can expand to new markets, take products to markets quickly, and acquire assets that offer a competitive advantage. You also have the flexibility to speed up divestures or acquisition of lines of business. Operational speed, standardization, and flexibility develop when you use DevOps models, automation, monitoring, and auto-recovery or high-availability capabilities.

Cloud Adoption Strategy

A well-aligned migration strategy, with a supporting business case and a well-thought-out migration plan, sets the proper groundwork for cloud adoption success.

One critical aspect of developing your migration strategy is to collect application portfolio data and rationalize it into what we refer to as the

6 R’s:

1.      Re-host,

2.      Re-platform,

3.      Re-factor/Re-architect,

4.      Re-purchase,

5.      Retire, and

6.      Retain.

This is a method for categorizing what is in your environment, what the Interdependencies are, technical complexity to migrate, and how you’ll go about migrating each application or set of applications.

The complexity of migrating existing applications varies, depending on considerations such as architecture, existing licensing agreements, and business requirements. For example, migrating a virtualized, service-oriented architecture is at the low-complexity end of the spectrum. A monolithic mainframe is at the high-complexity end of the spectrum.

Typically, you want to begin with an application on the low-complexity end of the spectrum to allow for a quick win to build team confidence and to provide a learning experience. You also want to choose an application that has business impact.

Choosing the right migration strategy depends on

·        Your business drivers for cloud adoption,

·        As well as time considerations,

·        Business and financial constraints, and

·        Resource requirements.

In the next phase, optimize applications where the Cloud Service Provider’s Platform can make a notable difference in cost, performance, productivity, or compliance. For example, if you are migrating an application that leverages an Oracle database and your strategy includes replacing Oracle with Aurora PostgreSQL, the best migration approach may be to

·        Migrate the application and stabilize it in the migration phase.

·        Then execute the database change effort in a subsequent phase.

·        This approach controls risk during the migration phase and focuses on the migration business case and value proposition.

 Your strategy should address the following questions:

·        Is there a time sensitivity to the business case or business driver, for example, a data center shutdown or contract expiration?

·        Who will operate your AWS environment and your applications? Do you use an outsourced provider today? What operating model would you like to have long-term?

·        What standards are critical to impose on all applications that you migrate?

·        What automation requirements will you impose on applications as a starting point for cloud operations, flexibility, and speed? Will these requirements be imposed on all applications or a defined subset? How will you impose these standards?

The following are examples: TCO Analysis  MS CloudRecon Tool for analysis

·        We will drive the migration timeline to retire specific facilities and use savings to fund the transformation to cloud computing. Time is particularly important, but we will consider any changes that can be done quickly and safely while creating immediate savings.

·        We will insource core engineering functions that have been historically outsourced. We will look at technology platforms that remove operational barriers and allow us to scale this function.

·        Business continuity is a critical driver for our migration. We will take the time during the migration to improve our position. Where application risk and costs are high, we will consider a phased approach: migrate first and optimize in subsequent phases. In these cases, the migration plan must include the second phase.

·        For all custom development, we will move to a DevOps model. We will take the time to build the development and release processes and educate development teams in each application migration plan matching this pattern.

CloudRecon Tool: Business Case

AWS Total Cost of Operations Tool (TCO)

In building your business case, consider the following items:

·        Right-size mapping provides estimates of the AWS services (compute, storage, etc.) required to run the existing applications and processes on AWS. It includes capacity views (as provisioned) and utilization views (based on actual use). This is a significant part of the value proposition, especially in overprovisioned virtualized data centers.

·        Extend right-size mapping to consider resources that are not required full time, for example, turning off development and test servers when not in use and reducing run costs.

·        Identify early candidates for migration to establish migration processes and develop experience in the migration readiness and planning phase. This early analysis of the application discovery data will help you determine run rate cost, migration cost, resource requirements, and timelines for the Migration.

You migrate candidate applications and application groupings, commonly referred to as migration waves, to the cloud environment.

Functional Organization of a Cloud Center of Excellence (CCoE)

Migration readiness Assessment (MRA)

Assessing Migration Readiness

The AWS Cloud Adoption Framework (AWS CAF) is a framework for analyzing your IT environment. Using this framework lets you determine your cloud migration readiness. Each perspective of the AWS CAF provides ways of looking at your environment through different lenses to make sure all areas of your business are addressed. Being ready for a large migration initiative requires preparation across several key areas.

AWS has developed a set of tools and processes to help you assess your organization’s current migration readiness state in each of the AWS CAF perspectives. The Migration Readiness Assessment (MRA) process identifies readiness gaps and makes recommendations to fill those gaps in preparation for a large migration effort. The MRA is completed interactively in a cross-group setting, involving key stakeholders and team members from across the IT organization, to build a common view of the current state. You may have representatives from IT Leadership, Networking, Operations, Security, Risk and

Compliance, Application Development, Enterprise Architecture, and your CCoE or CBO. The MRA output includes actions and next steps and visuals like a heat map (see Figure ) below The MRA is available through AWS or an AWS Migration Partner.

 Link: here

The MRA phase determines the current state of your readiness to migrate and identifies areas where you already have strong capabilities and where further development is needed to migrate at scale. The MRA evaluates cloud readiness along eight dimensions (landing zone, operating model, security and compliance, migration process experience, skills and center of excellence, migration plan and business plan). Priorities and gaps identified during the assessment help define the scope for the Migration Readiness & Planning (MRP) phase. The MRA typically involves a 1-day workshop conducted at your office with your key stakeholders.

 During the Migration Readiness & Planning (MRP) phase, the team will work with your stakeholders to build the foundation for large-scale migration.  We work with the Client to develop a strong migration plan and compelling business case that articulates the total cost of ownership (TCO) and return on investment (ROI) for cloud migration. 

Migration readiness Assessment (MRA) heat map

Application Discovery

• Application Discovery is the process of understanding your on-premises environment, determining what physical and virtual servers exist, and what applications are running on those servers.
• You will need to take stock of your existing on-premises portfolio of applications, servers, and other resources to build your business case and plan your migration.
• You can categorize your organization’s on-premises environment based on operating system mix, application patterns, and business scenarios. This categorization can be simple to start. For example, you may group applications based on an end-of-life operating system, or by applications dependent on a specific database or sub-system.
• Application Discovery will help you develop a strategic approach for each group of applications. Application Discovery provides you with the required data for project planning and cost estimation. It includes data collection from multiple sources. A common source is an existing Configuration Management Database (CMDB). The CMDB helps with high-level analysis but often lacks fidelity.

 Discovery Tools

An application discovery tool can:

• Automatically discover the inventory of infrastructure and applications running in your data center and maintain the inventory by continually monitoring your systems.
• Help determine how applications are dependent on each other or on underlying infrastructure.
• Inventory versions of operating systems and services for analysis and planning.
• Measure applications and processes running on hosts to determine performance baselines and optimization opportunities.
• Provide a means to categorize applications and servers and describe them in a way that’s meaningful to the people who will be involved in the migration project.  

Application Portfolio Analysis

Application portfolio analysis takes the application discovery data and then begins grouping applications based on patterns in the portfolio. It identifies order of migration and the migration strategy (i.e. which of the 6 R’s, out lined will be used) for migrating the given pattern. The result of this analysis is a broad categorization of resources aligned by common traits. Special cases may also be identified that need special handling.

Examples of this high-level analysis are:

·        The majority of the servers are Windows-based with a consistent standard OS version. Some of the servers might require an OS upgrade.

·        Distribution of databases across multiple database platforms: 80% of the databases are Oracle and 20% are SQL Server.

·        Grouping of applications and servers by business unit: 30% marketing and sales applications, 20% HR applications, 40% internal productivity applications, and 10% infrastructure management applications.

·        Grouping of resources across type of environment: 50% production, 30% test, and 20% development.

Technical Planning

Planning a migration goes beyond cost, schedule, and scope. It includes taking the application portfolio analysis data and building an initial backlog of prioritized applications. Build the backlog by conducting a deep analysis on your portfolio by gathering data on use patterns.

The team analyzes and prioritizes the application portfolio and gathers information about the current architecture for each application. They develop the future architecture and capture workload details to execute a streamlined migration. It is not important to get through every application before begging execution of the plan. To be agile, do a deep analysis of the first two to three prioritized apps, and then begin the migration. Continue deeper analyses of the next applications while the first applications are being migrated.

Organize applications into migration patterns and into move groups to determine the number of migration teams, cost, and migration project timeline.

Maintain a backlog of applications (about three 2-week sprints) for each migration team in the overall project plan. As you migrate, you gain technical and organizational expertise that you will build into your planning and execution processes. You will be able to take advantage of opportunities to optimize as you progress through your application portfolio.

 The iterative process allows the project to scale to support migration teams structured by pattern, business unit, geography, or other dimensions that align to your organization and project scope.

Items to consider:

• Application discovery and portfolio analysis data are important for categorization, prioritization, and planning at this stage.
• An agile approach allows you to use this data for the migration before it becomes obsolete.
• Iteration helps migrations continue as the detailed plan evolves with new learnings.

Security: Security is key in migration and you need to become aware of the tenents that need to be covered. Please see the figure below

The AWS CAF Security Perspective is comprised of 10 themes:

• Five core security themes – Fundamental themes that manage risk as well as progress by functions outside of information security: identity and access management, logging and monitoring, infrastructure security, data protection, and incident response.
• Five augmenting security themes – Themes that drive continuous operational excellence through availability, automation, and audit: resilience, compliance validation, secure continuous integration/continuous deployment (CI/CD), configuration and vulnerability analysis, and security big data analytics.

 By using the ten themes of the Security Perspective, you can quickly iterate and mature security capabilities on AWS while maintaining flexibility to adapt to business pace and demand.

 Operations

Your operations group defines how day-to-day, quarter-to-quarter, and year-to-year business is conducted. IT operations must align with and support the operations of your business. The Operations Perspective defines current operating procedures and identifies the process changes and training that is needed for successful cloud adoption.

 The Operations Perspective helps you examine how you currently operate and how you would like to operate in the future. Operational decisions relate to the specific applications being migrated. Determine the appropriate Cloud Operating Model (COM) for a particular application or set of applications when envisioning the future state or future mode of operation (FMO).

There are different uses and users for applications across your business. Products and services will be consumed in different patterns across your organization. Therefore, you will have multiple modes of operating in a cloud environment. When planning for your migration you will first define the use cases and actors, and then determine how to deliver the solution.

Platform

IT architects use models to understand and communicate the design of IT systems and their relationships. The Platform Perspective capabilities help you describe the architecture of the target state environment in detail.

The following are key elements of the platform work stream:

·        AWS landing zone – Provides an initial structure and pre-defined configurations for AWS accounts, networks, identity and billing frameworks, and customer-selectable optional packages.

·        Account structure – Defines an initial multi-account structure and pre-configured baseline security that can be easily adopted into your organizational model.

·        Network structure – Provides baseline network configurations that support the most common patterns for network isolation, implements baseline network connectivity between AWS and on-premises networks, and provides user-configurable options for network access and administration.

·        Pre-defined identity and billing frameworks –Provide frameworks for cross-account user identity and access management (based on Microsoft Active Directory) and centralized cost management and reporting.

·        Pre-defined user-selectable packages – Provide a series of user-selectable packages to integrate AWS-related logs into popular reporting tools, integrate with the AWS Service Catalog, and automate infrastructure. It offers third-party tools to help you manage and monitor AWS usage and costs.

Items to consider:

• If your business is new to AWS, consider a managed service provider, such as AWS Managed Services, to build out and manage the platform.
• Identify account structures up-front that allow for effective bill-back processes.
• You will have both on-premises and cloud servers working together, at least initially. Consider a hybrid cloud solution.

 Migrating Planning

Migration Readiness Planning (MRP) develops core operations, security, and platform capabilities to operate at scale. We recommend migrating three to five applications. These applications should be representative of common migration patterns in the portfolio.

One example is re-hosting an application using existing server replication tools. Other examples are re-platforming an application to have its database running on Amazon RDS, or migrating an application that has internet-facing requirements and validating the controls and services involved. Choose the applications before you start the MRP in order to develop an approach and schedule that accommodates your selections.

 Items to consider:

• Identify patterns (e.g., common architectures, technology stacks, etc.) in the portfolio to create a list of application groupings based on common patterns. This creates a common process for group migrations.
• Your first three to five applications should be representative of common patterns in your portfolio. This will determine the process for moving that pattern in the mass migration to follow.

 Migration Execution

Now you will scale teams to support your initial wave of migrations. The core teams expand to form migration sprint teams that operate in parallel. This is useful for re-host and re-platforming patterns that can use automation and tooling to accelerate application migration.

 This is useful for re-host and re-platforming patterns that can use automation and tooling to accelerate application migration.

 Application Migration Process

Specific patterns with larger volumes, such as re-hosting, offer the opportunity to define methods and tools for moving data and application components. However, every application in the execution phase of a migration follows the same six-step process:

1.      Discover,

2.      Design,

3.      Build,

4.      Integrate,

5.      Validate, and

6.      Cutover.

 1.      Discover

In the Discover stage, the application portfolio analysis and planning backlog are used to understand the current (CMO) and future (FMO) architectures. If needed, more data is collected about the application. There are two categories of information:

1.      Discover Business Information (DBI): Examples are Application owner, roadmap, cutover plans, and operation runbooks.  

and

2.      Discover Technical Information (DTI): Examples are server statistics, connectivity, process information, and data flow.

 This information can be captured via tools and confirmed with the application owner. The data is then analyzed, and a migration plan for that application is confirmed with both the sprint team and the application owner. In the case of re-host patterns, this is done in groups that match the patterns. The portfolio discovery and planning process provides this information.

 2.      Design

In the Design stage, the target state is developed (FMO) and documented. The target state includes the AWS architecture, application architecture, and supporting operational components and processes. A member of the sprint team and engineering team (Migration Factory) uses the information collected during the Discover stage to design the application for the targeted AWS environment. This work depends on the migration pattern and includes an infrastructure architecture document that outlines what services to use. The document also includes information about data flow, foundational elements, monitoring design, and how the application will consume external resources.

3.      Build

In the Build stage, the migration design created during the Design stage is executed. The required people, tools, and reusable templates are identified and given to the migration teams. A migration team is selected based on the migration strategy chosen for the application. The team will use these pre-defined methods and tools to migrate to AWS. They assert basic validations against the AWS-hosted application.

4.      Integrate

In the Integrate stage, your migration team makes the external connections for the application. Your team works with external service providers and consumers of the application to make the connections or service calls (API) to the application. The team then run the application to demonstrate functionality and operation before the application is ready for the Validate stage.

5.      Validate

In the Validate stage, each application goes through a series of specific tests (that is, build verification, functional, performance, disaster recovery, and business continuity tests) before being finalized and released for the cutover stage. Your teams evaluate release management, verify rollout and rollback plans, and evaluate performance baselines. Rollback procedures are defined by application within a rollback playbook, which consists of an operations communication plan for users and defines integration, application, and performance impacts. You complete business acceptance criteria by running parallel testing for pre-migrated and migrated applications.

6.      Cutover

In the Cutover stage, you execute the cutover plan that was agreed upon by the migration team (AWS) and application owners (Client). Perform a user acceptance test (UAT) at this stage to support a successful cutover. Use the outlined rollback procedure in the cutover plan if the migration is not successful.

 Items to consider:

• Make sure the team is familiar with agile practices.
• An iterative approach to maximize immediate requirements gathering. You will not do up front work that will be out of date by the time you are ready to use it. (Challenge)
• The CCoE plays a key role in sharing best practices and lessons learned across the different migration teams.

 Team Models

Core migration teams persist through the project as part of your new IT operating model (on Cloud Service Provider). These teams each have their own areas of specialization.

 Core Cloud Teams

The Core Cloud teams work across the migration teams. They act as a central hub for managing projects, sharing lessons learned, coordinating resources, and building common solutions.

 These teams include:

1.      Cloud Business Office (Program Control) – Drives the program, manages resources and budgets, manages and reports risk, and drives communication and change management. Typically, this team reports to the overall migration or cloud lead and becomes the program office for your migrations.

2.      Cloud Engineering & Operations – Builds and validates the fundamental components that ensure development, test, and production environments are scalable, automated, maintained and monitored. This team also prepares landing zones as needed for migrations

3.      Innovation – Develops repeatable solutions that will expedite migrations in coordination with the platform engineering, migration, and transition teams. They work on larger or more complex technical issues for the migration teams.

·        Portfolio Discovery & Planning – Accelerates downstream activities by executing application discovery and optimizing application backlogs. They work to eliminate objections and minimize wasted effort.

·        Migration Factory Teams: Between 20%-50% of an enterprise application portfolio consists of repeated patterns that can be optimized by a factory approach. This is an agile delivery model, and it is important to create a release management plan. Your plan should be based on current workloads and information generated during the MRP phase. You should optimize it continually for future migration waves and future migration teams. Larger and more complex applications often follow the re-factor/re-architect pattern. They are generally conducted in planned release cycles by the application owner. The factory teams are self-sufficient and include five to six cross-functional roles. These include operations, business analysts and owners, migration engineers, developers, and DevOps professionals. The following are examples of migration factory teams that are focused on specific migration patterns:

• Re-host migration team – Migrates high-volume, low-complexity applications that don’t require material change. This team leverages migration automation tools. This approach is integrated into patch-and-release management processes (RMP).
• Re-host migration team – Re-platform migration team – Designs and migrates applications that require a change of platform or a repeatable change in application architecture.
• Re-factor/re-architect migration team – Designs and migrates complex or core business applications that have many dependencies. In most cases, development and technical operations teams support this business capability. The migration becomes a release cycle or a few release cycles within the plan for that team. There can be many of these in flight, and the role of the CBO is to track timing, risks, and issues until migration completion. This team owns the application migration process.

Items to consider:

• Perform a portfolio analysis to understand common patterns across all applications. This can help build repeatable work for the factory teams to execute efficiently.
• Use a partner to help with resource constraints as your team supports regular business activities.  (DXC Managed Services)
• AWS and the AWS Partner Network (APN) ecosystem can bring specialized resources for specific topics such as databases, application development, and migration tooling.

·        Conclusion:

Analyzing your current state, building a plan, and iterating the work breaks a large migration into manageable activities for efficient execution.

 Looking at a migration as an organizational change project empowers you to build buy-in and maintain communications through each stage of the process.

 1.      Build a business case and refine the return on investment as the project progresses.

2.      Use the AWS Cloud Adoption Framework to analyze Client environment through the different Perspectives: Business, People, Governance, Platform, Security, and Operations. This gave me a complete view of areas to improve before moving forward with a large migration effort.

3.      Use a migration factory construct and iterate the migration patterns to create an optimal move to the AWS Cloud. 

4.      Once we had migrated an application, we used our migration experience as a capability for the optimization phases for this application. We have a current architecture and a future design. We implemented, tested, and validated changes before we cutover and went live.

The effort brought new IT capability that now drives speed, agility, and business value for our Clients organization. 

 Post Migration Operations Activity

•      Patch Management

•      Event Monitoring

•      Incident Management

•      Platform Logging

•      Application Logging

•      License Management

•      Backup and Recovery

•      Configuration Management

•      Change Management

•      Problem Management

•      Release Management

I wish that you as an CTO or an IT Manager responsible for Cloud Migration will find this exhaustive compilation and interpretation helpful. Stay ahead of the competition! Be in the cloud ! Best of Luck.