Gradual Migration of Legacy Software to theCloud: a Telco OSS Case Study

Klaus Raizer∗, Joana Malaverri, Lin T. Li, Eliane Z. V. Dias and Claudia P. MacedoCPqD - Centro de Pesquisa e Desenvolvimento em Telecomunicacoes

Campinas, SP, 13086-902*Contact: klaus@cpqd.com.br

Abstract—This paper presents the preliminary effort atCPqD for transitioning part of its legacy software systemto a cloud-enabled environment. We review the majorstrategies for cloud migration and propose a roadmapwith four steps for gradual migration of legacy systemsto a cloud environment. CPqD myNet, a subset of CPqD’sbroader Operation Support System (OSS) software, is de-scribed as CPqD’s early efforts to develop a reliable SaaS-based telco system. We also describe our current effortsto migrate CPqD’s OSS software functionalities towardsPaaS technology. The paper closes with a discussion onthe proposed roadmap, comments about its dependabilityand indications for future work.

Keywords—cloud migration, platform as a service, legacysoftware, OSS, telco.

I. INTRODUCTION

We live in the age of cloud computing, mobility, e-communities and big data. CIOs and technical leadersare aware they need to take advantage of these new tech-nologies to preserve and improve their businesses. In thequest for reducing management costs and complexity,and improving productivity and standardization, com-panies are investing in cloud computing and service-based technologies. Cloud Computing refers both to thesoftware being delivered as a service on the web, aswell as to hardware and resources being provided ondemand over the Internet [1]. However clear the gainsof adopting cloud-based solutions are to a business,information technology (IT) leaders recognize there areseveral challenges they need to address first. One ofthese are their own legacy systems.

Many companies today run systems which have beendeveloped over the last few decades. These systemsare still important to the business, but either theyfail to comply with new standards and/or technologiesdemanded by the market or they can not get the benefitsout of them. Therefore, in order to preserve the busi-ness value of existing systems, one must transfer thoselegacy systems [2] into new technological surroundingswithout, however, changing its main functionality [3].Thus, there is a rising concern to provide solutions thatallow migrating legacy systems to modern computingenvironments, such as cloud.

Cloud computing offers three service models forproviding computing resources on demand, namelyinfrastructure-as-a-service (IaaS), platform-as-a-service(PaaS) and software-as-a-service (SaaS) [4]. Some ofthe advantages provided by the PaaS model are: reducedproduct cycle time; higher standardization, extensibilityand code reuse; increased dependability; cloud-awareapplications for mobile platform and easier integrationwith service-oriented applications [5], [6].

Recent literature has identified different strategiesfor migrating legacy software to the cloud [7], [8],[9]. To implement these strategies, one or more ofthe aforementioned cloud models could be used. Basedon the reviewed literature and on our own experiencehere at CPqD, we believe that the use of PaaS formigrating legacy software produces interesting resultsin code reuse, efficiency, and cost reduction, besidesmoving companies towards the development of cloud-aware dependable applications. In fact, embracing PaaScould also be an important step toward the developmentof an ecosystem around complex systems, such asOperation Support System (OSS) for Telco players. Thiscould make the transition from in-house developmentand customization to a global partnership endeavouraffordable not only to big businesses, but also to Smalland Medium Enterprises (SME).

II. STRATEGIES FOR CLOUD MIGRATION

Software migration can be understood as an effortto switch software and applications from one environ-ment to another without, however, changing its mainfunctionality. In [7], the authors have defined a set offour possible strategies for accomplishing this transitionwhen the target environment is the cloud.

• Type I - Replacement: One or more componentsare replaced by cloud services. For instance, usinga webmail service (Gmail by Google or LiveMailby Microsoft) instead of a local email server.

• Type II - Partial Migration: Layers or parts of theapplication are migrated to the cloud. For instance,moving database (data layer) and business logic tothe cloud, but not the presentation layer.

• Type III - Full Stack Migration: The whole soft-ware or application is encapsulated in a VM and

is run on the cloud.• Type IV - Cloudification: The software is fully

transitioned to the cloud environment. Its func-tionalities are implemented as a composition ofservices available on the cloud.

To implement these strategies, one or more of theavailable cloud models can be used in order to migratetarget applications to a cloud environment. In Table I wesummarize which cloud models are adequate for eachmigration strategy (Xmeans applicable, × means not-applicable, and ◦ means to be avoided).

Table I: Models used for each type of strategyType IaaS PaaS SaaSI Replacement × × XII Partial Migration X X XIII Full Stack Migration X × ◦IV Cloudification ◦ X ◦

Replacing software with an existing SaaS (Type I)does not require using IaaS or PaaS as part of themigration effort. In most cases, this is by far oneof the easiest strategies to implement, but it couldprove difficult depending on the application involved.For example, migrating an on-premises database to anexternal SaaS model might incur security issues, orchallenges due to different semantics [7], [10].

Partial migration of software (Type II) can be ac-complished by using any combination of all three mod-els. Which model to use, and on which functionalities[7], depends on the application being migrated and theexpected gains of transitioning a particular part of thesystem to a cloud environment. Full stack migration(Type III) is the most common type of transition. Itoften demands the least amount of work, but usuallyfails to benefit from the cloud environment in terms ofscalability. It relies heavily on the company’s ability toencapsulate everything an application needs in terms ofits dependencies into a VM so it can run on an IaaS.Therefore, in this case the use of PaaS is not applicableand using third party SaaS should be avoided if onewishes to have self-contained applications.

Finally, full cloudification of legacy software (TypeIV) entails decomposing a given software into discretesubsystems and making each of them available as acomponent in the cloud. This can be done using SOA(Service-Oriented Architecture) migration techniques[9], [8], [11] or RESTful API driven development, whilehosting those sub-components as web services on anIaaS provider. However, the best way to produce cloud-native and cloud-aware applications is by applyingcloudification using the PaaS model. This is often thehardest strategy to adopt, but it is the one that provideshigher code reusability and complexity reduction fordevelopers. Besides, it takes the best advantage ofcloud characteristics such as application scaling andmultitenancy.

III. ROADMAP FOR A GRADUAL CLOUD MIGRATION

Ideally, having the software components available asa composition of services in the cloud (Type IV – seeTable I) is the most desirable scenario. Although thereis no guarantee to produce cloud-native applications outof migrated legacy software, new software is easier tobe developed with cloud-aware techniques if done usingthe PaaS model.

However, adopting full cloudification right fromthe start might incur in higher costs and difficulties.Therefore, we are investigating a roadmap for a smoothtransition from the most common IaaS approach to afully cloudified PaaS approach.1 In Table II we sum-marize our current proposal for this roadmap, whichprovides a four steps methodology based on the modelspresented in Table I.

Table II: Methodology for migrating legacy software towardsfull cloudification with PaaS

step 1 step 2

step 3 step 4

The steps pictured in Table II can be interpreted asfollows:2

1) The first step focuses on using the IaaS model fortransitioning legacy software. In particular, eitheran IaaS-based full stack migration strategy (I-III)or an IaaS-based partial migration (I-II) can beused. However, in order to prepare the softwarecomponents for the PaaS approach, either SOAtechniques or RESTful APIs should be employedin partial migration.

2) At step 2, the PaaS model is introduced and usedto migrate non-cloud software and also to use whathas been produced in step 1. The motivation is thatsome functionalities are easier to implement withPaaS and could be partially migrated directly intoa platform as a service environment.

3) In time, the PaaS-based partial migration (P-II) oflegacy software, and also for developing new ones,

1At this point we are assuming that the legacy software in questionis not available as a commercial SaaS, which motivates the effort oftransitioning it to the cloud instead of replacing it.

2Here we are adopting the abbreviation “(model - strategy)”, e.g,(P-II) means using model PaaS with strategy II.

should be preferred instead of the IaaS model.It should become the standard procedure, whichwould lead to a better use of the cloud infrastruc-ture.

4) Achieving cloudification with PaaS (P-IV) meansthat its functionalities are implemented as a com-position of services in a cloud environment, andare available for developers. At the end of thisstep, there should be no legacy software left formigration.

In other words, a company can start migrating itssoftware using the IaaS approach at step 1, but makingsure service-based techniques are observed. This mightbe harder for approach (I-III) as in this case we areusually interested in migrating the whole stack as aunity. In step 2, it may not be feasible to migrate somecore features directly using PaaS. However, as soon asthey are available as services in a cloud environmentafter step 1, the P-II partial migration can be initiated.At step 3, IaaS-based migration should be reduced.Features migrated with IaaS and PaaS should, therefore,complement each other. If the company’s objective isto migrate only a subset of legacy functionalities, theprocess can stop here. If the full migration is the goal,the approach P-IV (step 4) should be adopted.

IV. FOLLOWING THE ROADMAP

In this section we provide a background and a casestudy example on how to follow the aforementionedroadmap.

A. Background

CPqD myNet3 is a SaaS developed by migrating asubset of CPqD’s broader OSS solution, which enablesa quick and safe operation and analysis of complexnetworks, facilitating its maintenance and expansionin a georeferenced environment (see Figure 1). Forthis deployment, a CAD/GIS client had to be kepton premises, while a set of features had to be madeavailable on the web through a layer of servers, whichaugmented the database to maintain business rules andstandard definitions [12]. Hence, this migration effortis an example of the I-II quadrant (IaaS-based partialmigration) presented in the first step of Table II.

The development of this system posed a few chal-lenges. The use of a CAD client was essential due tothe large amount of graphical data to be interacted withCAD/GIS engineering tools. Thus, these features hadto be maintained as front-end to operate the system,meanwhile sophisticated schematics and network viewsshould be available via web. Also, significant effortwas undertaken to minimize data transfers between hostand client and to apply caching techniques to enhanceQoS at lower bandwidths. Additionally, security and

3http://mynet.cpqd.com.br/ - 06/04/2015

Figure 1: Outside plant web map with interactive informationabout the network.

authorization to safeguard sensitive data in a hostedenvironment were carefully considered [12].

B. Case Study

In this section we present a case of legacy applica-tion migration to the cloud using the partial migration(Type II) strategy. The application is used for accessinginformation about Telco hardware at specific locations.Given a hardware’s ID, the application queries thedatabase for its geographical information and plots itsposition on a map.

For the proposed scenario we are using myNet’sdatabase, which is hosted in a third party IaaS and is ac-cessible through web services. The platform as a servicewe are using is Openshift online,4 a commercial PaaSdeveloped by Red Hat, thus it is located externally toCPqD and accessed through the Internet. The softwaredevelopment happens on premises by a developer usingjava for the core functionality, java-script and HTML5for the user interface, and Openlayers5 for the mapinterface. The final application can be accessed fromwithin CPqD’s network through the Internet. A diagramdescribing this proof of concept scenario can be seen inFigure 2.

This data access through web service mechanismis one of the many components used by myNet in itscurrent form. Therefore, this particular migration hasbeen done in the past when CPqD moved myNet fullyto an IaaS provider (Type III). However, performing thesame transition by applying strategy type II (using PaaSfor the application logic and interface, and IaaS for thedatabase) provides the following benefits:

• It builds new features on top of functionalitiesmigrated in previous steps.

4https://www.openshift.com/products/online - 06/04/20155http://openlayers.org/ - 06/04/2015

Figure 2: Enabling database access in a PaaS environment.

• It allows the creation of reusable cartridges6 forfuture developers and system integrators.

V. DISCUSSION

The gradual migration approach proposed in thiswork provides a number of advantages. Starting with themost common IaaS-based strategy allows the companyto get used to cloud technology and to the developmentof cloud-based software without the need to commititself to a cloud-based development environment. How-ever, in order to fully benefit from the cloud, a PaaSmodel is preferable.

In terms of dependability and security [6], thisapproach presents a number of benefits that can beachieved, but there are also some pitfalls to be avoided.A gradual approach to migrating legacy software tothe cloud would provide greater reliability, since ateach step we get closer to a commitment to the newcloud environment. Additionally, the system continuesto provide its services as expected during the wholeprocess. A clear benefit of using PaaS is its positiveimpact on maintainability. Its modular structure, en-hanced code-reuse, and centralized structure make iteasier to extend, upgrade and maintain. Moreover, thefact that all instances of the resulting software are basedon the same system enhances its integrity by preventinginappropriate changes in core functionalities.

We believe that PaaS adoption may be an importantstep toward the development of a productive ecosystem,similar to “SAP Services Ecosystem” [14], but basedon the cloud. Such an ecosystem might facilitate thetransition of systems like Operation Support System(OSS) for Telco players from their currently in-housedevelopment and customization model to a global part-nership one with wider scope.

This is a work in progress. Future work encompassesthe implementation of steps 3 and 4 of the proposedroadmap, and a quantitative evaluation of each approachin terms of time, costs, demanded resources, and overallsystem complexity. We are also investigating how toproperly test the resulting software, and how to integrate

6In Openshift, cartridges are the plugins that house the frameworkor components that can be used to create and run an application [13].

automated testing into the PaaS. More experiments arestill being performed with step 2 in order to provideimportant functionalities to the PaaS in the form ofcartridges. This will make it easier to migrate theremaining features and develop new applications.

ACKNOWLEDGMENT

This work has been funded by the National Councilfor Scientific and Technological Development - CNPq(grant 440872/2013-8) and CPqD. We express our ap-preciation and gratitude to the late Dr. Geovane CayresMagalhaes, whose previous work with CPqD myNetand his support for this work were instrumental for themaking of this paper.

REFERENCES

[1] Armbrust, M. and Stoica, I. and Zaharia, M. and Fox, A. andGriffith, R. and Joseph, A. D. and Katz, R. and Konwinski,A. and Lee, G. and Patterson, D. and Rabkin, A., “A view ofcloud computing,” Communications of the ACM, vol. 53, no. 4,p. 50, Apr. 2010.

[2] Feathers, M., Working Effectively with Legacy Code, 1st ed.Prentice Hall, 2004.

[3] Fuhr, A. and Horn, T. and Riediger, V. and Winter, A., “Model-driven software migration into service-oriented architectures,”Computer Science - Research and Development, vol. 28, pp.65–84, 2013.

[4] Mell, P. and Grance, T., “The NIST Definition of Cloud Com-puting: Recommendations of the National Institute of Standardsand Technology,” NIST, Gaithersburg, Tech. Rep., 2012.

[5] Intel, “What Is PaaS ? How Offering Platform as a Service CanIncrease Cloud Adoption,” p. 12, 2014.

[6] A. Avizienis and J. Laprie, “Basic concepts and taxonomyof dependable and secure computing,” IEEE Transactions onDependable and Secure Computing, vol. 1, no. 1, pp. 11–33,2004. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs\all.jsp?arnumber=1335465

[7] Andrikopoulos, V. and Binz, T. and Leymann, F. and Strauch,S., “How to adapt applications for the Cloud environment:Challenges and solutions in migrating applications to theCloud,” Computing, vol. 95, pp. 493–535, 2013.

[8] Zhao, J. and Zhou, J., “Strategies and methods for cloud mi-gration,” International Journal of Automation and Computing,vol. 11, no. April, pp. 143–152, 2014.

[9] Baudoin, C., “Migrating Applications to Public Cloud Services:Roadmap for Success,” Cloud Standards Customer Council,Tech. Rep., 2013.

[10] C. Pettey and R. Meulen, “Gartner Identifies Five Ways toMigrate Applications to the Cloud,” p. 1, 2011. [Online].Available: http://www.gartner.com/newsroom/id/1684114

[11] Umar, A. and Zordan, A., “Reengineering for service orientedarchitectures: A strategic decision model for integration versusmigration,” Journal of Systems and Software, vol. 82, no. 3, pp.448 – 462, 2009.

[12] Magalhaes, G. C., “Case: O gerenciamento da planta da redena nuvem,” November 2012, presented at CPqD; Billing naNuvem: Oportunidade de Inovacao para Pequenas e MediasEmpresas.

[13] Pousty, S. and Miller, K., Getting Started with OpenShift.”O’Reilly Media, Inc.”, 2014.

[14] Greg Timbrell and Guy Gable, “The SAP Ecosystem: A Knowl-edge Perspective,” in Enterprise Resource Planning: Solutionsand Management. IGI Global, 2002, pp. 209–220.