Skip to main content

Cloud Assessment: A step-by-step guide

This document is designed to give you a insights over the steps that need to be carried out when executing a cloud transformation with Txture. Depending on the scope of your cloud transformation, not all steps might be strictly necessary. For example exact server data might not be required when simply conducting a high-level cloud readiness assessment for a set of applications.

The two main use-cases of Txture in the cloud context are:

  • Assessments: This corresponds to the Assessment tab of the Cloud Transformation Cockpit and comprises gathering enough information about all applications to decide whether they are in scope for a transformation to the cloud and which strategy to use. Txture uses a rule-based approach to assess applications and their readiness for the cloud. These cloud assessment rules evaluate applications, their properties, interfacing application and the deployment stack. This is done in order to determine multiple outputs:

    • Cloud Readiness of the application
    • Migration Timing to create the migration roadmap
    • 6 R's Migration Strategy (Rehost, Replatform, Retain, Retire, Repurchase, Refactor)

    Additionally, the cloud assessment rules will inform you about missing data (data completeness). This important so you know where more data needs to be collected to get high quality assessment and target architecture results.

  • Target Architecture Planning: Building on the 6R decision from the assessment phase, this phase goes into more technical depth and creates possible target architectures replacing the on-premise application with cloud technologies - possibly factoring in a feedback loop with application owners. Target architecture are provided on a technical component level suggesting IaaS, PaaS, CaaS and Saas replacements. Importantly Txture also generates the prices for each proposal and selected cloud provider.

Phase 0: Scope and Strategy​

This preliminary phase of each migration project is often underestimated, but should be taken very seriously.

  • The basic starting point for each assessment is defining the scope of the undertaking. In some cases it is clear that all application must be migrated to the cloud due to a strategic decision or external restrictions. In other cases the key challenge is finding applications that could possibly move towards the cloud and determining which of them could actually benefit from a migration (financially or otherwise).
  • Txture is meant to be a communication platform for all stakeholders in the cloud transformation project. It is key to identify all persons involved and provide them with (appropriately restricted) access to Txture. This increases acceptance of the projects and improves transparency. If you plan on using surveys, make sure you also create accounts for all recipients of the surveys.
  • Once the scope has been defined the logical next step is defining a rule set for assessing the applications in the context of the scope:
    • Txture comes with a large pre-defined rule set that has proven to be a robust assessment framework.
    • As previously mentioned, for some projects it is best to deactivate some of the rules. E.g. determining reasons to move to the cloud is unnecessary if all applications will be moved anyway.
    • As a best practice we strongly encourage customers and partners to align the selected rules with all relevant stakeholders. Depending on the project these stakeholders could be external consultants, IT management, enterprise architects or a number of other roles. We highly recommend to this in an early stage of the project in order to avoid miscommunications early.
  • If planning of target architectures is part of the project it is a good idea to define preferences for those now as well.

Phase 1: Data Collection​

Txture is centered around applications when it comes to cloud transformations. Thus, the key information to collect are application assets along with their deployment stack in the form of other assets. A typical example might look like this: Txture's structure allows different asset-types that each have different properties. So underneath this stack is a plethora of information in the form of property values. Typical properties include information about the application (business criticality, lifecycle information, etc.) and its deployment assets (RAM, Operating System, etc. depending on the asset-type). The goal of this phase is to collect all necessary information in order for Txture to evaluate the assessment rule set and calculate target architectures.

The typical approach contains three major steps with sub-steps for each of them. For most projects steps 1 and 2 will suffice.

(Semi-) Automated Data Collection​

This is the most important part of data collection as the ratio of data value to effort is the highest and it is therefore the most efficient process. It is usually worthwhile to spend some time in this step and tap into as many data sources as possible.

  • Identify possible data sources: frequently used sources include on-prem hypervisors, CMDBs, application lists, enterprise architecture tools.
  • Create data sources for each of these resources
  • Create asset and link-importers for as many asset-types (applications, virtual servers, stakeholders, databases etc.)
  • Check for data completeness problems in the Transformation Cockpit to see what is still missing and iterate over the previous steps.

Automated update scheduling

It is always preferable to integrate tools with frequently scheduled updates because the application landscape will change during the assessment and migration. This will lead to a continously up-to-date repository.

Survey-based data gap reduction​

In many cases, it is not possible to collect all information in an automated way. Reasons include lack of data, restricted access or scattered information, or the missing link between applications and the underlying tech-stack. If this is the case, the second most efficient way of collecting information is to tap into the large knowledge base application owners usually have. Such a process involves a lot of person-to-person communication and is therefore time-consuming. However, Txture helps you with collecting information in an organized and structured way by using surveys. Surveys allow you to define a set of questions that are sent out to application owners (or other relevant stakeholders) in an automated way. Recipients are guided through an easy-to-use UI and asked questions about their assets.

  • Review the activated rule set and check whether the rules still match the project scope
  • Identify the remaining information gaps using the Assessment Section in the Transformation Cockpit
  • Design a survey that includes questions that cover information gaps. Keep in mind that sometimes also previously known information can be displayed in surveys in order for recipients of the survey to review and confirm.
  • It is recommended to give survey recipients a reasonable time frame to answer the surveys: 2 to 3 weeks, depending on the number of recipients, have proven to be a solid time frame.

Most projects reach a reasonable information level at this stage. However, in some cases or for a subset of application it might necessary to proceed to the next stage for information collection.

Refining Information with the Help of Application Owners​

Txture allows three main modes of editing application information in interactive sessions with application owners.

Depending of the modelling activity either one of the options can be more useful.

Phase 2: Assessment​

The assessment phase of a cloud transformation project is often used to identify which applications are candidates for a migration, which applications are better retained and often also to identify applications that can be retired entirely due to their lack of relevance for the enterprise. After a successful assessment, Txture will allow you to report on the organization's application portfolio with regard to several cloud transformation aspects:

  • Cloud Readiness of applications
  • 6R strategy for each application
  • Estimated migration risk

For each application the assessment tap shows the cloud readiness, recommended 6R strategy as will the estimated migration risk. These are calculated based on the Assessment Rules defined in the Assessment Preferences. Here you can decide which strategy to choose and also comment and the selection made. You can base this selection based on the detailed rule evaluation you find lower on the page.

Warning:

Keep an eye on the the data completeness is shown here. If the data quality is medium or low, consider investing more time in gathering data in order to get high quality recommendations.

In many cases, also the communication dependencies of applications with one another are compiled for the first time. Txture's advanced reporting capabilities can help to visualize such information in a useful manner.

The exact steps in this phase of a cloud transformation vary from project to project, but typically include one or more of the following:

  • Establish a feedback loop with application owners to confirm results in Transformation Cockpit (particularly the strategy)
  • De-scoping of unsuitable applications
  • Advanced reporting to management
  • Export results to other formats (CSV/Excel, Images)

Phase 3: Target Architecture​

This advanced step requires detailed information about the deployment stack of applications. Of particular interest are technical details of deployment stack assets (virtual servers, databases, physical servers, etc.), such as technologies, sizing information (CPU, RAM, storage requirements, etc.).

Txture uses its Cloud Knowledge Engine to map on-premise technologies to suitable replacements in the cloud.

Warning:

Before considering and selecting a proposed target architecture make sure that the data quality is high and you have collected all necessary information about the sizing and deployment of the technical stack.

This mapping happens for all assets of a deployment stack while always taking into account other restrictions such as cloud preference settings, avoiding unnecessary technology mixing and the cost factor. The result of this process is called a Target Architecture proposal and contains of the initial assets and a migration action for each of the assets:

Even though the output of the preceding Assessment phase is one of the 6R, the Target Architecture section always shows proposals for all Rs (if they could be calculated).

Use-cases and steps for the Target Architecture include:

  • Cost estimation for the entire Target Architecture landscape
  • Reviewing and confirming proposed architectures with application owners
  • Advanced reporting on the technology mix for the Target Architecture landscape