Risk Perception of Migrating Legacy Systems to the Cloud

Breno G. S. Costa and Priscila Solis

Department of Computer Science, University of Bras

ılia, Bras

ılia-DF, Brazil

Keywords:

Cloud Computing, Legacy Systems, Migration, Reference Model, Risk Perception.

Abstract:

With the utilization of Cloud Computing as the way to provide Information Technology services, the organi-

zations can migrate legacy systems to the cloud in order to reach several beneﬁts. There are in the literature

several proposals to model the critical elements of migration and many have been validated by speciﬁc case

studies. Also several reference models were deﬁned on top of these proposals and were created with the in-

tention to consolidate different researches, trying to expand their applicability. Based on the above, this paper

selects a reference model for migrating legacy systems to the cloud and proposes a method for calculating a

score of perceived risk associated with each legacy system migration. The paper presents a proof of concept

on government domain to show the method’s applicability.

1 INTRODUCTION

In the last years Cloud Computing (CC) changed the

way Information Technology (IT) is provided and

consumed and created a new landscape in which or-

ganizations manage their own computing infrastruc-

ture to another, where IT is consumed as a service

(ISACA, 2012).

According to (Gartner, 2017), the massive use of

public cloud services appears in the signiﬁcant growth

rates of service providers such as Amazon Web Ser-

vices (AWS) (AWS, 2017) and Microsoft Azure (Mi-

crosoft, 2017), among others. The study surveyed al-

most 3000 participants and found that 21% of them

have already used public cloud services, while 56%

planned to implement the cloud by the end of 2017.

For many of these organizations, IT modernization is

almost synonymous of increasing the use of CC.

The migration to this new paradigm has a potential

cost reduction of IT infrastructure, noticed by several

authors (Armbrust et al., 2009; Armbrust et al., 2010;

Gartner, 2017), mainly when related to the use of pub-

lic cloud. According to (Pahl and Xiong, 2013), mi-

gration to the cloud is the process of deploying, in

whole or in part, the digital assets, services, IT re-

sources, or systems of an organization on the cloud.

With the use of CC, government organizations can

reduce the number of contracts and consequently re-

duce the opportunities for irregularities while improv-

ing efﬁciency. They can also focus on providing ser-

vices to the population by reducing the operational

effort to maintain the infrastructure and IT services

platform (Kundra, 2011).

Migration to the cloud may involve retention of

part of the infrastructure within the organization. For

example, a legacy system can be merged with a com-

plementary cloud solution, with integration over the

Internet. The trend of increased use of CC, including

on government organizations, may beneﬁt of using a

process (guidelines and methods) to migrate legacy

systems to the public cloud.

The goal of this paper is to present an extension to

a reference model of legacy systems migration to the

cloud. The extension will be validated with a proof of

concept in government domain. This paper makes the

following contributions:

• based on a review of related work, proposes a

method for calculating a score of perceived risks

associated with the legacy migration to the cloud;

• describes a proof of concept showing the applica-

bility of the method for the government domain.

The remainder of this article is divided into four sec-

tions. Section 2 presents the theoretical concepts

and related work and also describes the motivation of

evaluating the risk perception of applying the refer-

ence model. Section 3 presents the proposed evalua-

tion method. Section 4 describes the proof of concept.

Finally, Section 5 presents the conclusions and future

work of this research.

634

Costa, B. and Solis, P.

Risk Perception of Migrating Legacy Systems to the Cloud.

DOI: 10.5220/0006801706340642

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 634-642

ISBN: 978-989-758-295-0

2 THEORETICAL CONCEPTS

AND RELATED WORK

2.1 Migration Methods and Strategies

Software migration is the process of moving (or

adapting) a system from one operating environment

to another (ISO/IEC, 2006). Software migration can

be seen as part of a broader context that is software

maintenance and reuse (Ionita, 2013). Migration to

the cloud is the effort to adapt legacy systems running

locally on the organization’s infrastructure to trans-

port them to the cloud (Jamshidi et al., 2013).

To take advantage of CC beneﬁts and protect ex-

isting investment in a legacy system, organizations

tend to migrate their legacy systems to the cloud grad-

ually when feasible (Zhao and Zhou, 2014; Gartner,

2017; Ionita, 2013). As discussed in (Pahl and Xiong,

2013), the migration process requires careful consid-

eration, planning, and execution to ensure system se-

curity and integrity after migration, and to remain

compliant with the organization’s requirements.

According to (Babar and Chauhan, 2011), unsuc-

cessful cloud migration can cause business processes

to fail, increase security incidents, and increase main-

tenance costs. In addition to these considerations,

the work of (Zhao and Zhou, 2014) discusses migra-

tion strategies and methods. For them, different mi-

gration strategies should consider different migration

processes, with their subdivisions into speciﬁc tasks.

In the study of (Binz et al., 2011), the authors propose

an application migration framework for the cloud and

between cloud providers.

One alternative point of view regarding migration

to the cloud is the use of adaptation, addressed by

(Andrikopoulos et al., 2013). The authors identify

four types of legacy systems migration. In (Zhao and

Zhou, 2014), the authors analyze and compare the two

migration deﬁnitions cited in (Binz et al., 2011) and

(Andrikopoulos et al., 2013), among other deﬁnitions

and categorized migration to the cloud into three ma-

jor areas: migration to Infrastructure as a Service, mi-

gration to Platform as a Service and migration to Soft-

ware as a Service.

One of the main beneﬁts of using CC is the po-

tential cost reduction of IT infrastructure investments

(Armbrust et al., 2009; Armbrust et al., 2010; Gart-

ner, 2017). However, according to (Sun and Li, 2013),

this beneﬁt typically only considers the cost of cloud

services after migration. The authors developed a

method to estimate the cost of the migration process

from legacy systems to cloud. The method consid-

ers that, although described sequentially, the execu-

tion ﬂow of the migration tasks iterates in a way in

which errors in the execution of a task can cause the

repetition of previous tasks. Thus, according to the

size and complexity of the legacy system and also to

the maturity of the team responsible for the migration,

the cost of the migration process can be calculated us-

ing the method they have deﬁned.

2.2 Characterization Model

Many publications address how to structure the mi-

gration of legacy systems to the cloud. The Cloud-

RMM model (Jamshidi et al., 2013) categorizes

twenty-three studies on the migration of legacy sys-

tems to the cloud and serves as a guide to the analy-

sis of these studies. The model is composed of four

processes and each process is a group of tasks.In the

model, there is also an indication of the artifacts gen-

erated at the end of each process.

In this model, there is only a consolidation of pro-

cesses, tasks and artifacts, found in the twenty-three

studies analyzed in the systematic literature review

undertaken by (Jamshidi et al., 2013). There is no dis-

cussion about the need and relevance of each process

and task.

2.3 Evaluation Model

The work of (Gholami et al., 2016) provides a detailed

assessment of existing CC migration approaches from

the perspective of process modeling and software de-

velopment methodologies. The authors propose an

evaluation model to compare existing approaches,

highlighting their resources, similarities and differ-

ences. The approach used by the authors differs from

other related works because it focuses on the aspect

of the cloud migration process to understand which

core activities and concerns are involved during this

transition. According to their analysis, none of the

reviewed studies provides an in-depth discussion of

proposed migration features and activities and also

did not bring useful experience of applying those ap-

proaches in practice. In addition, the article provides

a meticulous analysis of existing approaches through

an evaluation model which encompasses twenty-eight

criteria classiﬁed into two dimensions. That is, eleven

generic criteria and seventeen speciﬁc criteria for

cloud computing. The proposed framework was de-

rived from a literature review and validated through

a web-based questionnaire survey of 104 academics

and experts in the ﬁeld of cloud computing (Gholami

et al., 2016).

As challenges for future work, (Gholami et al.,

2016) acknowledge that there is a large amount of

research on cloud migration, which is currently dis-

Risk Perception of Migrating Legacy Systems to the Cloud

635

persed and fragmented, and suggest that a generic ref-

erence model must be deﬁned with the goal of consol-

idating the existing literature.

2.4 Reference Model

According to (Fettke and Loos, 2003), a reference

model is a conceptual framework that can be used

as the model for information systems development.

Reference models are also called universal models,

generic models, or standard models. To use reference

models, they must be tailored to the requirements of a

speciﬁc domain. The study presents several perspec-

tives for the evaluation of reference models. Among

them, the empirical perspective, from which we men-

tion two approaches that relate to the object of this

research: case study and survey.

In a more recent study, (Gholami et al., 2017) re-

sponded to the challenge proposed in (Gholami et al.,

2016) and worked to ﬁnd out the critical activities, ar-

tifacts, concerns and key recommendations regarding

the migration of legacy systems to the cloud. Results

were validated empirically, through the collection of

experts perceptions to increase the reliability.

Based on an intensive qualitative analysis of ex-

isting constructs in the literature, the authors cre-

ated a migration to the cloud reference model. The

relevance and robustness of the model was further

conﬁrmed using quantitative research and qualitative

feedback from domain experts. Figure 3 shows a sum-

mary of the resulting reference model. To simplify

the view, the summary shows only the model’s key

elements, without the subdivisions of activities into

smaller tasks and without the ﬂow of information be-

tween them. The detailed view of phases Plan and

Design will be better described in Section 4.

Although this reference model has been created

from the literature and evaluated using survey with

CC experts, the authors do not claim its general appli-

cability. In the opposite sense, they assert that there

is no universally superior or applicable method for

Figure 1: Project life cycle as deﬁned on PMBOK (PMI,

2013).

all cloud migration scenarios and therefore, methods

must be tailored to the speciﬁc characteristics of the

application domain.

2.5 Legacy Systems Migration Viewed

as an IT Project

Each legacy system migration to the cloud can be

viewed as a different project, following what is out-

lined in the Project Management Body Of Knowledge

(PMBOK)(PMI, 2013): it is a temporary endeavor

and creates a unique product: the legacy system mi-

grated to the cloud. PMBOK deﬁnes the life cycle

of a project as being the series of phases, usually se-

quentially linked, that a project goes through. Figure

1 shows the generic structure of a project life cycle

and the level of costs and personnel required at each

stage of the life cycle.

According to the PMBOK, the generic structure

of the life cycle presents, among others, the following

characteristics:

• The personnel and cost levels are low at the be-

ginning, they reach a maximum value while the

project is running, and fall quickly as the project

is ﬁnalized. Figure 1 illustrates this pattern.

• The risks and uncertainties are greater at the be-

ginning of the project. These factors decrease

over the life of the project as decisions are made

and deliveries are accepted, as shown in Figure 2.

• The ability to inﬂuence the ﬁnal characteristics of

the project’s product, without signiﬁcant impact

on costs, is higher at the beginning of the project

and decreases as the project progresses to its end.

Figure 2 illustrates the idea that change costs and

bug ﬁxes generally increase signiﬁcantly as the

project nears completion.

Figure 2: Project risks and cost of changes through the time

(PMI, 2013).

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

636

Figure 3: Key elements of Legacy to Cloud migration Reference Model proposed by (Gholami et al., 2017).

3 REFERENCE MODEL

EVALUATION

The previous section presented some deﬁnitions and

classiﬁcations of migration models and analyzed

three of them: a characterization model that grouped

processes, activities and artifacts referenced in 23 mi-

gration proposals published between 2010 and 2013;

an evaluation model that, based on 28 relevant cri-

teria, evaluated 43 articles published between 2009

and 2015; and a reference model (Gholami et al.,

2017), selected as the basis for this study, deﬁned

from the consolidation of 78 proposals published be-

tween 2008 and 2015. The selected reference model

is divided into three phases: Plan, Design and En-

able as shown on Figure 3. The Plan phase is re-

sponsible for collecting relevant information about

the system to be migrated (technical information, or-

ganizational context) and, in accordance to migration

requirements, for creating an appropriate migration

plan. The Design phase uses the knowledge and ar-

tifacts generated in Plan phase and is responsible for

choosing one or more CC providers and also for deﬁn-

ing the new architecture that the legacy system will

have on the cloud. The Enable phase represents the

actual migration. It comprehends the implementation

of legacy system code adaptations, the build of inte-

grators when appropriate, the conﬁguration of the CC

services deﬁned in Design phase, testing and go live

of migrated system.

As shown in Figure 1, the effort required to ex-

ecute the third phase is potentially bigger than what

will be spent in the two initial phases. This is due to

the fact that ﬁrst phases have mostly analytical work,

while the third, mostly implementation work. Imple-

mentation in this context means both the development

related to the adaptations and new integrations, when

necessary, and cloud services conﬁguration.

Thus, it is important to have an early assessment

of migration risks before Enable phase. The assess-

ment may indicate an increased risk perception (mi-

gration additional cost and time, for instance) for a

given system when compared to the others, and thus

provide an objective measure of comparison. It is pos-

sible to rank the systems that will be migrated and set

up an order of execution that prioritizes the systems

with less perceived risk, thus increasing the success

rate and organization’s conﬁdence on the migration

project.

As a way to provide an objective and early assess-

ment of perceived risks of migration of each legacy

system to the cloud using the Reference Model, we

deﬁned the following procedure: in each of the two

initial phases (Plan and Design), one must select the

tasks that together better represent the critical points

of each legacy system migration to the cloud. Some

tasks have a job of merely collecting and aggregating

information, while others implement constraints, de-

cisions or characteristics that are intrinsic to the sys-

tem and the organization and thus have the potential

Risk Perception of Migrating Legacy Systems to the Cloud

637

to impact the rest of the migration. One should choose

between tasks in the second category. It is important

to realize that different application domains may have

different sets of tasks that better evaluate the risk per-

ception of migrating legacy systems to the cloud on

that domain.

After choosing the set of evaluation tasks, it is nec-

essary to deﬁne the weights that each task will have

in relation to the other tasks on the set. The weight

of tasks is related to the importance of that task in the

domain of application. For instance, on government

domain the task related to procurement is perceived

as being more risky than the one related to training,

due to legal and regulation rules.

The evaluation function deﬁned here has the fol-

lowing format:

EvF(Pl, De) =

Pl + De

(1)

where:

Pl =

∑

i=1

∑

i=1

(2)

De =

∑

j=1

∑

j=1

(3)

and:

Pl – Plan Phase Evaluation Indicator.

De – Design Phase Evaluation Indicator.

– Risk perception rate for task i of the Plan Phase

evaluation set.

– Weight of task i in Plan Phase evaluation set.

– Risk perception rate for task j of Design Phase

evaluation set.

– Weight of task j in Design Phase evaluation

set

The function deﬁned in (1) considers that both

phases have the same relative importance on calcu-

lating the the score of perceived migration risks. But

speciﬁc circumstances could be considered on an-

other evaluation function that balance the phases dif-

ferently.

After selecting the set of evaluation tasks in each

phase and the weight of each of them, they must be

evaluated. Note that the work required on each task

must be performed as deﬁned in the Reference Model.

At the end of the execution of each phase, and conse-

quently at the end of the execution of all tasks of that

phase, is when the evaluation method is performed.

This is an important consideration because it is nec-

essary to know each system in an appropriate level of

detail to do a more accurate evaluation and this can

Table 1: Plan Phase evaluation task set.

Task Weight

Analyze migration cost 3

Identify dependencies 3

Select migration scenario 1

not be done by executing only the tasks on the eval-

uation set. So, after the end of each phase’s work, it

is necessary to evaluate each task that is part of the

evaluation set. The proposal is to use a scale of 5 val-

ues for perceived risk, whose meaning could be 1 –

High risk, 2 – Moderate risk, 3 – Average risk, 4 –

Somewhat risk and 5 - Low risk. For each task, the

5 levels of the scale can also be deﬁned textually, in

order to facilitate the choice and evaluation of each

system. This must be done only once and only for the

tasks that are part of the evaluation set.

Once the scale is deﬁned and the Plan Phase is

ﬁnished, the evaluation can start by deﬁning, for each

task in the evaluation set, the rating of perceived risk

associated with that task’s subject in relation to legacy

migration and calculating the evaluation indicator of

the Plan Phase, Pl, as described in (2). The same

should be done to Design Phase by calculating the

evaluation indicator for the Design Phase, De, de-

scribed in (3). After calculating the two indicators,

one can calculate the perceived risk score of migrat-

ing the legacy system to the cloud, EvF(Pl, De), as

described in (1).

After calculating the evaluation function for each

system that will be migrated, a ranking can be estab-

lished that indicates, among other things, which sys-

tems should be migrated ﬁrst, which will be the sys-

tems with higher evaluation values (higher perceived

risk scores). This strategy is reinforced by (Reza Bazi

et al., 2017) who states that it is better to select a pilot

project at ﬁrst, when performing migration process.

Systems with lower evaluation values may receive ad-

ditional analysis to identify whether work modiﬁca-

tions to the evaluation tasks that are causing low eval-

uation are feasible. Even when could not be possible

to change something in systems with low evaluation

values, knowing that there is an increased risk percep-

tion is of great value. In addition, when using evalua-

tion function values to rank systems, one can also use

them to categorize systems on a previously deﬁned

risk scale. For this purpose, evaluation thresholds can

be deﬁned. For example, one can deﬁne that evalua-

tion function results that are below or equal to a cer-

tain threshold T 1 mean that the system should have

its migration decision reanalyzed. Another example

is when the value calculated by evaluation function is

above the threshold T 1, but the value of one of the

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

638

indicators (Pl or De) is below a given threshold T 2.

The threshold values can be deﬁned by using a

certain value of the Likert scale used, but can also

be deﬁned by the history of evaluations already done

and considering the result of these migrations. While

there is no history of assessments, it is suggested to

use the central value of the scale as the threshold T 1

and T 2 and adjust them as soon as new values have

been calculated from actual migrations.

4 PROOF OF CONCEPT

The proof of concept in this section presents an anal-

ysis of the selected activities and deﬁnes weights that

best support a risk perception evaluation for the mi-

gration of legacy systems in the government domain.

4.1 Plan Phase

For the Plan phase, we selected the tasks and deﬁne

the weights shown in the Table 1. The reasons why

the tasks were selected are the following:

Analyze migration cost - This activity results in

an estimate of migration cost. Cost is associated with

the effort required to migrate the legacy to cloud as

well as the cost of running the application after mi-

gration. As cost of migrating a system increases, also

increases the risk perception for the entire migration

process. On the other hand, a low-cost migration sys-

tem can be a good candidate to validate the migration

process and to gain experience with both the process

and the provider to which the system will be migrated.

If the cost of the migration added to the cost of

running the system in the cloud provider does not rep-

resent an economy relative to the current cost, this

may indicate a system that will not beneﬁt from the

cloud if there is no value aggregation by other means,

such as the use of intrinsic cloud characteristics (self-

scalability, higher availability, for example) (Gholami

et al., 2017). According to (Gholami et al., 2017), the

objectives of Analyze Context activity (which is an

aggregate of Analyze migration cost and other tasks)

are cost estimate and risk mitigation.

Identify dependencies - This activity has the ef-

fect of identifying which other local systems and

components the system being analyzed depends on to

function properly on the cloud after migration. With

this task, it is possible to identify which other systems

would have to be previously migrated to the cloud.

Or, in the case of a hybrid cloud and if the dependen-

cies are not migrated yet, one will need to evaluate

and consider the network latency between the local

infrastructure and the cloud. According to (Reza Bazi

Table 2: Design phase evaluation task set.

Task Weight

Negotiate with cloud provider 3

Train 1

Identify incompatibilities 1

et al., 2017), this is a critical factor to be consid-

ered, since legacy systems were developed on older

platforms than the current version supported by cloud

providers. The objective of Recover Legacy applica-

tion knowledge (activity which aggregates Identify-

ing dependencies task) is Understand legacy system

dependencies (Gholami et al., 2017).

Select migration scenario - According to the

characteristics of the legacy system and also accord-

ing to the amount of effort that is intended to be spent

in the migration, one may choose the migration type

among ﬁve options (Andrikopoulos et al., 2013; Gho-

lami et al., 2016). Migration type V, for instance, is

a type associated to a low risk of failure when com-

pared with other types, since it is based on moving the

whole system stack to the cloud. Thus, the choice of

the scenario may be directly related to the risk inten-

sity that is accepted. This is not the same to say that a

scenario of low risk is also the option that will bring

the greatest beneﬁt (cost reduction, increased avail-

ability), because scenario V, for instance, could make

costly the implementation of elasticity (Andrikopou-

los et al., 2013). The objectives of Deﬁne Plan (ac-

tivity that aggregates Select migration scenario task)

are Project management and Risk mitigation (Gho-

lami et al., 2017).

4.2 Design Phase

For the Design phase, we selected the tasks and deﬁne

the weights shown in the Table 2.

Negotiate with cloud provider - This task is criti-

cal because only after its execution one or more cloud

providers are available to provide the cloud services

that will support migrated systems. If one have not

still hired the provider at migration time of a partic-

ular legacy system, this may delay the migration or

cause rework. Note that even after a provider has al-

ready been hired and some legacy systems have been

migrated to the cloud, it is possible that the contract

could be reaching its end, or even that the provision

of the service is not satisfactory and that the organiza-

tion has decided to replace the provider, even before

the end of the contract.

Training - This task is responsible for acquiring

and maintaining the necessary knowledge to prop-

erly design, operate and monitor the CC services. A

Risk Perception of Migrating Legacy Systems to the Cloud

639

Figure 4: Reference Model’s Plan phase with visual indicative of task evaluation set.

Figure 5: Reference Model’s Design phase with visual indicative of task evaluation set.

higher need for training may indicate a higher risk in

managing the migration project of a given legacy sys-

tem. According to (Reza Bazi et al., 2017) organiza-

tions must extend their cloud knowledge as a way to

guarantee a successful start. The objective of Choose

Cloud Provider (activity that aggregates both Negoti-

ate with the cloud provider and Train tasks) is to ﬁnd

the best providers that meet migration requirements

(Gholami et al., 2017).

Identifying incompatibilities - This task is re-

sponsible to ﬁnd the incompatibilities between the

legacy system and the set of CC services deﬁned in

the design phase as being required to run the system

after migration to the cloud. These incompatibilities

will require speciﬁc effort to be solved. The objec-

tive of the activity Identifying incompatibilities is to

estimate effort and cost to resolve incompatibilities

(Gholami et al., 2017).

The above explanations of what motivated task se-

lection for the government domain are illustrated in a

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

640

Table 3: Rating of risk perception associated with tasks on evaluation set (shaded lines:Plan phase; white lines:Design phase).

Task Weight Rate Reason

Analyze migration cost 3 5 Low complexity system and low estimated migration cost.

Identify dependencies 3 4 System that has almost no dependency.

Select migration scenario 1 4 Scenario type V, lift and shift.

Negotiate with cloud provider 3 4 Providers selected.

Train 1 2 High necessity of training. No experience on CC.

Identify incompatibilities 1 5 No incompatibilities found.

detailed view of Reference Model phases with a vi-

sual identiﬁcation of the tasks in Figures 4 and 5. The

ﬁgures show how each key element is associated to

the others. Each key element has been associated with

a color, which covers the tasks that compound that

key element. In addition, there is a speciﬁc indication

(three colored smileys) in the tasks that are part of the

evaluation set.

4.3 Use Case

To show the method’s applicability, we chose a legacy

system in use by a government body that decided

to migrate its legacy systems to the cloud. The

legacy system is called Civic Cloud and exposes,

on the Internet, updated data about educational and

health institutions around the country and data about

medicines that are authorized by the proper govern-

ment agency. Although the system has cloud on its

name, it runs on local infrastructure.

The system is composed by a set of loosely cou-

pled web services that can be used by developers and

companies to add value to their applications. For in-

stance, one can develop and publish a mobile appli-

cation that automatically captures user location and

suggests the health institution that is closer to the

user. The system was developed using Java language

with the support of Spring MVC framework. It is

running on application server JBOSS EAP, sharing

computational resources with other legacy systems.

The database management system is Oracle (Oracle,

2017).

As the system is publicly available, any developer

can build an application that makes calls to its ser-

vices and uses the provided data. If one of these ap-

plications becomes a killer application, with hundreds

or thousands of transactions by hour, there is a chance

that the computing infrastructure becomes inadequate

due to the lack of elasticity.

We worked with the team responsible by the sys-

tem in order to apply the reference model for migra-

tion to the cloud. After doing the work prescribed

on initial phases, Plan and Design, we applied the

method described on the Section 3, using the tasks

and weights deﬁned on the Section 4.

The team shared their perception that the system

was a good choice to be the ﬁrst legacy to be migrated

by this government body. This is explained due to the

low number of integrations with other legacy systems

and to the low complexity and size of system code.

The team then rated the risk perception for each

task on the evaluation set of both phases. The values

can be viewed on table 3, along with the main reason

that justiﬁed the rating.

Using the weights deﬁned on tables 1 and 2, the

rates given by the team (table 3) and applying equa-

tions (2), (3) and (1), we have: Pl = 4.43, De = 3.80

and EvF = 4.11. The calculated value of EvF is

the score of risk perception to migrate legacy system

Civic Cloud to the cloud with the use of Reference

Model. As suggested on Section 3, T 1 and T 2 are de-

ﬁned to be 3.0. Since EvF, Pl and De are higher than

these thresholds, this indicates a low risk perception

for this system migration.

5 CONCLUSIONS AND FUTURE

WORK

This paper presented a review of software migration

strategies, compared three conceptual migration mod-

els and selected a reference model as a basis for

legacy systems migration to the cloud. Based on

the concepts, we proposed a method for calculating

a score of perceived risk to the systems that will be

migrated to the cloud. Method’s steps are described

along with a proof of concept in the government do-

main. The proposed method can be used to rank the

systems to be migrated to the cloud, offering an op-

portunity to assess migration risk perception before

migration execution.

The future work of this research aims to apply the

method on other government systems and collect the

results in different scenarios. Also, these results could

be validated with a survey, applied over different gov-

ernment organizations, to improve and verify the pro-

posed method.

Risk Perception of Migrating Legacy Systems to the Cloud

641

REFERENCES

Andrikopoulos, V., Binz, T., Leymann, F., and Strauch, S.

(2013). How to adapt applications for the cloud envi-

ronment. Computing, 95(6):493–535.

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A. D., Katz,

R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A.,

Stoica, I., and others (2010). A view of cloud comput-

ing. Communications of the ACM, 53(4):50–58.

Armbrust, M., Fox, A., Grifﬁth, R., Joseph, A. D., Katz,

R. H., Konwinski, A., Lee, G., Patterson, D. A.,

Rabkin, A., Stoica, I., and others (2009). Above the

clouds: A berkeley view of cloud computing. Tech-

nical report, EECS Department, University of Califor-

nia, Berkeley.

AWS (2017). Amazon Web Services. [online]. available

from:. https://aws.amazon.com/.

Babar, M. A. and Chauhan, M. A. (2011). A tale of migra-

tion to cloud computing for sharing experiences and

observations. In Proceedings of the 2nd international

workshop on software engineering for cloud comput-

ing, pages 50–56. ACM.

Binz, T., Leymann, F., and Schumm, D. (2011). CMotion:

A Framework for Migration of Applications into and

between Clouds. In Service-Oriented Computing and

Applications (SOCA), 2011 IEEE International Con-

ference on, pages 1–4. IEEE.

Fettke, P. and Loos, P. (2003). Multiperspective evaluation

of reference models–towards a framework. Concep-

tual modeling for novel application domains, pages

80–91.

Gartner (2017). Developing a Public Cloud IaaS

Adoption and Migration Framework. [online]. avail-

able from:. https://www.gartner.com/doc/3645347/

developing-public-cloud-iaas-adoption.

Gholami, M. F., Daneshgar, F., Beydoun, G., and Rabhi,

F. (2017). Challenges in migrating legacy software

systems to the cloud—an empirical study. Information

Systems, 67:100–113.

Gholami, M. F., Daneshgar, F., Low, G., and Beydoun, G.

(2016). Cloud migration process—A survey, evalua-

tion framework, and open challenges. Journal of Sys-

tems and Software, 120:31–69.

Ionita, A. D. (2013). Introduction to the migration from

legacy applications to service provisioning. Migrat-

ing Legacy Applications: Challenges in Service Ori-

ented Architecture and Cloud Computing Environ-

ments, pages 1–11.

ISACA (2012). Guiding principles for cloud comput-

ing adoption and use. [online]. available from:.

http://www.isaca.org/Knowledge-Center/Research/

Pages/Cloud.aspx.

ISO/IEC (2006). Systems and Software Engineering- Soft-

ware Life Cycle Processes - Maintenance, ISO/IEC

14764:2006.

Jamshidi, P., Ahmad, A., and Pahl, C. (2013). Cloud migra-

tion research: a systematic review. IEEE Transactions

on Cloud Computing, 1(2):142–157.

Kundra, V. (2011). Federal Cloud Computing Strategy.

Washington: The White House.

Microsoft (2017). Microsoft Azure. [online]. available

from:. https://www.azure.com/.

Oracle (2017). Oracle Database. https://www.oracle.com/

database/index.html.

Pahl, C. and Xiong, H. (2013). Migration to PaaS clouds-

migration process and architectural concerns. In

Maintenance and Evolution of Service-Oriented and

Cloud-Based Systems (MESOCA), 2013 IEEE 7th In-

ternational Symposium on the, pages 86–91. IEEE.

PMI (2013). A Guide to the Project Management Body of

Knowledge (PMBOK

 Guide) – Fifth Edition.

Reza Bazi, H., Hassanzadeh, A., and Moeini, A. (2017).

A comprehensive framework for cloud computing mi-

gration using meta-synthesis approach. Journal of

Systems and Software, 128:87–105.

Sun, K. and Li, Y. (2013). Effort estimation in cloud migra-

tion process. In Service Oriented System Engineering

(SOSE), 2013 IEEE 7th International Symposium on,

pages 84–91. IEEE.

Zhao, J.-F. and Zhou, J.-T. (2014). Strategies and methods

for cloud migration. international Journal of Automa-

tion and Computing, 11(2):143–152.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

642