There was a challenge I posed to the list called Moving Sale:

Continuing the theme of the week lets look at what prep work would be required prior to the close of the sale. In this case, Acme Inc. went in on the cloud software offering by offering Anvils as a Service, and this will be offloaded to Widgets Inc. as its own unit including about half the current employees working on the product. The product itself is also cloud based, but runs on a different cloud provider from what Widgets Inc. uses.

What common pieces would be impacted as a part of this carve-out, but would not be conveyed to Widgets Inc.? As a follow-up question, would you make the common pieces available, and if so, how?

The first part of the answer looked at the end user/employee aspect as common enterprise data where nothing else would be conveyed so it would be up to the acquirer to figure out how to integrate. The second part looked at the tech side of users not just as users, but also their underlying data.

Today we look at the third part for the answer and that is the applications themselves.

When it comes to the product, there are two pieces to keep in mind:

  • The infrastructure to build and host the application
  • The components that make up the application including third-party libraries and services

Whenever you are dealing with cloud providers that are hosting third-party services, then you will need to either have your own account, or find a substitute. If you opt to get your own account, then it is a matter of conveying/seeding the required data to power the application. This is the best case scenario. Even better if you already have an account with the same provider. The API calls will be similar as well as the data format for the most part. In some cases, such as CRMs or issue tracking, there is a lot of custom data/fields available, and the application may need to be modified to account for the new mapping.

The worst case scenario is when you are going with an alternate vendor. In these cases, you will be required to modify the dependent applications to handle the new API calls and translate the data to the new app. You can offset this slightly by creating a shim whether directly in the application code, or an intermediary such as an API gateway or a platform like Mulesoft.

When it comes to the hosting infrastructure, and you are crossing cloud providers (Azure vs AWS vs Exoscale vs Alibaba Cloud vs …), then the challenges become more nuanced: provisioning/de-provisioning scripts are usually owned and kept by the parent company so you will definitely need to craft your own just to provision the infrastructure. If the application build/installation process and even runtime are dependent upon the cloud provider, then some additional refactoring will be required.

After all, one of the biggest value adds to the cloud provider is the stuff they give you from object storage (AWS S3) to resource segregation (Azure) to CI/CD (Google Cloud). Unless you are running on just compute resources with nothing special, then there will be some modifications required.

What other things can you think of? Reply and let me know so we can keep the exchange going!

cab