Software-as-a-Service Solution Implementation – Data Migration Perspective

Luba Shabnam, Farzana Haque, Moshiur Bhuiyan Service Consulting,

Enterprise Cloud Systems Pty Limited Sydney, NSW 2560, Australia

E-mail: {luba, farzana, moshiurb}@ecloudsys.com

Aneesh Krishna Department of Computing,

Curtin University Perth, WA 6102, Australia

E-mail: a.krishna@curtin.edu.au

Abstract— This paper presents a short case study on the implementation of SAP’s cloud based solution SAP Business ByDesign (ByD) in one of the largest state department within Australia. Software as a Service (SaaS) has its own implementation challenges from data migration perspective. This paper provides brief detail of the data migration process followed including lessons learned during the migration activities.

Keywords—SAP Business ByDesign (ByD), ERP, SaaS, Data Migration.

I. INTRODUCTION

This case study is based on the implementation of SAP Business ByDesign (ByD) [3] in one of the largest state department within Australia. This department was formed with a variety of existing but independent entities. Few ERP systems were operational to perform similar activities within the organisation. Many of the existing HR/Payroll and Financial Systems are disparate, unconnected and unable to supply the department management team with a single view of the organisation and its financial position. As a result, a transition and consolidation of existing ERP project was initiated in early 2012 with a goal to realise an integrated financial and HR/Payroll solution for about 80% of the department. The high level objective of this project includes the ability to perform consolidated reporting, be in control of core finance and HR/Payroll processes.

The department was running three instances of SAP ECC6 for Financials; SAP HR/Payroll and Aurion systems to manage human resources and payroll functions for 36 entities that fall in phase-1 of this project. SAP’s cloud based solution SAP ByD was selected as the prime ERP systems for consolidation of existing financial, HR and Payroll systems. This product supported the philosophy of the project by meeting the strategic objective for “system implementation will have to be scalable so that more entities within the department cluster can be moved on to it over time to take advantage of economies of scale and to reduce the cost of financial and management reporting for the cluster”.

The phase-1 consisted 36 entities and 5000 users across the department. SAP ByD was implemented with a tight schedule of four and half months, making it the biggest and fastest implementation within the world. This paper will focus on the data migration perspective of this project. It

will cover brief detail of the data migration process followed including lessons learned during the migration activities.

II. APPROACH TO DATA MIGRATION

SAP ByD has an in built data migration tool that requires the standard XML data templates to populated for data migration [2]. All data objects/ info types are represented by these templates. At the initiation of data migration activities it is important to have an understanding of the existing systems’ data volume and other relevant technical and non-technical information [1, 2].

This project went through 3 trial data conversions prior to production conversion. During each trial conversion and production conversion four processes were completed i.e. Data Extract, Data Cleanse, Data Load and Data Reconciliation. Data cleansing strategy was consulted and agreed with relevant data owners; data cleansing occurred in the staging area after extraction as opposed to cleanse data in sources systems. Each process was executed multiple times during each conversion. Below is an illustration of these processes:

Figure 1. Data Migration Process

III. DATA RECONCILIATION

The overall reconciliation approach proposed for this project consists of dissecting the migration process data flow into three reconciliation stages.

A. Extract Reconciliation The main focus of reconciliation in this stage is to ensure

that the data extracted is first and foremost comprehensive, complete and reconciled back to reports that were requested from and provided by the business. This in turns give both the data migration team as well as the business the confidence to move forward with the data migration.

B. Transform Reconciliation During this stage number of records and balances are

generated and reconciled back to extract balances, ensuring transformation is working as per adopted mappings.

2014 IEEE 38th Annual International Computers, Software and Applications Conference

0730-3157/14 $31.00 © 2014 IEEE

DOI 10.1109/COMPSAC.2014.90

612

Figure 2. Data reconciliation process

C. Load Reconciliation Upon final data upload, standard extract reports are

downloaded from target systems and reconciled back to the extracted data from the source systems.

Each stage (i.e. Extract – Transform and Load) was to be reconciled independently where upon completion, approval/sign off is a pre requisite for progressing into the next migration stage

IV. LESSONS LEARNED Below is an illustration of the lessons learned from the

data migration perspective:

A. Organisational Structure Design One of the pre-condition of successful data migration is to

get the organisation structure right. The department decided to consolidate/ merge its 36 entities into 24 entities. Business stakeholders were due to have a decision on the new organisation structure i.e. company code, profit centre, cost centre, projects etc prior to trial conversion one; but was unable to do so within the planned time frame. This resulted a conversion far from the to-be operational system. Trial conversion two and three has gone though a lot of changes through its organisation structure which resulted un-reconciled financial transactional data. It is extremely important to get this correct to detect foreseeable issues with the migrated data.

B. Chart of Account (CoA) CoA/GL mapping was another challenging area. The

decision was to use a single CoA across the department; hence legacy GLs had to be consolidated and mapped to the new GL codes. There had been cases where an expense account was mapped to a revenue account and vice versa –this is due to the rush in getting the product implementation completed in an extreme tight schedule. It is important that business have realistic timeframe to complete the CoA mapping.

C. SAP ByD Migration Tool SAP ByD’s data migration tool was very helpful in the

entire migration process. This tool performs a structural validation of the XML templates, and then proceeds to data

conversion before initiating simulation. Once the simulation is complete, it generates a reconciliation report prior to actual data load. This reconciliation report is one of the most powerful function of this tool. However, for high volume transactional data especially fixed assets data could take few hours to complete simulation and data load which puts an extra constraint on the entire migration process.

D. Keep it Simple Data staging environment decision should be based on

few parameters such as technical platform, data volume, and time required to set up the environment having the project deadline in mind. Since this was a time-compressed project, there was little opportunity to get the staging environment set up right. As a result, data migration team experienced numerous issues in generating the XML template as per the migration tool’s specification and data mapping. The use of a staging environment should be assessed carefully since sometimes is much easier to do a manual data population and use spreadsheets for data mapping.

E. Data Cleansing As per the project schedule, extracted, cleansed and

mapped data was to be loaded in SAP ByD via the supplied templates for trial conversion one within a window of only 4 weeks. The data migration team had to initiate and perform data cleansing and in parallel with the data extraction and build processes. Since undertaking cleansing activities in the source systems was not an option in the project’s context, the extraction process started before the cleansing process. Adata cleansing tool allows greater agility and efficiency because of its many built in functions. This project however, did not support having a data cleansing tool in place, which means the entire cleansing activities were dependent upon manual cleansing and custom script development. This resulted un-cleaned data loaded in the target systems including many rejections from the migration tool during structural validation and simulation.

V. CONCLUSION

In this paper we have illustrated a brief view of the data migration activities for a large scale cloud based solution implementation. We plan to provide a greater detail on this perspective including project management aspects in the future.

VI. REFERENCES

[1] Michael Willinger and Johann Gradl, Migrating Your SAP Data, SAP PRESS; 2nd edition (January 28, 2008)

[2] Thomas Schneider, SAP Business ByDesign Studio - Application Development, SAP PRESS; 1 edition (October 28, 2011)

[3] http://www.sap.com/pc/tech/cloud/software/business-management-bydesign/overview/index.html

613