An Approach to Cloud Transformation and Cloud Migration

The ongoing COVID 19 pandemic is creating new challenges to almost all industries. It is causing a significant impact on business and operating models. Organizations are rethinking, "how to make business resilient for such large disruptions," " how to innovate faster and enable new business services to customers," "how to reduce TCO," and "how to enable better connectivity and collaborations." Such challenges existed before the pandemic era as well, but have become more relevant and important now.

Many IT firms and cloud service providers (AWS/Azure/Google) provide free tools for automated application discovery and assessment. However, manual interventions and interviews are still required to capture certain attributes for defining the right dispositions strategy.

1.2.2 Analysis

It is important to know the organization's cloud strategy, which can influence dispositions. If an organization has a data center consolidation or data center exit strategy within the very short term, then 'Rehost' and 'Replatform' dispositions check could be the first option for existing applications. 

This is also applicable to organizations who require faster migration to some of their workloads and modernize the apps in later phases. There could be EOL (End of Life support) for underlying OS or software on which critical business applications are running. Such applications can be candidates for migrating to new software versions or OS versions on cloud where vendor support is available . Some organizations leverage cloud transformation as an opportunity for rationalization and "modernization" of their exiting IT. Some organizations may want to make the applications "ready for containerization" by refactoring into the supported container technology stack (e.g. Docker). Some take an opportunity to transform commercial applications/databases to cheaper open sources to save cost . Some might be looking cloud as an extension for additional capacity needs. Some organizations may look at the cloud for building new capabilities like data lake, analytics and machine learning. 

Pharma companies may want to analyze a lot of data to  find faster vaccinations for such a pandemic. The cloud can be used for experimentation as well (e.g Piloting/POC). Here is the quick decision tree based on cloud strategy:

As you notice in the above view, Rehost/Replatform strategies are having low risks and fewer migration efforts, but have fewer benefits. Remediation or modernizing applications can have more migration efforts but come with more long term benefits. It's important to assess migration risk vs rewards ratio per applications. Some legacy applications cannot be rehosted or re-platformed due to technology constraints, such application needs remediation (rearchitecting) to new platforms. It is beneficial to rehost "low value" applications on low-cost hardware instead of costly refactoring exercise.

Use data collected from questionnaires and other attributes as mentioned above to analyze the applications for 7R dispositions. Provide a weightage and scoring against attributes in each category. Weightage can be decided based on an organization's business strategy, e.g. time to market may be more important to business than providing user experience. Technical debt can weigh more than high availability.

Business Capability Heap Map: Define the mapping for each application against business capabilities. Identify rationalization opportunities like COTS license reduction opportunities, and redundant applications that can be merged or replaced, or applications/datastores that are too expensive to run.

Based on the scoring of business values, technical value, and cloud amenability, create various analysis models like the 'TIME' model. Charts like 'benefits vs ease of migration,' and 'Technical Value' vs 'Business value.'  This would help in identifying potential "Quick Wins" i.e applications that can be migrated faster with low risk but can also provide cost benefits, as well as business value in short term. Sample Analysis templates are shown below:

Create a decision tree and apply the values from the above charts to arrive at a target cloud disposition, e.g. an application with low business value, but high cloud readiness score can simply be 'Rehost' rather than spending efforts for 're-architecting.' Apps with no business value and of low technical value can be considered to retire or rehost on low-cost infrastructure. Apps with very high business benefits but having low technical value (i.e high technical debt) can be considered for replacing, refactor, or rearchitect options. Applications with both high business and technical value can be considered for either Rearchitect/Rehost scenarios based on long term benefits. Some IT service providers have developed analysis tools that maintain standardized scoring values and rule sets for fastening the analysis process. A sample decision tree is shown below:

At this stage, it may be useful to provide a high-level recommendation summary for the applications. Define the short-term and long-term recommendation against each application, e.g. the short term strategy can be 'Rehost' and the long-term strategy can be to rearchitect using a server-less compute sample disposition such as this one shown below:

1.4 Business Case

Once the High level assessment is done, conduct a high-level cost-benefit analysis for applications. Based on the on-premise infrastructure run cost, depreciation, and infrastructure operations cost, determine the total current run cost of the application. Get the expected spend in the next 3 to 4 years. Based on the disposition of the application and database, create an inventory of target infrastructure with proper instance sizing/instance types/storage/network components/PaaS /DbaaS services. 

Determine the run cost of the application on target cloud for next 3 to 4 years. Determine the approximate migration cost. Determine savings in current infrastructure operation cost if moved to cloud. Use various cloud provider discounts, long term pricing plans benefits to arrive at the target cost. 

Cloud investment will usually be realized in 2 to 3 years. Compare the cost of hosting on different clouds. Cloud provider's online TCO calculators/Monthly spend calculators can be used to arrive at the cost. Include the added intangible benefits like agility, elasticity, flexibility, and scalability features as part of the overall business case.

This business case exercise will provide the business owners and CxOs with decision points for initiating cloud projects. It is also important to include cloud optimization exercise once the application and data are migrated on the cloud.

1.5. Cloud Business Office 

For successful cloud adoption and value realization, it is important to have effective strategic oversight and governance in an organization. Establish Cloud Business Office (CBO) that has C-level executives (sponsors), key business stakeholders, app owners, infrastructure leads, security leads, engineering leads, operations leads, procurement team, risk and compliance, and enterprise architects who would drive, accelerate and enable cloud transformation. CBO objectives are to define transformation goals and objectives, driving cloud strategy across the organization, providing budgets, architecture standards, change management, and initiate and govern cloud migration projects, tracking value realizations by measuring metrics and benefits.

Each of the roles will have either long-term or short-term responsibilities for supporting the CBO objectives and decisions around cloud adoption. Such a function or unit can also be called a Cloud Strategy office ( CSO) or COE ( Cloud Center of Excellence).

2. Design and Planning

In this phase, a detailed assessment of the application is performed and the minimum viable architecture is defined to implement the migration strategy. It is also possible to refine the cloud strategy in this phase .

Detailed Assessment: Analyze the application code/software that are planned for refactoring using code scanners. There are many commercial tools available to scan code for refactoring. Azure and Aws cloud also provide code scan tools e.g .NET portability Analyzer/Porting Assistant for .NET etc. There are also tools like AWS App2Contaner, which can even containerize apps and deploy them on the container platforms. Analyze the functionalities and code for rehosting, re-platforming, and rearchitecting applications. Identify any risks and blockers. This exercise will give a details required to arrive efforts estimation for cloud migration. 

Transformation Roadmap: Define the migration plan based on the efforts and assessment done. Group the applications with common dependencies and databases. Define a migration for each of such groups. Grouping can also be done by organization functions/domains or technical capabilities (e.g. Webapps, middleware, core transaction systems, Bigdata, etc.). Prioritize applications by complexities. Plan migration of the applications that are of low risk ( "quick wins" ) and of less complexity to start with. 

For example, simple web apps or reporting apps can be considered as early movers. Identify the Agile process methods and team structures . Identify number of migration user stories and sprints. Define the migration team structure and identify the right size of team by splitting it into Tribes and Squads. Some organizations may call them PODs structures. 

Define the life cycle stages for migration, testing and Cut-Over plans for applications. Successful migrations will create templates for moving the remaining apps. Modernizing applications (rearchitecting or refactoring) may require more time and a long-term strategy. Apply DevOps and Agile methods( e.g. Scrum, SAFe ) for migrations.

Target Architecture: Define the target deployment architecture for the applications, data, and network components. Since the migrations are planned in an agile fashion, it's important to define the architecture (Minimum Viable Architecture) that is simplistic but adequate to implement the migration. Define the target technologies, software/OS versions, and database versions that existing applications and databases will be transformed during migration. 

Consider database dependencies, interfaces, external integrations and data migration requirements for the applications. For cases where data and dependent applications going to reside on-premise, consider hybrid cloud architecture. This architecture will keep evolving during migration sprints. 

Make architectural decisions, and get the stake holder's buy-in for such decisions. Design architecture with high availability, load balancing, and performance with the "fit for purpose" principle. After all, cloud is built for scalability and availability, hence avoid over-engineering. A sample of a hybrid-cloud architecture is represented below:

DevOps: DevOps has become the de-facto standard for every industry for any transformation and modernization projects. Each migration POD teams should follow DevOps process. For some applications (e.g. COTS), DevOps may be not relevant or can't be applied. Callout such applications in architectural decisions. Such applications can follow existing methods of build and deployment on the target cloud. 

Define the tools that would be used for building, testing, deploying and monitoring apps on the target cloud. There are many cloud-native options available. Design the DevOps pipeline (e.g. using Jenkins/AWS code pipeline/Azure DevOps etc.). Consider code vulnerability scanning and security testing before deployments. Plan to automate the steps wherever feasible (e.g. testing). Define how the source code is managed and versioned (e.g. using Github repository and branching). Define how user stories are captured and tracked (e.g. using tools like Jira). Define the various environments that the existing application that will be deployed and tested before going live in production. 

The migration process has to be continuous (CI/CD) and iterative for each application until the required testing KPIs are met. Define the application support process and how to monitor the issues post-production. DevOps teams are expected to own the application from code changes and deployment to operations.

Proof Of Concept (POC): Conduct a proof of concept in cloud. Whether it's a migration of application or data warehouse, piloting the migration in a cloud environment will give you the confidence, new learnings, and help in overcoming challenges. POC will help in identifying issues and gaps based on current organizational processes, connectivity, and environment dependencies. Apply DevOps process and tools while migrating, and pick up a medium complex rehost and refactoring application, such as POC, through which the majority of migration uses cases will be addressed. POC will help in refining target application and infrastructure architectures.

Cloud Infrastructure and Security Design: This is very important part of design phase. This is about defining the technical landing zone of the target architecture. An example of an AWS landing zone will include network components like the number of VPCs, connectivity from the datacenter, inter VPC communications, subnets, Route 53, ELB, API gateway, etc. 

Compute and storages like EC2, EKS, ECS, RDS, SQS, S3 etc. Security components like IAM groups, users' groups, IAM policies, AD SSO for existing enterprise users, security groups and port controls at network levels. Define tagging (labeling) rules for components. Access control mechanisms for environments, including databases. Define the infrastructure using the infrastructure as a coding principle. Leverage new-age tools like cloud-native infrastructure creation services or cloud independent open sources like terraform. Design the integration with DevOps tools to easily create and destroy infrastructure. This design should address below areas:

Cloud infrastructure components and services; Integration layers; Bigdata and analytic components (if applicable); Network Connectivity; Hybrid cloud network connectivity topology (define location/region-wise connectivity to data centers and external clouds); High Availability design; and disaster recovery approach.

What a Security Architecture Should Address: Access and identity management (e.g. AD integration, AWS account and organizations); Security controls and process of accessing environments/applications and databases; Security auditing and monitoring (e.g. SIEM integration); Data security and encryption; and Assessment of vulnerability/patch management process.

Cloud Operating Model: Cloud operating model is all about how the organization will implement it's cloud transformation. It consists of people, processes, and tools. "People" are critical in driving the successful cloud programs. 

Identify stakeholders, team structure, and roles that are aligned to cloud business office, business /domains, operations, security and DevOps. Identify application and data governance processes and policies. Identify compliance requirements and ways to address them. 

There can be strategy to either create centralized, de-centralized or shared operating models. De-centralized operating is the preferred model, as it provides more agility and cost management. However, there could be other limitations of such model. For more details, refer to Azure documentation on operating models' comparison documentation.

Change Management: Cloud transformation requires adapting to changes in process technology and tools. There will be changes in governance and infrastructure controls. Address the new changes required in different roles that existing teams might have to take-up. Plan for re-skilling and cloud training for staff. Create a plan for addressing gaps in new required skills. 

Cloud migration is mainly a technical change. Many organizations involve a changing of the advisory board (CAB), which is responsible for reviewing and approving such transformation changes. The traditional CAB approval may pose a hindrance for migrations unless the right engagement was done with stakeholders well in advance. It would be worthwhile to consider enterprise change management tools ( e.g. ServiceNow, BMC, Jira Service desk, Freshservice, etc.) for governing and controlling the overall cloud migration process. 

There are tools available to complete access control the environments, provisioning, billing/cost controls, security monitoring, incident management, release management, and change management and approvals process. Alternatively, use cloud-native services, such as AWS Config, CloudTrail. The service catalog, AWS console, AWS Organizations, trusted advisor, etc. ) along with enterprise tools to achieve these tasks.

3. Next Steps

The next step is "Migrations and Transformation." Deploy POD teams, migrate applications and data as designed, and plan in previous stages. The "Manage and Optimize" stage is about managing ("RUN") infrastructure, applications, and data post migrations on the cloud. We will address the detailed implementation process, monitoring, and cloud operations in the next article.

Useful Links