Skip to main content

Cloud-to-Cloud Transformation

Txture is known for covering well the on-premise-to-cloud transformation use-case, still our customers are increasingly taking the next step and migrate between hyper scalers such as AWS, GCP, Azure and others or modernize existing cloud landscapes. This leads to an entirely new set of hurdles that can be tackled using the Txture Cloud Transformation toolset.
This part of the documentation outlines some of the typical steps undertaken in such a cloud-to-cloud transition and how to use Txture to help along the process.

Note

The process for Cloud-to-Cloud transformation is equal to the On-Prem-to-Cloud process in many areas. Therefore, it is advisable to taking a look at the documentation of the on-prem-to-cloud transformation first.

1. Initial considerations​

Cloud-to-cloud transformations have two main drivers. First, optimizing cloud costs and second, modernizing existing IaaS landscapes that have been initially lifted, and shifted.

Txture offers a robust set of features that help to identify cost saving potentials and options for modernizing existing cloud landscapes.

As most of these features are available from our Software-as-a-Service offering, it is often advisable to make use of this deployment option in a cloud-to-cloud transformation.

2. Gathering data​

Given that the landscape is either hybrid or completely located in the cloud already, the main data source will be the resource APIs of the cloud providers in use. Txture offers a range of data sources that span both on-prem technologies and the cloud world. It is suggested to implement a connection to the existing provider(s) using one of these data sources. This will allow importing most assets that are currently present and therefore create a transparent landscape overview.

Data collection via cloud provider resource APIs typically happens via programmatic access credentials. Txture does not scan the content of, e.g., managed cloud databases or blob stores but needs to find out about cloud services, their dependencies, sizing, and configuration. Read-only credentials should be obtained for such data collection tasks. As an example, see how to set up for importing from AWS.

Depending on the migration goals, it might be useful to augment the mere infrastructure information with more high-level data from an enterprise architecture point of view or even other costing information. A key point here is that Txture is application-centric and requires a mapping of assets to individual applications. This provides the boundaries for individually evaluating expected cost or target architecture options.

Therefore, it is highly recommended to import at least a minimal set of information for all existing applications. If such a catalog does not yet exist, we recommend creating one during the process as it is considered best practice. Leveraging Txture's survey functionality, a holistic IT landscape picture can be created during the process that will simplify future transitions and compliance requirements.

3. Business Case Calculation​

In many cases, infrastructure such as virtual machines (and container runtimes), managed databases, storage, and networking capabilities are the main cost drivers with roughly 85% of the cost stemming from these products. Other services like Functions-as-a-Service (FaaS), AI training or inference, or management infrastructure (key management, logging) account for the rest but only play a minor role in cost estimation. It is, therefore, often a reasonable approach to calculate infrastructure costs for different providers and use the results for calculating the business case of a cloud-to-cloud transformation.

Txture's target architecture proposal engine is well suited to estimating prices for a business case calculation. As mentioned above, Txture requires assets to be linked to applications for a target architecture. The stack created by linking the individual components to form an application can then be compared for different providers.

If absolutely no application portfolio is available, it is recommended to create one or more placeholder applications and link assets to these. One option for choosing such a placeholder application could be the deployment environments (dev, test, staging, production etc.), but different business units or subsidiaries have been a common practice for creating initial resource groups.

Immediately upon linking assets to applications, the transformation cockpit will display target architecture proposals for any selected provider and allow for comparison between different proposals. Of course, providers and optionally any applicable discounts can be configured for these calculations.

For more advanced comparisons (e.g. with existing costing information), Txture offers advanced scripting capabilities in the form of propagation rules. This feature allows e.g. to accumulate individual infrastructure asset cost to derive an as-is TCO on application level for further cost comparison. In combination with the flexible structure and advanced reporting capabilities arbitrary costing calculations can be performed within Txture.

Below see such a costing report that associates as-is and target cloud cost via a derived cost savings value.

4. Cloud Portfolio Modernization​

In addition to the comparison of costs between different cloud providers, the modernization of the as-is cloud portfolio is another use case of a cloud-to-cloud transformation.

Once the components of the existing cloud portfolio have been imported into Txture, in addition to the direct replacement of individual components of the same type, completely new proposals based on a different deployment model can be calculated. Existing IaaS architectures can be compared with architectures enriched with CaaS or PaaS services.

The example below shows again the same example applications including PaaS databases and Kubernetes services instead of the original virtual machine deployment.