Mapping your application landscape - a quick guide

Mapping your application landscape – a quick guide

Written by: Koen van Schijndel

In the previous blog you read that a good Cloud transition starts with packing your suitcase smartly. Or in technical language: the better you think about your future IT situation, the smoother the migration and the more favourable the end result. But then it comes. Because how do you properly arrange that preparation? As far as we are concerned, everything starts with mapping your application landscape. Because if you know what you have in place and what the ideal location of your applications would be, you’ve come a long way. In this blog, therefore, you will read how to map your application landscape using a clear roadmap.

Landing sites by application

Mapping your application landscape starts with listing all existing applications and determining the best landing site for each individual application in the new situation. After all, there are more flavours than “Cloud” and “no Cloud.” For example, you can choose to migrate applications to a Public Cloud, a Managed Public Cloud or a Private Cloud. You can also turn off an application altogether because you no longer need it after the cloud migration, or replace it with a SaaS product. Thus, if the SaaS product serves the exact same needs as the application you replaced, you still benefit from all the functionality of the application, but the vendor takes over management and maintenance from you.

There is no right or wrong (or wait, there is)

Which landing site fits best simply depends on the application. After all, a Managed Public Cloud is not necessarily better than SaaS. There is such a thing as a mismatch between your cloud strategy and your company’s goals. Suppose you are working with an application that sets you apart from your competitors. In this case, you want to keep the development and management of that application in-house as much as possible because you know the application best and may already be working in a DevOps fashion. If you then choose to completely outsource the management of this application, it can lead to a lot of frustrations. For example, your vendor may not know how to keep your application available, and you’re paying for something that you still end up having to do yourself. The opposite is also possible: if your strategy dictates that you outsource as much management as possible, you may want to let a vendor take over as many tasks as possible, or purchase applications as SaaS products.

While your new application landscape depends on your business goals, you don’t have to reinvent the wheel. Based on the roadmap below, you will gather useful information that will help you determine the ideal landing site:

Step 1. Distinguish mission-critical applications from non-mission-critical ones

With each application, ask yourself whether it is necessary to keep the operation running. Is the answer yes? Then you are dealing with a mission-critical application. Think about your ERP system and customer applications. If you turn it off, (part of your) organisation no longer functions and thus you suffer damage. Mission-critical applications are therefore best placed in an environment that ensures they can deliver always and stably.

Examples of non-mission-critical applications are experiments or new customer apps that are not yet live. This type of application requires flexibility above all else. Because developers are still tinkering with the applications, you need a lot of computing power and opportunities to scale up if the apps prove to be a success and you want to make them available to a wider audience. At the same time, you must also be able to easily turn off environments if the experiments prove unsuccessful.

Step 2. Distinguish applications with distinctive capability from non-distinctive applications

The second question you ask yourself is about the distinctive capability of the application. Do customers buy from your company because you work with this particular application? Then the application contributes to your differentiation and it is important that you can continue to develop it after the cloud migration.

Applications that don’t necessarily make your service unique include scheduling systems, and accounting packages. You’d rather not manage these types of applications yourself, especially since Cloud Service Providers often do a much better (and cost-efficient) job of it. After all, they provide these services to thousands of companies at once.

Step 3. Determine the landing site for each application

In steps 1 and 2, you distinguished mission-critical from non-mission-critical applications and business-unique applications from standard applications. In step 3, you determine the best landing site for each application. For this, you can choose from five flavours:

Managed Private Cloud
Public Cloud
Managed Public Cloud
Replaced by SaaS
Turf off

Depending on your business goals, you are now going to classify your applications into these five groups. For example, you can turn off (offload) applications you no longer need after the cloud migration and start buying non-mission-critical and non-distinctive applications like accounting packages as SaaS. In doing so, keep a close eye on the business objectives. For example, do you want to keep many applications in-house because of their distinctiveness but want lots of computing power and development capabilities? Then a Public Cloud is a suitable option. Instead, do you want to outsource as much as possible to free up your hands for other things? Then choose to purchase many of your applications as SaaS.

Step 4. Create groups by application (clustering)

Setting aside for a moment your redundant applications, you now have four groups of applications. These applications share similar characteristics (e.g., mission-critical but not distinctive) and thus form a cluster. For that cluster, you then determine what needs to be done. Convenient, because that way you don’t have to migrate your applications ad hoc, but work with groups of applications that match or even overlap. You can also monitor for each cluster what the migration burden is going to be. For example, how complex will the transition be and how long do you expect it to take? Based on this information, determine quick wins (light applications that you can migrate quickly and that also create value quickly) and create a schedule. The infographic below is useful in this planning.

Next steps: plan your cloud migration

Hopefully, after reading this short guide, you will know how to map and prepare your organisation’s application landscape for cloud migration. But how exactly do you set up a migration plan? In the e-book below, we share a comprehensive roadmap so that you don’t migrate for the sake of migrating, but use the Cloud as a tool to become a Digital Enterprise.