Step 1: Select migration scenario

The first step in our proposed methodology is the selection of the migration scenario.

For this purpose, we use the ten cloud data migration scenarios identified database layer outsourcing, using highly-scalable data stores, geographical replication, sharing, cloud bursting, working on data copy, data synchronization, backup, archiving, and data import from the cloud (FR6).

Application migration phases to cloud Figure 19

These migration scenarios cover both migration directions between on-premise and off-premise (FR2).

Based on the selection of the migration scenario, a migration strategy is formulated by considering properties such as live or non-live migration, complete or partial migration, and permanent or temporary migration to the cloud.

During this step, potential conflicts between the migration scenario selected and the refined migration strategy should be explicitly addressed by proposing solutions to the user, e.g., the choice of a different migration scenario.

An example of a conflict is the selection of the migration scenario cloud bursting and the choice of a permanent migration to the cloud in the strategy.

The purpose of this migration scenario is by definition to migrate the database layer to the cloud in order to cover peak loads and migrate it back afterwards; choosing therefore permanent migration as part of the strategy cannot be satisfied.

Step 2: Describe desired cloud data hosting solution The specification of functional and non-functional requirements with respect to the target data store or data service is the focus of the second step.

We define cloud data hosting solution as the concrete configuration of a cloud data store or Cloud data service in terms of a set of concrete functional and non-functional properties (FR1).

Therefore, we derived an initial set of properties grouped into different categories based on the analysis of current data store and data service offerings of established cloud providers such as Amazon, Google, and Microsoft. Table 1 provides an excerpt of the categories and corresponding properties we consider.

These categories cover both relational and NoSQL solutions

(FR3, FR5).

Step 3: Select cloud data store or data service

The concrete target data store or data service for the migration is selected in step three by mapping the properties of the cloud data hosting solution specified in the previous step to the set of available data stores and data services that have been categorized according to the same non-functional and functional properties.

Implementing this step requires data stores and data services to be previously specified according to the set of functional and non-functional properties either directly by the cloud providers, or by the users of the methodology.

The management and configuration capabilities required for this specification can however be used at a later time to also make new cloud data stores and data services available (FR4).

Step 4: Describe source data store or data service

As it is not sufficient to consider only where the data has to be migrated to, in step four the functional and non-functional properties of the source data store or data service are also described in order to identify and solve potential migration conflicts, e.g., the database technology used, or whether the location is on-premise or off-premise (FR5).

Step 5: Identify patterns to solve potential migration conflicts The usage of cloud technology leads to challenges such as incompatibilities with the database layer previously used or the accidental disclosing of critical data, e.g., by moving them to the public cloud.

Incompatibilities in the database layer may refer to inconsistencies between the functionalities of an existing traditional database layer and the characteristics of an equivalent cloud data hosting solution.

Therefore, in the fifth step conflicts are identified by checking the compatibility of the properties of the target data store selected in step three with the properties of the source data store or service used before the migration (FR5).

As a way to address these conflicts, in previous work Starch et al. (2013c) we have defined a set of cloud data patterns as the best practices to deal with them that can be reused here.

Step 6: Refactor application architecture

As the migration of the database layer also has an impact on the remaining application layers the methodology should also provide guidelines and hints on what to be considered for the refactoring of the application.

Special focus should be given on the adaptation of the network, the data access layer, and the business logic layer of the application, depending on the outcomes of the previous steps (FR7).

Networking adaptation might require for example the reconfiguration of open ports in the enterprise firewall.

Although the cloud data store might be fully compatible with the data store previously used, the migration requires at least a change to the database connection string in the data access layer.

The impact of the database layer migration to the cloud on the business logic layer depends on several aspects, such as the migration scenario and the incompatibilities of the source and target data store.

In case of switching from a relational database to a NoSQL data service, the business logic needs to be significantly adapted as the characteristics of these two technologies are different for example with respect to transaction support, relational database schema vs. schema-free or schema-less NoSQL solution, and quality of services.

Step 7: Migrate data

The final step, migrating the data, entails the configuration of the connections to the source and target data stores or services by requiring input on the location, credentials, etc. from the user.

This step should also provide adapters for the corresponding source and target stores, bridging possible incompatibilities between them, and/or reuse of the data export and import tools offered by the different cloud providers.

As the last step is dealing with potentially confidential information, in order to prevent other users from accessing the data a tool supporting the proposed methodology has to support the required security mechanisms (NFR1).