An approach to cloud transformation and cloud migration
Overview
Ongoing COVID 19 pandemic is creating new challenges to almost all industries. It is causing significant impact on business and operating models. Organizations are rethinking on “how to make business resilient for such a large disruptions”, “ how to innovate faster and enable new business services to customers”, “how to reduce TCO” and “how to enable better connectivity & collaborations”. Such challenges existed before the pandemic era as well, but have become more relevant and important now !
Businesses that have already embarked their cloud journey have shown greater resiliency and responsiveness to this pandemic. In near future, it’s expected that cloud adoption will significantly increase across industries with combination of different cloud service models (SaaS, PaaS, IaaS) along with hybrid and multi cloud topologies. Cloud hosting will become new essential IT service for businesses.
A well-defined approach for cloud transformation is expected to realize business goals, cost savings and strategic benefits. This article will briefly outline the elements of a typical approach for application cloud migration, modernization and transformation . Article combines portfolio rationalization methods that can identify potential savings by reducing spend on non- valuable portfolios, along with cloud migration methods to realize the benefits of cloud. This article would explain methodical approach for a successful cloud transformation.
Typical cloud transformation project can have following 4 phases . Depending on the current transformation stage of an organization, applicable phases must be applied..
· Strategy and Portfolio Assessment,
· Design & Planning
· Migration & Transformation
· Mange Operations & Optimization.
This article will focus more on first two phases i.e. “Strategy and Portfolio Assessment” and “Design & Planning ”. Below picture depicts a cloud migration approach that is elaborated in this article
1. Strategy & Portfolio Assessment
Objective of this phase is to assess the organization readiness to cloud, define cloud strategy ,conduct an application portfolio assessment and define target disposition.
1.1. Cloud Strategy:
Before arriving a cloud strategy, It is important to understand the organization’s current business objectives and priorities, current IT landscape, ongoing transformation initiatives and technology strategies.
· Define a cloud objectives aligned with organization vision, business & IT strategy. Define how cloud will enable the organization to meet its business objectives or new capabilities.
· Define the primary purposes of adopting cloud. For e.g digital transformation, data center exit, legacy modernization, replacing legacy technologies, launching new business services, improving agility, capacity bursting, cost reduction, improving resiliency, responsiveness, flexibility or operational efficiency. Define KPI metrics with tangible and intangible benefits for these objectives
· Define the process method for cloud migration and transformation. For e.g Piloting before implementation to address diverse set of workload scenarios, preference of migration in short sprints over ‘Big Bang’ approach.
· Define the cloud decisions with rationale, impacts and benefits .Some of such decisions mentioned below;
§ Decision on selection of cloud service providers (AWS or Azure or GCP). Define the cloud topology if its ‘private’, ‘hybrid’ or ‘multi-cloud’. If its multi-cloud strategy, define the rationale for selection of different clouds and what type of workloads can be placed against different clouds (e.g. Analytics on AWS and legacy servers on Azure or vice versa).
§ Decision on container platform and containerization strategy.
§ Cloud service model preference selection for an application — e.g. SaaS is preferred over PaaS ,then CaaS ( container as a service) and then IaaS being a last option.
§ Define what cloud services ( IaaS/PaaS) are approved for usage against each cloud service provider. Serverless computing features (e.g Lambda/Azure functions) may not be approved as an enterprise strategy due to various security reasons. Define process of approval in case of using such new cloud services .
§ Define any decisions taken or under considerations for replacement for packaged software or any enterprise applications using SaaS or COTS platforms.
· Define cloud adoption principles- E.g. enforcing standard technology stacks for migrations, applying DevOps principles , self -service and cloud brokerage principles .Portability principles to avoid vendor-lock in. For example enforcing Kubernetes based PaaS container platforms to support portability between clouds. “Infrastructure as code” principle to make deployment work on any clouds. Choosing cloud agnostic databases than native database. portability options between clouds (e.g. AWS to Azure or Azure to AWS).
· For data migrations like data warehouses or Big data & Analytics platforms, a detailed data migration strategy is required either by using cloud native or new age COTS data platforms.
· Define platforms for multi-cloud integrations ( e.g. using iPaaS and API gateway platforms).
· High level cloud migration and transformation timelines.
· High level change management process like new roles, new skills, change in deployment process, additional tests that may be required ( e.g. security/penetration's testing)and training needs for new cloud skills
· Define cloud adoption constraints ,risks and mitigations to enterprise — e.g Data security & regulatory constraints and impact due to ongoing strategic initiatives. IT service provider’s exit criteria’s like cloud subscription/account ownership transfer process. Cloud service provider exit criteria.
· Define cloud governance guidelines and guardrails- i.e. Rules and guidelines for meeting regulatory & compliance process, security guidelines, cloud migration project approval process , operation guidelines and cost management.
· For datacenter exit strategy, define high level data center (DC) decommissioning process
Cloud Strategy is evolving document. Many times various ambiguities would exist in the beginning. This strategy gets more refined during design & planning exercise.
1.2. Application Portfolio Assessment:
Conduct an enterprise wide application portfolio assessment. This is required for defining enterprise wide transformation strategy. If such exercise is already carried out then leverage these artifacts for further analysis. If entire organization is not ready for cloud, then plan for conducting assessment of applications of a business units that are ready for cloud transformation. There are 7R strategies for a migration. These are Rehost, Replatform, Refactor, Rearchitect , Replace, Retain and Retire. The outcome of assessment phase is to provide one of the 7R strategies mapped against applications.
Applications need to be assessed from both top-down & bottom-up approaches. This phase involves gathering required application details by conducting workshops and by capturing responses to set of questionnaires from various application stakeholders. Application and Infrastructure attributes can also be gathered from configuration management database (CMDB) or from existing Enterprise Architecture (EA) repositories. It’s all about “knowing the current IT estate” of an organization. For enterprises having large IT footprint, it is advisable to leverage automated application & infrastructure discovery tools for getting required attributes and application details.
Below table provides brief description of 7R’s. Post analysis, application may fall into one of these disposition categories.
Identify Life cycle status of an application. Filter the applications and infrastructure from the assessment list that are ‘planned to be retired’ in near term or that are already ‘decommissioned’ from further assessment..
1.2.1. Data Gathering:
Gather the attributes for below categories for each application.
Application Attributes: Create an inventory with basic applications attributes like functionality, life cycle status of application , business capability, supporting business unit, hosted location/geography, type of application ( web/batch/middleware/transactional/analytics etc.), Any planned upgrades or changes expected in near future.
Business Value attributes: How important this application to business in terms of revenue generation or providing analytics report or for supporting operations. Capture Factors such as alignment to business strategy, current benefits, business criticality , redundant/duplicate functions of this application that exist in other apps , number of users, time taken to release new feature (agility), differentiation factor for organization, user satisfaction, level of automation in this application.
Total cost of ownership — such as cost of maintaining an application, Infra costs, licensing costs.
Technical Value Attributes : Alignment of application to technology strategy, Technical debt and performance of application, ease of supportability, ease of integration, meeting modern technology standards, current state on meeting non-function requirements ( NFRs) like modularity, extensibility, scalability, portability, accessibility , maintainability, response time, recoverability, availability, performance ,development & deployment methods, quality and accuracy of data produced.
Risk & Compliance attributes: Data privacy ,security and regulatory requirements .Such as data confidentiality levels, data encryption requirements, application security requirements, organization constraints, local/regional regulation requirement like HIPPA, GDPR, PCI-DSS etc
Cloud amenability (readiness) : Check technical feasibility of moving this application to cloud. Factors such as, if the application has hardware dependency (appliance) or operating systems (OS) that are not supported in cloud. If it’s Packaged COTS app, check for supportability on cloud. Is application using legacy technologies like COBOL, C,C++ etc or its using modern technologies. Check for database supportability on cloud. Hosted location i.e. if its hosted in- house or third party datacenter.
Complexity: Complexity that can impact migration to cloud. Factors like distribution of application, configurations, number of hosts, database size, interface technology, number of interfaces ( both inbound and outbound) , topology/clustering requirements, load balancing needs, code complexity , ease of doing build/test /deployment, usage of legacy technologies.
Many IT firms and cloud service providers ( AWS/Azure/Google) provide free tools for automated application discovery & assessment .However manual interventions and interviews are still required to capture certain attributes for defining right dispositions strategy
1.2.2. Analysis:
It is important to know the organization cloud strategy which can have influence on dispositions. If an organization has a data center consolidation or data center exit strategy within very short term, then ‘Rehost’ and ‘Replatform’ disposition could be 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 supported container technology stack ( e.g. kubernetes/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 cloud for building new capabilities like data lake, analytics and machine learning. 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 above view, Rehost /Replatform strategies are having low risks, less migration efforts ,but have less 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 need 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 organization 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 , redundant applications that can be merged or replaced , Applications or datastores that are too expensive to run.
Based on scoring of business values, technical value and cloud amenability , create various analysis models like ‘TIME’ model ,Benefits vs Ease of migration,’ ‘Technical Value’ vs ‘Business value’ . This analysis 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
1.3. Disposition and Recommendations:
Create decision tree and apply the values from above charts to arrive at target cloud disposition. E.g. 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 rehosting on low cost infrastructure. Apps with very high business benefits but having low technical value (i.e high technical debt) can be considered for replace, 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 a standardized scoring values and rule sets for fastening the analysis process. Sample decision tree is shown below.
At this stage it may be useful to provide 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 long term strategy can be to rearchitect using server-less compute .
1.4. Business Case:
Once the high level assessment is done, conduct high level cost benefit analysis for applications. Based on the on premise infrastructure run cost , depreciation and infrastructure operations cost, determine total current run cost of application . Get the expected spend in next 3 to 4 years. Based on the disposition of the application and database, create 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 target cost . Cloud investment will usually get realized in 2 to 3 years of time. Compare the cost of hosting on different clouds. Cloud provider’s online TCO calculators/Monthly spend calculators can be used to arrive the costing. Include the added intangible benefits like agility, elasticity, flexibility and scalability features as part of overall business case.
This business case exercise will provide the business owners & CxOs a decision points for initiating cloud projects. It is also important to include cloud optimization exercise once the application and data is migrated on cloud.
1.5. Cloud Business Office:
For a 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 & compliance and enterprise architects who would drive ,accelerate and enable cloud transformation .CBO objectives is to define transformation goals & objectives, driving cloud strategy across organization, providing budgets, architecture standards, change management, 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 function or unit can also be called as Cloud Strategy office ( CSO) or COE ( Cloud Center of Excellence).
2. Design and Planning
In this phase, detailed assessment of application is performed and 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 tool e.g .NET portability Analyzer/ Porting Assistant for .NET etc . There are also tools like AWS App2Contaner which can even containerize apps and deploy on container platforms. Analyze the functionalities and code for rehost , replatform and rearchitect 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 webapps 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 by right sizing the migration efforts. Define Migration team structure and identify the right size of team by splitting into Tribes and Squads. Some organizations may call them as PODs structures. Define the life cycle stages for migration, testing and Cut-Over plans for applications. Successful migrations will create templates for moving remaining apps. Modernizing applications (rearchitecting or refactoring) may require more time and long term strategy . Apply DevOps and Agile methods( e.g. Scrum, SAFe ) for migrations.
Target Architecture : Define Target deployment architecture for the applications, data and network components. Since the migrations are planned in agile fashion, its important to define the architecture (Minimum Viable Architecture) that is simplistic but adequate enough to implement the migration. Define the target technologies, software /OS versions and database versions that existing application 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 stake holder’s buy in for such decisions. Design an architecture with high availability, load balancing and performance with “fit for purpose” principle. After all, cloud is built for scalability and availability , hence avoid over-engineering. Sample hybrid cloud Architecture is represented below.
DevOps : DevOps has become 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 the architectural decisions. Such applications can follow existing methods of build & deployment on 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 captured and tracked ( e.g. using tools like Jira) . Define the various environments that existing application 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. Weather it’s a migration of application or data warehouse, piloting the migration in cloud environment will give the confidence, new learnings and help in overcoming challenges. POC will help in identifying issues and gaps based on current organizational process, connectivity and environment dependencies' .Apply DevOps process and tools while migrating. Pickup medium complex rehost and refactoring use cases as POC with which majority of uses cases are 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 technical landing zone of target architecture. Example for AWS landing zone will include network components like number of VPCs, connectivity from 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 database. Define the infrastructure using Infrastructure as code 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 & services; Integration layers; Bigdata & analytic components (if applicable); Network Connectivity; Hybrid cloud network connectivity topology (define location/region wise connectivity to datacenters & external clouds ); High Availability design; Disaster recovery approach.
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; 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 consist of people, process 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 process and policies. Identify compliance requirements and way to address them. There can be strategy to either create centralized, de-centralized or shared operating models. De-centralized operating is preferred model as it provides more agility and cost management. However, there could be other limitations of such model. For more details refer azure documentation on operating models’ comparison documentation.
Change Management: Cloud transformation requires adapting to changes in process technology and tools. There will be change 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 technical change. Many organizations involve change advisory board (CAB) which is responsible for reviewing and approving such transformation changes. The traditional CAB approval may pose hindrance for migrations unless right engagement were done with stake holders well in advance. It would be worthwhile to consider an 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 completely 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. Service catalogue, AWS console, AWS Organizations, trusted advisor etc. ) along with enterprise tools to achieve these tasks..
3. Next Process
The next step is “Migrations & Transformation”. Deploy POD teams, migrate applications and data as designed, planned in previous stages. “Manage & Optimize” stage is about managing (“RUN” ) infrastructure, applications and data post migrations on cloud . Will address detailed implementation process, monitoring and cloud operations in next article.
Useful Links
https://d1.awsstatic.com/whitepapers/cloud-migration-main.pdf
https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/organize/cloud-center-of-excellence
For further information on this article contact: https://www.linkedin.com/in/sandeeptol
