Cloud Placement Organizer

A cloud migration results in a system being transferred from a source landscape to a target landscape. Often, during the migration, an adaptation of the architecture for the target landscape is also carried out, for example to eliminate technological legacies of the past. The so-called "6-R approach" is used for this:

• Rehosting (Lift & Shift): Cloning of the existing IT landscape
• Replatforming/Redeploying: Migration to a new technological basis
• Repurchasing: Change of product
• Refactoring/Rearchitecting: Rebuilding the application
• Retire: Deactivation of legacy systems
• Retain: Retention in the current state (no migration)

Typically, companies do not focus on just one of the 6-R approaches when migrating to the cloud, but often choose a combination depending on the expected technological challenges.

Often, the vast majority of applications and systems are migrated using the "rehosting" approach, as this is usually the most cost-effective variant, which also involves few technological dependencies. This strategy is supplemented by replatforming or redeploying approaches in order to be able to carry out the technological modernisation for some of the application components.

The most rarely used variant is the refactoring/retrieving variant, as this involves an elaborate new construction of the app. Although this helps to profit from the greatest cloud benefits, it is associated with high costs in the short term.

The Cloud Placement Organiser already brings a number of mechanisms to identify and suggest the ideal migration strategy depending on the system and app.

The cloud consists of a network of servers that bundle resources such as storage. The difference between the public and private clouds is primarily that in the private cloud the resources of the underlying IT infrastructure are exclusively available to one company, while in the public cloud several companies share the use ("shared infrastructure").

The public cloud is provided by an external service provider, a so-called cloud service provider. The service provider procures and operates the IT infrastructure so that many of its customers can consume the IT services. This is an IT environment shared by several customers. Public clouds are characterised above all by a very high level of functional diversity, which can often only be replicated in the private cloud at great expense.

The private cloud is often operated by companies themselves - sometimes also by external service providers - on their own. The company procures and operates the IT infrastructure and consumes the IT services exclusively itself, without third-party users such as other companies using the same IT infrastructure. This makes the private cloud particularly suitable where companies have a particularly high need for IT security, as the cloud is not shared with other users.

A hybrid cloud helps to combine the advantages of both cloud types - public and private cloud. In this way, a company can use the functional diversity of the public cloud, but use the private cloud for individual selective servers and apps if there are special requirements with regard to security. However, a prerequisite for efficient use of the hybrid cloud is precise planning of which systems and servers are to be operated and used in the private or public cloud. This is the ideal way to combine the advantages of both worlds.

The most common requirements for the cloud come from the area of IT security. Companies with a high security requirement for particularly critical systems prefer the private cloud because it runs on the company's own systems and no other companies also use the systems. Other aspects in the decision-making process can be the costs incurred, any technical restrictions or the use of a provider's particular technical strengths.

1. Clear strategy for the use of private and public clouds

Since both private and public clouds often offer a similar portfolio of services, it should be clearly defined for which application purposes the respective cloud type will be used. This ensures that there are no discrepancies in the planning process prior to migration.

2. Very good knowledge of the IT landscape

The systems and apps to be migrated should be sufficiently well documented to be able to adequately consider them in the planning. This includes documenting the amount of servers and apps, the responsible persons in the company and the business criticality, as well as technical documentation. The better and more extensively a system is documented, the fewer technical and organisational hurdles can hinder the migration.

3. Determining the scope of the migration

It should be determined prior to migration which systems and apps will be migrated to the cloud in each case. The selection can be made according to business units and processes as well as geography and lifecycle status of the respective systems. This approach ensures that the migration scope is clearly outlined and that the scope does not change unscheduled during the migration process (so-called "scope creep").

4. „Start small, think big"

A cloud migration is a complex undertaking. Since there is often little experience at the beginning of a migration, it is advisable to start the migration with a few and non-critical systems and apps. On the other hand, planning should be sufficiently long-term and anticipate an increase in migration speed to be able to migrate even large landscapes. In this way, it is possible to start with a low risk at the beginning and keep the migration risk limited in the further course of the project.

5. For mass migration: Use of a Migration Factory

A cloud migration is largely an individual project. Even if every system and every app functions and acts uniquely, recurring activities such as testing the systems and apps can still be bundled. It is advisable to set up a so-called migration factory, which has the task of centralising standardisable tasks and at the same time giving the cloud technicians flexibility to solve special issues.