Accelerating Application Rationalization

If there is a single migration obstacle that slows delivery, I would offer up application rationalization. The cloud readiness assessment of applications across the enterprise can often be time consuming, complex, and inhibit migration velocity. The question then becomes, how can we accelerate migrations without impacting quality and maximizing cloud native capabilities?

How many R’s are there in Rationalization? I have heard 4, 5, 6 R’s over the years but I can tell you that to cover all your basis I land on 6. Rehost, Refactor, Rearchitect, Rebuild, Replace, and Retire. See below for some quick definitions.

·      Rehost: Migrating applications as-is with no modifications or code changes. Typically, an IaaS shift and often focused on COTS Applications.

·      Refactor: Minimal code changes to rewrite or repackage code to use cloud native services and / or PaaS offerings.

·      Rearchitect: Modifying application functionality through code enhancements to utilize cloud native services.

·      Rebuild: Building net new greenfield applications using cloud services.

·      Replace: Replacing an application with SaaS offerings.

·      Retire: Retire and application when the core capabilities are unneeded or duplicated.

Now that we have outlined some common terminology it is time to dive into our application assessment. I break application rationalization down into six sections: application discovery, application engagement, application assessment, application decision matrix, application portfolio, and application migration. I know this may sound like a lot but stick around and I will break it down to some more manageable levels.

·      Application Discovery: Prior to migration we need to conduct an inventory of our digital estate but how do we conduct an inventory of our application portfolio. 1st: review your CMDB for accurate configuration items (CI). 2nd: review your Application Portfolio Management (APM) system and if one does not exist, you can still move forward but it may become a little more difficult. 3rd: align your CMDB with your APM system to validate applications are aligned to CI’s. 4th: pull in all data from your 3rd party digital inventory scans.

·      Application Engagement: Next, we need to get to know our application owners and lead developers. 1st: reach out to your application owners and have them validate APM data and key personnel. Preferably, business owner, dev lead, test lead, and infrastructure lead. 2nd: conduct app owner interviews to gather all remaining information. Keep in mind, you can stagger these interviews across your high-level migration plan.

·      Application Rationalization: The application rationalization phase can be founded on key data inputs. 1st: at Finopssp, we use an Application Complexity Assessment Matrix. This matrix pulls in multiple data sets such as complexity, business impact ((Recovery Point Objective (RPO) and Recovery Time Objective (RTO)), risk, testing requirements, database compatibility, and 3rd party integration scans. 2nd: we want to begin our rationalization assessment. This process follows a sequential questionnaire that deduces applications into 6R buckets; based on question progression from rehost, refactor, rearchitect, to rebuild.

·      Application Decision Matrix: Now that we have conducted the majority of our analysis, how can we use this information to build a plan? At Finopsp, we compile this data into an Application Decision Matrix based on a high, medium, low point system aligned to weighted categories. We finally have our initial Application Migration Portfolio outlined from least complex to most complex. Why do we want to build our migration portfolio in this manner? 1. This allows internal staff or 3rd party vendors to gain comfort with the cloud platform and services. 2. We can test security controls and cloud environment design in a managed environment. 3. We can methodically integrate our DevOps and CI/CD processes to fully maximize the cloud native service offerings. 4. We can test data ingress and egress flows on apps with lower complexity.

·      Application Portfolio: Our application decision matrix has built us an initial list (let us say 200) of 200 applications based on complexity. We cannot rely on this information alone to optimize our migration plan. 1st: get moving. Select your first 10 – 15 applications for migration while we assess the remaining categories. Focus on rehosting and COTS applications to get rolling. 2nd: look at the following use cases to refine your migration plan. 1. Capital Cots Avoidance: Do you want to maximize your cost savings by avoiding large capital investments in hardware and other technologies? Focus on storage arrays, backup systems, virtual desktop infrastructure, and disaster recovery. 2. End of Life (EoL) Optimization: Target your EoL assets and OS. Focus on EoL assets in Non-Prod and applications with limited integrations. 3. Environment Readiness: Look at migrating Dev, Test, environments to test data flows and cloud services.

·      Application Migration: Now that we have built a logical migration portfolio, we can start to optimize our migrations. This phase has different levels of maturity per organization, but focus on refining your DevOps processes, CI/CD pipelines, release management, ITIL / ITSM integrations, and FinOps standards. Start to hone your best practices and standard operating procedures (SOPs) to optimize a cloud first mentality. It is imperative to enhance your cloud first operations at the enterprise level.

• Cloud Foundation
• Cloud Governance
• Cloud Migration Planning
• Cloud Operations
• Cloud FinOps

Building a data driven and logical cloud migration plan can often come off the rails and without proven processes and standards your progress can be greatly impacted. By utilizing the above application rationalization procedures, you can experience accelerations without impacting your quality control measures for cloud migrations.