R5 ES AP270 Conversion Strategy Final

Project EVO
Vodafone Spain Local Conversion Strategy
15 December 2009
Version 1.21
Document Status: Draft

Vodafone Spain Local Conversion Strategy 509928691.doc
Version:1.1 - DRAFT
Document Control
Location:
ClearQuest ID : EVOPR00072021
Document Owner
Owning Team Authors
Stefano Russo, Leonardo Bernal, Alessandro De Marinis,
ACN Data Migration Team
Vittorio Guarini
Document History
Author Date Version Comment
Alessandro De
30-11-2009 1.0 Initial Draft for Document Content Discussions
Marinis
Alessandro De
04-12-2009 1.1 First review
Marinis
Document Updates based on the Kick Off meeting with
Vittorio Guarini 15-12-2009 1.2
VF Group on 14th December 2009
Document Review & Signoff

Position Action Approved
Local Implementation Manager S
Local PMO IR
Local IT Lead FR
Local Process Lead FR
Local Financials Lead FR
Local Data Lead FR
S = Signed Approval Required, QA= Quality Assurance Review Required, FR = Formal Review Required, IR = Informal
Review, I = For Information.
Related Documents
Title Location
DP521 Data Migration Approach https://teamrooms4-
vista.vodafone.com/eRoom/Global70/Fatmatayekinni/0_44041
PM262_Roles_and_Responsibilities CQ EVOPR00072002
DP221_Deployment_Plan CQ EVOPR00072029
PL201_Requirements_Traceability_Matrix CQ EVOPR00072006
DP 512 Data Cleansing and Migration
CQ EVOPR00072028
Approach
Check ClearQuest Query: Public Queries -> Data -> AP363 Data Format
CBM Data Format Definitions (AP363)
definition
CBM Conversion Designs Check ClearQuest Query: Public Queries -> Data -> Conversion Designs
TA345_Development_Environment_Design https://teamrooms4-
Modified: 14/02/2021 Page 2 of 29

Version:1.1 - DRAFT
vista.vodafone.com/eRoom/Global70/Fatmatayekinni/0_1d43f
https://teamrooms4-
TE582 Master Test Approach
vista.vodafone.com/eRoom/Global70/Fatmatayekinni/0_1eb2d
TE582 Local Test Plan CQ EVOPR00072022

Version:1.1 - DRAFT
Table of Contents:
1. Purpose............................................................................................................................................................. 5
1.1 Overview..................................................................................................................................................... 5
1.2 Assumption.................................................................................................................................................. 5
1.3 Definitions................................................................................................................................................... 5
2. General Approach............................................................................................................................................. 7
3. Data Migration process...................................................................................................................................... 8
3.1 High Level Data Migration process................................................................................................................. 8
3.1.1 Data Cleansing and Enrichment............................................................................................................... 8
3.1.2 Data Extraction...................................................................................................................................... 8
3.1.3 Data Transformation.............................................................................................................................. 8
3.1.4 Data Load............................................................................................................................................. 9
3.1.5 Data Reconciliation................................................................................................................................ 9
3.2 Manual Conversion process........................................................................................................................... 9
3.3 Roles, Responsibilities and Deliverables....................................................................................................... 10
4. Data Migration Objects................................................................................................................................... 12
4.1 Data Migration Scope.................................................................................................................................. 12
4.2 Interdependencies....................................................................................................................................... 13
4.3 Selection Criteria / Historical Data Migration................................................................................................ 14
5. Selecting Tools Approach................................................................................................................................. 15
5.2 Data Transformation Tools.......................................................................................................................... 15
5.3 Data Loading Tools..................................................................................................................................... 15
6. Migration Flow and Migration Plan................................................................................................................. 17
6.1 Infrastructure and Test Systems.................................................................................................................... 17
6.2 Migration Phases........................................................................................................................................ 17
6.3 Cut-Over approach...................................................................................................................................... 18
6.4 Legacy Application Freeze........................................................................................................................... 18
6.5 Migration Window...................................................................................................................................... 19
6.6 Alignment with MDM................................................................................................................................. 19
6.7 Alignment with BI...................................................................................................................................... 20
7. Security Considerations................................................................................................................................... 21
8. Appendix 1 - Data Conversion Project Documentation.......................................................................................... 23

Version:1.1 - DRAFT
Table of Figures:
FIGURE 1 OVERVIEW OF HIGH LEVEL DATA MIGRATION PROCESS................................................................................................8
FIGURE 2 OVERVIEW OF MANUAL DATA MIGRATION PROCESS.....................................................................................................9
FIGURE 3 OVERVIEW OF CONVERSION RESPONSIBILITIES AND DELIVERABLES...........................................................................10
FIGURE 4 PROJECT AND MIGRATION PLAN.................................................................................................................................18
Figure 5 Alignment steps with MDM.........................................................................................................................................19
Table of Tables:
TABLE 1: DEFINITIONS...................................................................................................................................................................6
TABLE 2: OVERVIEW OF ROLES & RESPONSIBILITIES.................................................................................................................11
TABLE 3: LIST OF OBJECTS IN SCOPE..........................................................................................................................................12
TABLE 4: MIGRATION SEQUENCE FOR THE OBJECTS IN SCOPE....................................................................................................14
TABLE 5: LIST OF AVAILABLE LOAD TOOLS................................................................................................................................16
Table 6: List of project deliverables............................................................................................................................................24

Version:1.1 - DRAFT
1. Purpose
1.1 Overview
This document describes the local approach to data migration for the Vodafone Spain OpCo This document develops the
strategies down to the data object level and describing the processes and usage of tools.
The primary objectives of this document are to outline the strategy for the conversion of the business data from the legacy
systems to the EVO one and to define the list of Migration of objects in scope for Finance, Supply Chain and HR processes.
In particular this document will cover the following subjects:
 General Approach
 Data Migration process: Roles, Responsibilities and Deliverables
 Data Migration objects
 Data Migration tools
 Data Migration Plan
 Security considerations
1.2 Assumption
 This document is aligned with the Global Data Migration Approach.

 The Local Conversion Strategy should be aligned with the Local Deployment Approach. At the end of the Data
Migration Process, all the relevant data objects will be available in the EVO SAP system. The final loading into
productive environment will be part of the cutover activities, and will be detailed in the Cutover Plan, prepared on
an hourly base.
 Data load for different objects into the live environment will be executed in several steps according to cutover plan.
Some of the objects (esp. transactional data) will be uploaded in SAP trying to minimize the system freeze time and
avoid delta (delta = conversion related data created after the final extraction in the legacy systems) handling.
 The final scheduling of Data Conversion and related cutover activities will be finalized based on the previous testing
procedures (Mock Conversion).
 The scope of the Data Conversion is focused on the EVO SAP-ECC environment. Migration in other
systems/Database like MDM or SAP BI will be managed separately by Vodafone.
 The Data Object list is finalized at global level, but needs to be confirmed according to the local requirements. The
list will be finalized at the end of analysis phase.
 The Terminals are out of Spanish Data Migration scope due to Option B-.
 Manual data loading requirements should be confirmed per each object together with VF Spain.
 Configuration data in SAP is referred to as Customizing and will be part of the configuration activities as designed
in CBM and any of the localizations – it will be handled by the Release 5 Build team. Configuration Data is
managed across systems using the standard SAP transport system. The migration of configuration data will therefore
not be part of this conversion strategy as the Release 5 Build team is in charge of configuration.
 Configuration Data that cannot be transported across systems (manual activities to be executed environment per
environment) will be managed by Deployment team in the BAU landscape and will be not part of this conversion
strategy.
 No historical data (e.g. closed FI items, closed purchase orders) is being migrated into productive SAP
1.3 Definitions

Version:1.1 - DRAFT
Migration phase Definition

Data Cleansing Defines detecting and correcting (or removing) corrupt, duplicated or inaccurate records from a
record set in the legacy source systems. After data cleansing, data will be consistent with other
similar data in the source legacy system according to the data model used in that system. "Clean
Data" is unambiguous, correct, and complete.
The process of data cleansing may involve removing typos or validating and correcting values
against a known list of entities.
The Data Cleansing Approach documents describe these methods for each data object.
Data Enrichment Enrichment of a data record set with all the information needed in SAP data model but that are
missing or incomplete in sources legacy system. This will include any taxonomy (categorisation)
necessary to migrate from a non-SAP platform to SAP.
If the source system does not contain space to enter the required data, the enrichment can be
completed outside of the legacy system for example during or after data extraction. In any case
this activity has to be completed data transformation.
Data Extraction Defines data downloads from relevant legacy source systems in a predefined Unicode format.
Data Consolidation Defines the consolidation of business data elements from multiple sources into a centralized
database from source legacy systems. Additionally consolidation is required for master data that
has been migrated into the productive systems during conversion for previous releases and data
entered into the system after productive start.
Data Transformation Defines conversion of data format from a source legacy system and its structure into the target
data format and structure of SAP. The data transformation includes field and value mapping as
well as complex conversion rules.
Data Load Defines transfer / upload of the data in the required format (fields mapped, data cleansed,
consolidated, enriched) into SAP.
Data Reconciliation Defines process of ensuring that data is not lost and correctly converted during data conversion
processes.
Table 1: Definitions

Version:1.1 - DRAFT
2. General Approach
The data challenges of the EVO project cannot be seen as a single simple problem. Data activities are iterative, as the data
becomes increasingly more “ready” for acceptance into the EVO environment.
The readiness will be conditional on:
 The initial condition of the data (e.g. completeness, cleanliness)

 When the activities are started
 The time and resources available for data activities
 The effectiveness of the activities and the workflow between activities
 The amount of automation that can be brought to the process
 The degree of fit between the legacy data formats existing and the required data format for EVO SAP
The inclusion of the common coding (the codes assigned to business objects as they are consolidated across countries) and
associated activities also requires a more intelligent approach to the data activities.
The Data Migration consists of three main steps:
 Extraction – data needs to be extracted out of the legacy system

 Transformation – data needs to be transformed into the new SAP EVO format according to mapping rules
 Load – transformed data needs to be loaded into EVO SAP
EVO CBM Design as well as the local Fit Gap Analysis will provide the Functional Data Migration requirements for the
execution of the steps described above, including data mapping, value mapping and transformation rules that will be defined
during the design phase.
The Conversion strategy is focused on Data migration process into EVO - SAP ECC system. Data migration to SAP BI and
to MDM database will be managed separately by Vodafone.
Following documents will define the target requirements for the Data Migration process for Spanish data conversion:
 Data Cleansing Approach

 Data Migration Approach
 Conversion Functional Designs
 Data Format Definition
 Configuration Rationales
The objects loaded on the productive system have to fulfill several criteria:
 Master Data objects (e.g. Vendor, Material, Customer and Employee) and Transactional Data (e.g. Purchase Orders,
Open Items) have to be uploaded according to requirements of standard SAP field rules
 Master and Transactional Data has to fulfil requirements generated by the CBM / MDA
 Master and Transactional Data have to fulfil requirements of the local OpCo based on the completed Fit Gap
Analysis / Design completion.

Version:1.1 - DRAFT
3. Data Migration process

This section describes the overall Migration process, the roles and responsibilities between project teams and the involvement
of the local Vodafone Operating Companies
3.1 High Level Data Migration process
Data Migration means the migration of data into the EVO-SAP (ECC) domain and comprises the steps below.
Cleansing Data Data Data

Data
and
Extraction Transformation Load Reconciliation
Enrichment
Figure 1 Overview of high level data migration process
3.1.1 Data Cleansing and Enrichment
In addition to classical correction of data, data cleansing also includes:

 De-duplication - the process of removing multiple records or fields where they represent the same intrinsic value
 Enrichment - the addition of fields or content required to support the cleansing or migration process
 Consolidation - the process of harmonizing records and/or fields and potentially values where they exist in different
data sets but fulfilling the same business process
 Mapping - of fields and/or values against the defined definition
In general, where possible data cleansing and enrichment takes place in the source system. Where it is not feasible, it will
take place during or after the extraction phase and in any case before the transformation step. Further information about this
process can be found in the local cleansing approach DP512 Data Cleansing and Migration Approach.
3.1.2 Data Extraction
The data extraction and the corresponding selection of the appropriate tools (used in the legacy source systems) are under
Vodafone Spain responsibility, with support from Vodafone’s Global Data Team. In most cases export functionality within
the legacy application (SAP) will be used and enhanced accordingly to fit the extraction requirements defined by EVO design
(e.g. SAP ABAP standard/enhanced extraction programs,...).
The extraction methods and rules will be defined per each object in scope.
Vodafone Spain business needs to reconcile extracted data before to submit them for transformation phase.
3.1.3 Data Transformation
In the transformation stage, the actual data conversion process takes place. In this stage the extracted data is aligned to the
structure of the EVO system.
This will typically include the following processes:
 Partitioning the extract files

 Data (field and structure) mapping from source systems into the target system
 Apply a set of documented business transformation rules
 Consolidate data
 Perform data validation
 Converting data into a format that is compatible with the load program: i.e. can be consistently read and processed.

Version:1.1 - DRAFT
Besides the field mapping between the tables in the source and the target system, a value mapping table and a key mapping
table have to be set up. This is required to match the current configuration values or field values in the Legacy SAP system
against the future EVO configuration values, and for field entries according to mapping rules per field based on the EVO
business rules. This does not necessarily mean that every value can be mapped 1:1, but also n: 1 or 1: n. The latter might
imply dependencies to other fields which need to be considered in advance. The Value Mapping table and the Key Mapping
Table have to be prepared by Vodafone Spain and should be based on the value definition done during EVO VF Spain
configuration design.
3.1.4 Data Load
The output of the transformation stage will be loaded into the target systems. No further data transformation process should
be required during this loading process.
The mapping against the data fields in the load programs will have been performed as specified in the AP363 data format
definition and conversion functional designs defined for the CBM Solution.
3.1.5 Data Reconciliation
The purpose of reconciliation process is to ensure that no data is lost or incorrectly converted during data migration
processes. Responsible for the reconciliation process is Vodafone Spain with the support of Accenture (during the Mock
cycles run in the project landscape basing on the current contract agreements), that will provide the Reconciliation reports.
Reconciliation step has to be performed over the Data Migration process (extraction, Transformation and Load).
The sign-off of reconciliation results is under Vodafone Spain responsibility.
3.2 Manual Conversion process
Besides the normal Migration process, defined in the paragraphs above, some SAP objects need to be converted manually.
The drivers to considering this different approach could be related to the amount of records to be migrated (create a migration
tool for few records is not so efficient) or to the object complexity (some data cannot easily be extracted from legacy source
system for technical or business reasons).
Figure bellow explains the approach that will be used during a manual conversion approach.

Version:1.1 - DRAFT
Roles
Vodafone Spain Data Team Accenture Data Team
Manually Load
created file (LSMW or Other)
Activities
EVO CBM / MDA & OpCo Fit Gap Design

Migration/Conversion Functional Requirement
Figure 2 Overview of manual data migration process
3.3 Roles, Responsibilities and Deliverables
Different parties are involved in the data conversion process. Each of these parties will be responsible for certain activities.
The figures below show the overview of the Data Migration process for automatic conversion in terms of activities, roles and
deliverable responsibilities (for deliverable see also the Appendix 1). The responsibility for Data Cleansing, Data Extraction,
Data Transformation, Data Load (into BAU landscape) and Data Reconciliation activities will be in charge of Vodafone
Spain. The Data Load during Mock cycles run in the project landscape will be in charge of Accenture.
ACN/V
VF VF VF F VF**
*
Data
Data Cleansing Extraction Load Reconciliation
Transformation
Analysis Design Build Test Deploy
AP370 Data DP512  Data Migration TE483  Common AP568  Mock Data Conversion
Cleansing Approach (Accenture) Test Data Conversion Plan Executed - Including
Approach (VF) AP363 Data Format (Accenture) (Accenture) rehearsal. (VF +
AP270  Conversion Definition (VF MDA) Mock Conversion cycle Accenture)
Strategy AP374  Legacy Data execution (VF + Data Sign Off (VF)
(Accenture) Mapping (VF / Accenture) Accenture)
AP365  SAP Upload
Conversion Design
(Accenture)
AP356  Functional Design
Conversion (Accenture) * ACN will be responsible for load in PRJ landscape, VF in BAU landscape
**Collaboration with Accenture during Mock cycles run in project landscape

Version:1.1 - DRAFT
Figure 3 Overview of conversion responsibilities and deliverables
Furthermore, local requirements could have an impact on the data cleansing activities as well as the extract criteria.
In addition, the following roles and activities concerning data migration have been defined:
Role Activities
Data Cleansing,  Define local data cleansing plan and resources
Enrichment and  Work with business and IT experts to manage data cleansing
Reconciliation
 Drive through execution of cleansing activities
Coordinator
(Vodafone ES)  Reconcile data in the different migration steps (extraction, transformation and load)
insuring delta analysis and issue resolution
Data Lead – Extract  Manage conversion (Extract part) which comprises preparation of conversion plan for
(Vodafone ES) extract part, design of extract programs, delivery of data extracts for analysis in
transformation area and for mock conversions
 Align transformation and load part of conversion related activities
 Manage data cleansing related activities
 Manage cut-over related activities in close cooperation with process work stream
Data Lead –  Manage transformation part of conversion related activities including preparation of
Transformation conversion plan for transformation part, analysis of data extracts in transformation area and
(Vodafone ES) for mock conversions.
 Align extract and load part of conversion related activities
 Manage data cleansing and transformation related activities
Data Lead - Load  Manage load part of conversion related activities including preparation of conversion plan,
(Accenture for M1 gap analysis, design of conversion programs, plan and execute mock conversions, execute
and M2 / VF ES for conversion into production environment
M3 and conversion  Align extract and transform part of conversion related activities
in production)
Conversion  Define local data mapping plan in close cooperation with data transformation team and
Coordinator resource against this
(Vodafone ES)  Drive execution of mapping activities
 Prepare local migration plan for extract part
 Define the download programs for master and transactional data based on requirements
defined by transformation and load teams
 Prepare the design for the extract programs
 Work with business and IT experts to answer queries from other teams (e.g. on data aspects
of delivering a deployment plan for Master & Transactional data)
 Drive through execution of mapping activities
 Execute extraction activities
 Prepare Reconciliation requirements for Master and Transactional data
 Manage data fixing with business based on reconciliation log of Transformation and Load
 Manage business sign off of Master and Transactional data for the live environment
 Liaise with cutover coordinator to deliver the data activities in line with the migration plan
Table 2: Overview of Roles & Responsibilities.

Version:1.1 - DRAFT

Version:1.1 - DRAFT
4. Data Migration Objects
4.1 Data Migration Scope
The following data objects identified are a subset of the CBM design tailored on the Vodafone Spain Option B- scenario.
For each object the following information is shown in below table:

 Data object description
 Work stream (FI, SCM, HR)
 Module (B&P, LTD, OTC,...)
 Data type (Master data or Transactional data)
 Volumes (where available)
 Source system

Version:1.1 - DRAFT

Version:1.1 - DRAFT
Table 3: List of Objects in Scope.
(*) The volumes in the table have been retrieved during the TLS Workshops and have to be confirmed and integrated by
Vodafone
(**) To be verified if in scope or not
Note: Additional objects not included in the list above, have to be discussed and classified by the end of the analyze phase.
Additional comments on the migration object list:
 The migration scope includes only the objects to be migrated in SAP ECC. Data migration in other systems (SAP
BI, MDM) will be managed separately by Vodafone.
 The in house cash objects (Account, hierarchy, business partner and interest rates) are not in migration scope since
they will be created during the cut over by the R5 Deployment Team.
 Customer credit management is out of migration scope due to Option B-.
 Sales Order transactional data is out of migration scope due to CBM model and also to Option B-
 Sales condition is out of migration scope due to Option B-
 The Terminals are not in migration scope due to Option B-
 Since the terminal will be not migrated, the Open PO related to Terminals will not take in account.
 The Batch and the Material Classification are not in scope due to Option B-
 The Stock / Inventory is out of migration scope due to Option B-
 Catalogue migration is not included in the list since they will not be migrated in SAP - ECC but only in MDM
 Employee Absences will not be migrated as out of EVO scope
 Open Purchase Orders Attachments will not be in scope of Migration
 Employee Absences will not be migrated as out of EVO scope
 Open Purchase Orders Attachments will not be in scope of Migration
Open points to be classified:
 Usage of Sub assets: investigation ongoing to understand if this object is really out of scope or will be used.
To summarize, the scope of R5 Spanish Data Migration consists of 32 objects split as follows:
 20 FI objects
 66 SCM objects
 6 HR objects
4.2 Interdependencies
For the conversion and upload, different aspects have to be taken into consideration. One of these is the sequence of the
different migration steps.
First, it is very important to consider the sequence of objects. Objects that feed data into other objects have to be migrated
first before other objects that depend on a ‘superior’ object are migrated. Typically this means that master data needs to be
migrated before transactional data. Afterwards, a decision has to be making how to handle dependencies within an object. If
an object is migrated in several steps, the sequence has to be defined as well.
The table shown below contains the sequence that should be followed during the load of Spain Migration objects.
Further information on this topic will be provided in the AP365 Upload Conversion Design for each of the data objects in
scope.

Version:1.1 - DRAFT

Version:1.1 - DRAFT
Table 4: Migration sequence for the objects in scope
4.3 Selection Criteria / Historical Data Migration
In order to keep the complexity of the data migration manageable and to avoid causing unacceptable system downtimes the
data scope needs to be limited to the minimum necessary based on the EVO program guidelines. The DMA Team should be
involved to present the overall approach of the Data Cleansing and Data Extraction criteria.
General rules that need to be adhered are:
 The migration of closed, archived or historical data is NOT in scope

 No change documents (table CDHRD, CDPOS) will be migrated.
 The number of open items (e.g. purchase orders, etc.) need to be reduced to a minimum in order to reduce impacts
on business “Freeze Period” during the cutover period.

Version:1.1 - DRAFT
5. Selecting Tools Approach

1.1 Data Extraction Tools
Data Extraction and the corresponding selection of the appropriate tools (used in the Legacy Source Systems) are under
Vodafone Spain responsibility Spain with the support by Vodafone’s Global Data Tem. In most cases it is expected that
standard export functionality within the legacy application (SAP, ORACLE) will be used and enhanced accordingly to fit the
extraction requirements defined by EVO Design (e.g. ABAP standard/enhanced extraction programs, ... ).
5.1 Data Transformation Tools
For the Data Transformation activities (to be performed within a Transformation Staging Area) the selected toolset will
include:
 SAP Master Data Management (MDM) / Exchange Infrastructure (XI). The MDM tool will be used for
handling the Data Transformation & Consolidation activities for Master Data Objects. Focus will be given especially
to the objects that will be maintained centrally in EVO “Business As Usual” via SSC. (i.e. Material, Vendor).
 ETL / Informatica: The ETL Informatica tool will be used mainly for Data Objects where large data volumes are
involved combined with complicated conversion requirements. The focus will be on Transactional Data Objects.
 MS SQL server: for the mid size data volumes MS SQL server can be used.
 Excel, MS Access: for Data Objects of low volumes, complexity and/or limited conversion requirements, MS Office
products may also be used (Excel, MS Access) according to the needs identified per OpCo.
5.2 Data Loading Tools
SAP Data Loading tools are explained in detail in the Global document DP521 Migration Approach. Additional or new tools
may be defined based on migrating to EVO experiences for other OpCos.
1.1.1 Overview
This section describes the Load of transformed data into SAP which is the last logical step in the sequence of Extract,
Transform, and Load. The usage of selected tools will be described in context of their use during the project. Due to the fact
that Spain is not the first country where conversion will take place, many tools used during previous releases will be reused.
Nevertheless some additional tools might be created due to the following reasons:
 if country specific data format will differ from data format used in existing tools
 if during the tests the existing tools will not perform sufficiently enough
 if any errors are find in the existing tools
The tools will be modified by Accenture Data Team according to CBM design (after FIT/GAP analysis).
Data formats needed for load tools will be defined in functional designs completed in the CBM design. An excel table will be
included in the functional design documents to cover the required data format.
1.1.2 Tools available to support Data LOAD
SAP provides several types of automated methods for data load which short description are listed below. There are some key
principles that should be taken in account while choosing a tool.
Key Principles

Version:1.1 - DRAFT
 Use SAP standard programs wherever it is possible

 Conversion activities assume that conversion programs have been designed, developed and unit tested within the
framework of the development activity.
 The development manager ensures consistency between conversion plan and programming plan. This may lead to
re-prioritize development workload based on the conversion plan.
 Do not start programming activities prior to a formal sign off of conversion specifications.
 Each set of program (legacy side, SAP side) has to have a complete audit trail.
Standard SAP Where possible, Standard SAP Conversion Programs will be used for conversion. This will
Conversion Program allow the Conversion process to benefit from programs, which are fully supported and
tested by SAP
LSMW – Legacy The LSM Workbench is an R/3-based tool that supports transferring data from non-SAP
System Migration systems ("Legacy Systems") to SAP systems once or periodically. The tool supports
Workbench conversion of data of the legacy system in a convenient way. The data can then be
imported into the SAP system via batch input, direct input, BAPIs or IDocs.
BDC Upload An Accenture Excel Macro converts raw data into Batch Input session data which can be
Program uploaded into SAP. This program will be used in cases where Conversion Entity data is
simple, and where volumes do not warrant a new SAP Conversion Program and when the
input requires substantial integration to be performed by the user. In cases where the Excel
BDC Upload is to be used, the country conversion team is responsible for configuring the
excel spreadsheet with the data, and ensuring that the data is loaded properly into SAP.
Conversion Program New conversion programs will be designed to be used commonly, for conversions in
multiple countries, with multiple legacy systems eventually using the applicable
components of the integration architecture (e.g. the ETL functionalities).
Permanent interfaces In cases where a permanent interface will be established to a legacy system for later
system operations, it is preferred to use this permanent interface for the initial data upload.
Only in case the additional effort, timing considerations or any system restrictions (on
legacy or EVO side) are unacceptable, should new migration programs be developed.
Special care needs to be made when the permanent interfaces are using SAP XI in the
integration layer as this technology does not support high data volumes. Where possible
SAP standard load programs should be used.
Manual data The manual data migration is a favoured method in case of very small volume data objects
migration where any (semi-) automated methods does not justify the effort for the tool set up. But as
manual data migration is error-prone it is necessary, that the data to be entered is
maintained in advance in a template. This allows of pre-check of the data content, which
will be entered later on and reduces the effort time and error probability during the cut-
over phase.
Table 5: List of available load tools

Version:1.1 - DRAFT
6. Migration Flow and Migration Plan
6.1 Infrastructure and Test Systems

Within the EVO project, an architecture structure has been established. Development, test and Mock conversions will take
place on independent systems whereas the performance test will be conducted on the productive system. Each system will
host different clients for different purposes. The mock conversion test will take place on a different system from the others to
prevent from interfering with the other test phases. The Development Environment Design TA345 contains further
information about the architecture structure.
6.2 Migration Phases
The data testing activities are described in the Master Test Approach TE582. This paragraph complements the Master Test
Approach by detailing migration test steps – assembly testing and mock conversions – and their fits with the overall test
approach. There will be the following tests which each includes an error fixing phase:
 Component test / Assembly test: extract, transform and load all data objects with low volumes.
Upon component test completion, assembly testing will be performed for the whole activity but without integration
between the responsible parties. The assembly test ensures that related work units function properly.
Responsibilities:
o Vodafone Spain: Unit Test of Data Extraction and Data Transformation tools
o Accenture: Unit Test of Data Load tools
 Mock Conversion 1: all data objects, full volume; the data should be extracted from the production environment or
from a refreshed copy of production environment to ensure that the actual data volumes can be handled with the
method used. The resulting data load will be used for Product Test Cycle 1 and 2.
The first mock conversion is aimed at ensuring the whole conversion process takes place and the accuracy of data
mapping during transformation stage can be fully confirmed. Whether this requires a full load of transactional data
has to be checked and aligned with the local test team. The first objective of Mock 1 conversion is to produce a list
of issues to be analysed, solved and tested during the following Mock phases.
Responsibilities:
o Vodafone Spain: Data Cleansing, Data Extraction, Data Transformation and Data Reconciliation
(collaboration with Accenture)
o Accenture: Data Load and support VF in Data Reconciliation
 Mock Conversion 2: all data objects, full volume; the data should be extracted from the production environment or
from a refreshed copy of production environment to ensure that the actual data volumes can be handled with the
method used. The resulting data load will be used for Product Test Cycle 3 and will be basis for the User Acceptance
Test Cycle. The business will be required to verify the data loaded into SAP.
Responsibilities:
o Vodafone Spain: Data Cleansing, Data Extraction, Data Transformation and Data Reconciliation
(collaboration with Accenture)
o Accenture: Data Load and support VF in Data Reconciliation
 Mock Conversion 3: simulate go-live. Mock 3 will be included as part of Rehearsal, that is a simulation of the
whole cut-over process, including the complete (end-to-end) conversion process. Where there is any problem
encountered during this cycle, a quick solution has to be agreed among all parties and tested again during the Mock3
3 plan.
Responsibilities:

Version:1.1 - DRAFT
o Vodafone Spain: all phases (Data Cleansing, Data Extraction, Data Transformation, Data Load and Data
Reconciliation)
o Accenture: NA
 Productive Load – perform go-live where all data objects in the scope of conversion will be uploaded in SAP
productive system. Formal reconciliation and formal signoff will take place at each of the process steps. The system
will be transferred to the end user according to the sign-off procedures.
Responsibilities:
o Vodafone Spain: all phases (Data Cleansing, Data Extraction, Data Transformation, Data Load and Data
Reconciliation)
o Accenture: NA
As per the latest project plan, the overall migration process is shown in the following picture:
Figure 4 Project and Migration Plan
This calendar will be updated during design and build phases.
6.3 Cut-Over approach
Cut-over can only take place once the Mock 3 has been conducted successfully into dress rehearsal.
The order of data being migrated into the target system will need to take into consideration the object and functional
dependencies.
The approach for the cut-over is as follows:
 Reduce impact on the Business operations and customer experience

 Structure and controllable testing approach
 Iterative approach to building/enhancing the DM solution
 Shorten timescale to first cut-over and start of benefits realization
 Time to enrich and correct data
 Align with any VF-Spain initiative running in parallel ( for example legacy update)
6.4 Legacy Application Freeze

Version:1.1 - DRAFT
In order to build reliable extract, transformation and load programs it is essential that there are no major structural changes
(e.g. massive data field definitions changes) for the legacy applications relevant to data migration after the EVO design
phase.
Major data structural changes will include:
 Creating new master data objects & attributes in the legacy application under EVO migration.
 Modifying data types or field sizes for existing data object attributes.
 Mass change of critical field contents or their use in a significant way. This is especially important for fields that are
part of mapping tables (e.g. modifying legacy material hierarchies or GL account groupings that have already been
mapped to EVO global ones).
It is recommended that a freeze period starts 4 months prior to go-live.
6.5 Migration Window
It is essential to keep the impact on OpCo business to a minimum during the final data migration (Cutover).
The targeted approach is to perform Go-Live migration activities at Financial Month-End closing. The downtime will need to
be as short as possible to minimize business disruption. It is expected that the downtime will be minimized; exact estimate of
time needed for conversion can be defined after executing mock conversions. During this time the legacy and EVO systems
will not be available. Thus the data migration activities will also impact other OpCos which are already on EVO.
To reduce system downtime all data that is static (e.g. Master Data) should be migrated before the legacy system will be
taken offline. Changes to this data will need to be tracked by the local OpCo and will need to be introduced into the EVO
system manually after go live. Data that does not necessarily need to be available at go live can be migrated in the first weeks
after go live.
The length of the system downtime will be influenced by the volume of data that needs to be migrated during the downtime
period. Reducing the number of open transactions through planned ramp down procedures will be essential to obtain an
acceptable downtime.
Downtime also includes other activities during which the system(s) are not available for users such as system backup /
restore, reconciliation, sign off, etc. These need to be determined in cutover planning.
A forecast for planning purposes for the data migration part of the downtime will be made as soon as complete data extracts,
transforms and loads have been made. The initial plan should be available after the first mock conversion.
6.6 Alignment with MDM
It is important to align the data converted into SAP with MDM tool that will be used (for business as usual) to manage master
data in the first phase, of material master and vendor master in subsequent phases additional objects. This means that after
loading of vendor and material master data in SAP system, MDM system needs to be uploaded with data created in SAP.
Following figure shows the steps of the process in order to achieve this.

Version:1.1 - DRAFT
Extraction and Upload in SAP Upload in MDM

Transformation
Vendor master and Vendor master and

Material master Vendor master and Material master
data extraction and Material master data upload into MDM
transformation from data upload into SAP from SAP with existing
Legacy systems interfaces
Figure 5 Alignment steps with MDM
After loading of data into SAP of extracted and transformed data from the Legacy system, Interface that has been created for
initial load of MDM will be used in order to upload material and vendor master data for Spain release. Final upload to
productive MDM system will be executed after upload and sing-off of data in SAP productive system.
As already explained in the previous sections of this document, the Migration to MDM system will be not in scope of Data
migration Stream.
6.7 Alignment with BI
It is important to align the data converted into SAP with BI system. In order to achieve these BI loading programs will be
executed for upload of infocubes. Final upload to productive BI system will be executed after upload and sing-off of data in
SAP productive system.
As already explained in the previous sections of this document, the Migration to MDM system will be not in scope of Data
migration Stream.

Version:1.1 - DRAFT
7. Security Considerations
At the time of this document no special considerations regarding security, authorizations or SOX have been defined besides
the already indicated at the global document DP521 Data Migration Approach.
In general, from a security point of view the following topics have to be considered:
 Data security
 Data integrity
 Data protection
 Data access and authorisation
 Data encryption
 Audit requirement
 Data storage
 SOX
 IFRS
1.2 Data security

Loss or theft of data has to be prevented when loading data. Technically this will be ensured by using a VPN connection for
any Load activity of EVO SAP data.
1.3 Data integrity

Unauthorised change of data needs to be prevented. Technically this will be ensured by using a VPN connection for any Load
activity of EVO SAP data. Additionally the data reconciliation after load will be confirming the correctness and completeness
of data (see the following chapter).
1.4 Data protection

Unauthorised access to sensitive Security data (such as HR data) needs to be prevented. This is achieved by authorization:
 The transformation environment (including Oracle tables) will only be accessible by the transformation team
 The SAP environments into which the data is loaded will only be accessible to testers authorized by Vodafone.
1.5 Data access and authorisation

Transformation area toolset and loading tools should be configured / developed accordingly in order to make sure that only
authorised users/developers have access to Vodafone Productive Data. Appropriate authorisation roles should be set up to
make sure that separate user teams (developers, key users etc) will only have the appropriate system/data access.
1.6 Data encryption

Encryption of data is not possible due to high complexity and possible difficulties this could create during testing.
1.7 Audit requirement

Transformation Area Toolset as well as Loading programs should be configured / developed accordingly in order to allow
logging to the changes performed on Vodafone C3 Productive Data.
1.8 Data Storage

Version:1.1 - DRAFT
The standard for C3 information is:
 Electronic storage: encryption must be used to protect C3 information stored on a portable device, or where there is
a requirement to store or process C3 information in a non-secure environment. Operating system or database access
controls must be correctly configured to ensure authorised access
 Physical Access: C3 must not be left unattended. Physical media must be stored in a safe when not in use or being
worked on.
Generally No productive data should be stored in personal laptops or other “transportable” storage means (memory sticks
etc).
1.9 SOX
All data transformation is subject to full SOX compliance according to SOX requirements. The concrete SOX requirements
need to be described during the design phase.
1.10 IFRS
All data transformation related to financials need to comply with IFRS regulations in order ensure the reliability and
transparency of financial reporting.

Version:1.1 - DRAFT
8. Appendix 1 - Data Conversion Project Documentation

The EVO project follows the Accenture Delivery Methods (ADM). The following deliverable documents are planned to be
created for migration purposes or may include migration relevant information:
Deliverable Description Responsibility Stage

AP270 - Conversion This document outlines the plan for the Accenture Analysis
Strategy conversion of the business data from the legacy
systems to the EVO systems and obtains
commitment from the stakeholders to proceed
with the approach outlined herein.
AP370 - Data Cleansing This document represents the conceptual design Vodafone Analysis
Approach of data cleansing activities.
Data Cleansing refers to the activities that take
place to ensure that only relevant data is
extracted from current systems, and that the
data conforms to data standards before being
loaded into the EVO systems. This requires
detecting and correcting or removing corrupt,
inaccurate or obsolete records from a record
set.
DP512 - Data Migration The Data Migration Approach document Accenture Design
Approach provides a high level overview of how the
migration process is going to be performed on
the project.
The document covers the following areas:
- scope of migrations
- roles and responsibilities
- deliverables
- migration tools
AP363 Data Object This is a CBM document that describes all the Vodafone Design
Definition information used in EVO. The document is
updated during each release.
Data Format Definition This deliverable provides a definition of the Vodafone Design
source and target structure (e.g. data type and
data length).
D03 Data Object A summary of the most important facts for one Accenture Design
Migration Overview object. This document gives an overview of the
described data object providing the information
to be considered in the conversion rules
definition.
One document for each data object.
D04 Mapping Source to This document defines the field mapping Vodafone Design
Target between Legacy systems and EVO systems.
This document ensures the validity of all data
when going from the existing Legacy
applications to the EVO applications by
clarifying the sources for the EVO application's
data, specifying the rules for validating existing
data at the field level.
D05 Value Mapping This document defines the value/key mapping Vodafone Design
between fields of Legacy systems and EVO

Version:1.1 - DRAFT
Deliverable Description Responsibility Stage
systems.
This document ensures the validity of all data
when going from the existing Legacy
applications to the EVO applications by
clarifying the source values and calculating the
value for each EVO data element.
D06 Complex Mapping The document contains all local not standard Vodafone Design
Rules cases that are found during the mapping. This
document is optional.
D07 Local Cleansing Description of local requirements for cleansing Vodafone Design
Findings reports that should be created in the
transformation area. This document is optional.
D08 Cleansing Reports This is the extraction technical specification Vodafone Design
written by the local OpCo. This document is
optional.
D09 Extraction Technical This is the technical specification written by the Vodafone Design
Design extraction team.
D10 Transformation This document shows the dependencies Vodafone Design
Technical Design between data objects and should be prepared by
the team performing transformation.
AP365 SAP Upload This document shows the dependencies Accenture Design
Conversion Design between data objects.
AP356 - Functional This deliverable captures the functional Accenture Design
Design Conversion specification for how data converts from the
existing Legacy source into the EVO system.
TE483 - Common Test This deliverable contains the test data shared Accenture Build
Data between test stages used by the development
and testing teams. The common test data is
created, updated, and used in the preparation
and execution of each test stage.
AP568 - Mock This deliverable contains the plan for the Accenture Test
Conversion Plan conversion processes and steps of the system
from the existing system to the EVO system.
This deliverable contains the detailed steps that
must be done to convert the system, and also
the validation procedure to ensure the
conversion is successful.
Table 6: List of project deliverables
The mentioned deliverable documents in the table above are official deliverable documents confirmed at contractual level.
Next to these, there are some additional working and technical specification documents that are mandatory or suggested to be
used.
This enables all involved teams to create an overall documentation of the migration including extraction, transformation and
loading, independently from their responsibilities. Some of the documents will be created on data object level and others are
general overviews that help to understand the complete context of the migration. This approach reduces the volume of
documentation avoiding duplication and parallel work where possible.
Some of the documents depicted above will be edited by more than one team. In this case, they should be developed jointly,
especially where mapping or cleansing decisions have to be done between the groups. A clear view needs to be created to
understand on the responsibility, support, consultancy and informational activities.

R5 ES AP270 Conversion Strategy Final

Uploaded by

Copyright:

Available Formats

R5 ES AP270 Conversion Strategy Final

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

R5 ES AP270 Conversion Strategy Final

Uploaded by

Copyright:

Available Formats

Project EVO

Vodafone Spain Local Conversion Strategy

Document Status: Draft

Document Review & Signoff

Modified: 14/02/2021 Page 2 of 29

Modified: 14/02/2021 Page 3 of 29

Modified: 14/02/2021 Page 4 of 29

Modified: 14/02/2021 Page 5 of 29

In particular this document will cover the following subjects:

 This document is aligned with the Global Data Migration Approach.

Modified: 14/02/2021 Page 6 of 29

Migration phase Definition

Modified: 14/02/2021 Page 7 of 29

The readiness will be conditional on:

 The initial condition of the data (e.g. completeness, cleanliness)

The Data Migration consists of three main steps:

 Extraction – data needs to be extracted out of the legacy system

 Data Cleansing Approach

Modified: 14/02/2021 Page 8 of 29

3. Data Migration process

3.1 High Level Data Migration process

Cleansing Data Data Data

Figure 1 Overview of high level data migration process

3.1.1 Data Cleansing and Enrichment

In addition to classical correction of data, data cleansing also includes:

3.1.2 Data Extraction

3.1.3 Data Transformation

 Partitioning the extract files

Modified: 14/02/2021 Page 9 of 29

3.1.4 Data Load

3.1.5 Data Reconciliation

3.2 Manual Conversion process

Modified: 14/02/2021 Page 10 of 29

EVO CBM / MDA & OpCo Fit Gap Design

Figure 2 Overview of manual data migration process

3.3 Roles, Responsibilities and Deliverables

Analysis Design Build Test Deploy

Modified: 14/02/2021 Page 11 of 29

Table 2: Overview of Roles & Responsibilities.

Modified: 14/02/2021 Page 12 of 29

Modified: 14/02/2021 Page 13 of 29

4. Data Migration Objects

4.1 Data Migration Scope

For each object the following information is shown in below table:

Modified: 14/02/2021 Page 14 of 29

Modified: 14/02/2021 Page 15 of 29

Additional comments on the migration object list:

Open points to be classified:

Modified: 14/02/2021 Page 16 of 29

Modified: 14/02/2021 Page 17 of 29

Table 4: Migration sequence for the objects in scope

4.3 Selection Criteria / Historical Data Migration

General rules that need to be adhered are:

 The migration of closed, archived or historical data is NOT in scope

Modified: 14/02/2021 Page 18 of 29

5. Selecting Tools Approach

5.1 Data Transformation Tools

5.2 Data Loading Tools

1.1.2 Tools available to support Data LOAD