More and more companies are choosing to run their applications in the cloud. Migrating an application to the cloud is a significant undertaking that requires careful planning and execution. In this blog post, we present a six-phase guide to cloud migration, illustrated through the example of migrating an application to a Software-as-a-Service (SaaS) solution. We highlight the key components and steps of each phase. The goal of this approach is to ensure a target solution in the cloud that meets the specific requirements of the organization.

Initial Situation

An increasing number of companies are migrating their applications to the cloud, replacing and modernizing their existing on-premises infrastructure. Over the past few years, many security standards have been established, and the security level of cloud providers has improved—making cloud migration more attractive for many organizations.

But how should the migration be approached to ensure the target solution in the cloud meets not only functional and security requirements but also compliance standards? And how can it be seamlessly integrated into the existing IT landscape (both on-prem and cloud)?

Six-Phase Migration Guide

To address these questions, we present a six-phase guide to cloud migration designed to ensure the cloud solution meets all organizational requirements.

Below, we examine each phase in detail and explain the key components and steps. We also highlight critical aspects that should be given special attention in each phase.

 

Phase 1: Current State and Requirements Analysis

The first step in any cloud migration is analyzing the current state and requirements. This involves a detailed assessment of the application, data assets, and business processes. It’s essential to identify and document existing applications, dependencies, and data.

Key components:

• Inventory of current IT infrastructure
• Identification of application functions, data, and data classes
• Determination of regulatory and legal requirements (e.g., GDPR)
• Evaluation of current security measures

A crucial aspect of this phase is the security analysis and the resulting security requirements. The project team should identify existing vulnerabilities and assess them as part of a comprehensive risk analysis.

Phase 2: Target Concept

Based on the current state analysis, a target concept is developed that defines the future cloud architecture and the requirements for the cloud application. Common cloud security measures should be established and considered.

Key components:

• Selection of cloud provider and target architecture, including necessary interfaces
• Provisioning of required cloud functions
• Central security requirements and measures
• Operations and maintenance concept
• Monitoring tools (e.g., for service tracking and cost control)

The target concept serves as the foundation for the following phases and ensures that all requirements for the new environment are clearly defined. The project team should also ensure compliance with established internal security standards.

Phase 3: Cloud Setup

Once the target concept is finalized, the cloud environment is set up. This includes configuring the cloud infrastructure, implementing security measures, and performing an initial data transfer. While many cloud providers offer tools to meet security and compliance requirements, these often need to be activated or customized by the customer.

Steps:

• Setup of cloud infrastructure and application
• Activation of licenses and tools
• Configuration of functions and interfaces
• Implementation of security configurations (e.g., firewall, encryption, access rights)
• Data transfer

Security measures should follow company-wide standards. Additional recommendations, such as those from the German Federal Office for Information Security (BSI), may also be applied. A “security-by-design” approach is essential—security mechanisms should be integrated from the beginning.

Phase 4: Testing / Pilot

After setup, the cloud environment must undergo thorough testing. Depending on the complexity of the application, a pilot phase may be appropriate. The goal is to identify and resolve issues early.

Steps:

• Define test cases based on application scenarios (use cases)
• Test use cases, performance, and security
• Evaluate tests and adjust configurations
• Fix defects and issues

Test cases should cover both regular and exceptional scenarios to provide a comprehensive picture. All relevant stakeholders should be involved in the testing process.

Phase 5: Migration

This phase completes the remaining data migration and transitions the application to the cloud. To minimize risks and downtime, the transition may be carried out in stages.

Steps:

• Prepare application and data for final migration
• Conduct employee training
• Execute data migration and updates
• Monitor migration and resolve issues

Maintaining data integrity and security during migration is critical. Appropriate tools and secure transmission paths should be used.

Phase 6: Handover to Operations

After migration, the application is handed over to the internal or external operations team. Even after successful migration, the cloud environment should be continuously monitored and optimized. Operating costs and security should be regularly reviewed.

Key components:

• Transfer of documentation to operations teams
• Initiation of support and hyper-care teams
• Audits and security checks
• Continuous monitoring and optimization of the cloud environment

Conclusion: Cloud Migration of an Application

Migrating to the cloud is a complex project that demands precise planning and careful execution. By adhering to proven security standards, a secure cloud environment can be established that meets the specific needs of the organization. Each of the six phases—from analysis to operational handover—plays a vital role in ensuring a successful and sustainable cloud migration. Collaboration across all teams and departments is essential to achieve a successful outcome.

When being involved in a transition – successful acceptance tests cannot be taken for granted. Clients know the situation: IT services were outsourced to an IT service provider. However, the acceptance of the IT services in the transition phase is not running smoothly. Typical weaknesses are lack of documentation, insufficient personnel resources, missing measuring equipment. And in particular services can become a problem, that have not been sufficiently tested by the provider in advance.

Weaknesses identified during acceptance usually lead to a delay in acceptance. In the worst case, it is aborted because the functionality of the services cannot be fully proven. If acceptance tests are cancelled or only partially released, additional acceptance tests must be planned. This causes considerable costs for both the client and the provider.

Reasons for an unfinished acceptance are in particular

• clearly defined acceptance criteria before the contract is signed
• the provider underestimates the effort required for acceptance of the services and therefore cannot provide the necessary resources for acceptance
• no adequate configuration management according to ITIL

How can you avoid such situations? In this article I would like to show ways and methods to do so. I will concentrate on essential points that are critical during the acceptance process.

The outsourcing lifecycle consists of the phases strategy, conception, RfP/award of contract, transition and operation. The foundation for a successful acceptance is laid in the RfP phase of the services. From the outset, the framework conditions for the acceptance should be defined, taking into account company-wide guidelines (e.g. quality guidelines), templates and change management specifications. In order to realize this, the general conditions of the acceptance and the responsibilities must be clearly and unambiguously formulated in the tender. Acceptance in the outsourcing life cycle is divided into three work steps:

1. Creation of the Test Strategy

ITIL defines the test strategy as the overall approach to organizing tests and allocating test resources. In the award phase, the provider creates the test strategy as part of the bidding process in accordance with the specifications of the RfP. The required activities include

• translating the service concept from the service design into test requirements and test models (test plan, test procedures, list of test elements, scripts, etc.)
• definition of the necessary test levels (component test, integration test, etc.)
• definition of the acceptable failure rate for each test level (pass/fail criteria) as well as abort and restart criteria
• coordination of the acceptance procedure
• clarification of responsibilities during acceptance
• definition of the delivery results
• specification of the role requirements during acceptance

The client checks the test strategy for completeness and the traceability of the test requirements back to the service design criteria.

Every company has different attitudes to risk with regard to service quality. This willingness to take risks influences the degree and level of validation and testing. Depending on the risk appetite, the client may require an adjustment of the testing strategy. The aim is that a joint agreement on the acceptance of services is reached between the client and the service provider. The test strategy becomes part of the contract.

If service changes are agreed upon and lead to contract adjustments, the acceptance procedures must be adjusted with appropriate advance notice before acceptance.

2. Notification of Readiness of Acceptance by the Service Provider

In order to avoid frictional losses during the acceptance in the transition phase, an acceptance readiness test should be carried out by the client beforehand. This test ensures that all necessary preliminary work to start an acceptance procedure has been completed correctly.

According to the current project plan, the provider reports the readiness for acceptance of the service to the client. The prerequisites for reporting readiness for acceptance should already be defined in the contract. The provider delivers the relevant documentation as agreed in the acceptance procedure specified in the contract.

Depending on the type of service, the documentation includes

• Delivery bills
• Guarantee certificates
• Configuration list(s)
• Network plans
• Executed checklist(s) or test protocols
• Operating Manual
• Training documents

Within the scope of the readiness for acceptance test, the client checks the documentation for completeness and correctness. The client may have several queries to the provider. When these have been clarified, the client confirms the readiness for acceptance. If the delivery is incomplete compared to the specifications, the acceptance readiness is rejected and the service provider is requested to close the open points. Depending on the situation, the readiness for acceptance can be confirmed under the condition that the service provider removes the defects by the start of the acceptance. It is important to allow enough time for the documentation to be checked and a reworking period to eliminate the defects before acceptance.

3. Acceptance by the Client and Declaration of Acceptance

The organization of the acceptance is done by the service provider. He ensures that the infrastructure for the execution of the acceptance is created and that all participants receive the relevant information in time.

In the acceptance procedure, the service provider presents the test procedures defined in the agreed acceptance procedure to the client. Defects resulting from additional, not pre-defined tests may not lead to an acceptance abort, unless the effects of the defects are so serious by their nature or number that the service is significantly impaired.

After acceptance, the service provider must have the opportunity to rectify the defects within a realistic period of time, which is agreed upon jointly at the time of acceptance. The results of the acceptance must be recorded and identified defects must be listed with details of the defect pattern, defect class, further procedure and responsibility.

Acceptance ends with a declaration of acceptance by the client with or without open defects or with an acceptance abort according to contractually defined abort criteria. The service provider undertakes to remedy the defects in due time. It is advisable to contractually set the largest payment milestone to a successful acceptance. Otherwise, the motivation pressure on the provider cannot be maintained.

Conclusion: Transition – Successful Acceptance Tests

The structured approach and the applying of this approach, as well as the acceptance criteria in the contract, ensure that the service provider takes a detailed look at the expected expenses. The introduction of the acceptance test ensures that all prerequisites (e.g. configuration management, documentation and preparatory tests by the service provider) for a smooth acceptance are in place. It is important to describe the activities of the acceptance in the project plan and to update them regularly. Furthermore, it is recommended to plan an acceptance in several steps and as early as possible in order to detect defects early on, which will not occur in later partial acceptances. A careful acceptance of services also ensures service quality in the later operating phase.