Making a cloud application portfolio assessment

To compete in today’s game, organizations must ensure cloud plays a vital role in their strategy. Many organizations are also currently moving to the cloud because of its scalability, economy, enabler of innovation and reach. However, migrating to the cloud takes more than just packing applications in a box and unpack them in the cloud. It means making strategic decisions about cloud landing zone architecture, compliance issues of using public clouds, new ways of working for IT-operations and development (DevOps/DevSecOps), enable agility for development teams and still be in control around Compliance & Cost Control and (re-)establishing a governance model around SOC and  CCoE. It usually starts with an Application Portfolio Assessment, which this blog shortly describes a process for.

Insights into your application portfolio is crucial for a successful cloud migration. The best way to go about this is to do an assessment of each applications in order to determine cloud readiness, dependencies, business criticality and outline the best migration path (6Rs).

I would also like to emphasize that cloud migration is not only a technology and IT-project. It most inevitably need organizational changes and adaptions of processes, checks and balances as well as user and employee acceptance. I will not go into details on these aspects now but recommend bearing them in mind, that moving to Cloud & Cloud Native operations, requires a changed mindset from most OnPremise IT operation teams.

When we perform an application portfolio assessment, we analyze the code thoroughly and review all layers of the code, to understand which part is Cloud-ready and to highlight Application monoliths within the clients IT landscape.  We also do data workloads analysis to fully understand dependencies between applications and understand workload in peek-periods – e.g. over a business month closure.

Typically, your application assessment will provide you with categorization of all applications in five different buckets; rehost/replatform, refactor, replace, retain and retire. This is essential to give you full overview of all your applications and what it takes to migrate them to the cloud in an efficient way that does not violate critical business processes.

• Rehost/Replatform
  This category supports a Lift&Shift migration strategy. You can typically use cloud vendors out-of-the box tools for doing this type of migrations. 
• Refactor
  Refactoring requires code-changes, for the application to work. Applications can be split into two main transformation approaches:
  • Small & medium applications that with limited code-changes can be cloud ready fast and migrated often.
  • Large & x-large monolith applications, needs a dedicated cloud migration roadmap, where application-modules one-by-one typically are moved to a containerized microservice architecture with principles of encapsulation and separation of duties. Typical huge ERP systems falls into this bucket.
• Replace
  In this category you will find the applications that clients do not want to migrate, either from a business perspective or from a technical perspective – typical applications with a lot of technical depth. There are many ways of replacing applications, e.g., using SaaS. An existing OnPrem application monolith, is typical going to be replaces over time, gradually moving functionality and business services out to independent services.
• Retain
  Some applications are not meant for the cloud and should therefore not be migrated to the cloud. You simply have to retain them on-prem. For applications you choose to retain, focus on ensuring that they work smoothly with the rest of the portfolio that you will now host in the cloud. Integration is the top priority for this category, and you might need to upgrade your network to reduce latency between cloud and OnPrem data centers.
• Retire
  My experience is that you often end up with a set of applications you can and want to retire. This is especially true if you have replaced some of your applications. It often turns out that the new applications you have chosen, have features that overlap some of your old applications. This means you simply get rid of a set of old applications that is not necessary any longer.

Having gone through this exercise with all your applications, you will have a better overview of your scope of migration, cost for consumption, dependencies between applications, input to a roadmap for migration and an idea for migration waves based on Business Criticality and Dependencies for each application.