CV020 Data Conversion Strategy Approach Issue 1.0

CV.
020 DATA CONVERSION STRATEGY

& APPROACH
ClinigenOne
Authors: Adrian Edwards

Richard Weaver
Simon Frooms
Last Updated: 29 June 2017

Document Ref: 300518881/Clinigen/CV020/001
Version: Issue 1.0
Approvals:
Jeremy Shaw
Stephanie Stacey
Helen Lench
CV.020 Data Doc Ref: 300518881/Clinigen/CV020/001
Error: Reference source not found
1 DOCUMENT CONTROL
1.1 Change Record

4
Date Author Version Change Reference

23-Aug-16 Adrian Edwards Draft 1a No Previous Document – Template & Structure
30-Aug-16 Adrian Edwards Draft 1b Updated following Data Conversion workshop
23-Nov-16 Adrian Edwards Draft 1c Updated and aligned to contract
03-Jan-17 Adrian Edwards Draft 1d Updated to reflect RCL following initial review meeting
28-Apr-17 Adrian Edwards Draft 1e Updated after full review of all 150+ RCL comments
08-May-17 Adrian Edwards Draft 1f Updated with feedback from Richard & Simon
06-Jun-17 Adrian Edwards Draft 1g Final update after walkthrough with Jeremy/Steph/Matt –
published for final review from Helen
29-Jun-17 Adrian Edwards Issue 1.0 Updated to Issue 1.0 after formal acceptance from Helen
1.2 Reviewers
Name Position
Jeremy Shaw ClinigenOne – Project Manager
Helen Lench ClinigenOne – IT Director
Richard Weaver Oracle – Solution Architect
Marcus Lawrence Oracle – Order Management & Pricing
Prasanna Renganathan Oracle – Warehouse Management
Renato Carotenuto Oracle – Financials Consultant
Peter Beverley Oracle – Financials Consultant
Robin Marks Oracle – Projects Consultant
Emma Moran Oracle – MDM Consultant
Matthew Davis ClinigenOne – MDM Team
Jake Scothern ClinigenOne – Business Analyst
Stephanie Stacey ClinigenOne – Business Lead
Donna Holt ClinigenOne – Business Lead
Error: Reference source not found Data Conversion – Testing Strategy 2iixxiii18ii
File Ref: 756538509.docx
Contents
1 Document Control..................................................................................................... ii
1.1 Change Record........................................................................................................... ii
1.2 Reviewers.................................................................................................................... ii
2 Introduction............................................................................................................... 1
3 Background............................................................................................................... 2
3.1 Scope.......................................................................................................................... 2
4 Data Acquisition and Conversion Overview...........................................................3

4.1 Project Management................................................................................................... 3
4.2 Task and Work Products............................................................................................. 3
4.3 Team Organization...................................................................................................... 3
4.4 Resource Requirements.............................................................................................. 4
4.5 Data Cleanup Process................................................................................................ 4
4.6 Testing Strategy.......................................................................................................... 5
4.7 Acceptance Criteria..................................................................................................... 6
4.8 Metrics........................................................................................................................ 6
4.9 Risks........................................................................................................................... 7
4.10 Responsibilities........................................................................................................... 7
5 Data Acquisition - Strategy......................................................................................8

5.1 Logical Architecture..................................................................................................... 8
6 Data Conversion - SCOPE........................................................................................9

6.1 Objects in Scope (to be loaded)..................................................................................9
6.2 Objects out of Scope (not being loaded)...................................................................11
7 Data Conversion - Constraints and Assumptions................................................12

7.1 Cleanup Criteria........................................................................................................ 12
7.2 Minimum Attributes required.....................................................................................12
8 Data Loading - Approach........................................................................................13
9 Data Conversion – Testing Strategy......................................................................16

9.1 Data Migration Validation..........................................................................................16
9.2 Quantitative Reconciliation.......................................................................................18
9.3 Functional / Business testing.....................................................................................18
10 Open and Closed Issues.........................................................................................19

10.1 Open Issues.............................................................................................................. 19
10.2 Closed Issues............................................................................................................ 19
Error: Reference source not found Data Conversion – Testing Strategy 2iiixxiii18iii
2 INTRODUCTION
This document is used to define the strategy and approach for meeting the previously defined
Data Conversion needs for ClinigenOne as per the commercial contract. It has two major
components:
 Data Conversion Strategy
 Data Quality Strategy
The Data Acquisition component defines the scope and objectives as well as the critical success
factors and risks associated with the data extraction, transportation, transformation and data
loads to support the solution.
The Data Conversion component is intended to provide a road map for performing the conversion
of data from the legacy systems to the new Oracle system. The tasks and resources needed to
fulfill this strategy are also discussed in this work product.
The Data Quality component defines the approach for managing data quality for the processes for
ensuring ongoing data integrity. Also included in this component is a high-level assessment of
the source data
The Data Acquisition, Conversion and Data Quality Strategy is used as follows:
 The Data Acquisition and Conversion team uses this document to communicate to
the client the strategy for successfully converting their legacy data to the new Oracle
system.
 The Data Acquisition and Conversion team uses this document as a road map for
performing the conversion. All members of the team, both consultants and client
team members, should understand and follow the same strategy.
 The project manager uses this document to understand how the Data Acquisition and
Conversion team plans to perform the conversion, and how the conversion effort may
impact the overall project.
Therefore, the readers of the Data Acquisition, Conversion and Data Quality Strategy include the
following:
 the Client Conversion Project Leader & ClinigenOne Management Team who should
sign off on the strategy
 each member of the Data Acquisition and Conversion team
 the project leader who needs to review and determine what other groups should be
given the document
Use the following criteria to review this work product:
 Is the strategy understood by those on the distribution list for this work product?
 Are all assumptions, constraints, and risks which could impact the Data Acquisition
and Conversion process stated and understood?
Error: Reference source not found Data Conversion – Testing Strategy 2123181
3 BACKGROUND
Clinigen are currently in the process of implementing Oracle E-Business Suite 12.2.5 (EBS) as
part of their overall ClinigenOne implementation project alongside Master Data Management
(Product & Customer Hubs), Oracle Business Intelligence Applications (OBIA), Oracle Service
Cloud and Hyperion Financial Management. The new applications will be deployed and hosted in
a service provider’s network of Data Centres.
Each conversion object will be undertaken using one (or more) of the following six methods:
 Bulk Load - Mass load of static data into MDM applications using excel templates
 SQL*Loader - Oracle standard tool for loading data into staging/interface tables
 PL/SQL - Custom Conversion/Integration Routines
 WebADI - Data loaded using desktop spreadsheet integration
 DataLoad - Data loaded using spreadsheet template directly into application forms
 Manual - Data manually keyed by data entry operators
In the case of Clinigen, for E-Business Suite, the data conversion method for each data object
has been determined based upon data volumes and complexity and is reflected in the contract.
Where available/possible any data migration scripts/routines created for the initial IDIS migration
will be leveraged in order to avoid redevelopment, however all of these will need to be individually
examined by OCS to ensure that they are compliant with the new application release and target
ClinigenOne Application architecture as per the approved MC.010 document.
Manual conversion will be used for low-volume and configuration.
DataLoader (www.dataload.com) is a third-party (non-Oracle) product and has a classic (free to
download) version and a professional version with more features (for use with HTML forms). The
licensing of the professional version of DataLoader (if required) for use on the project is the
responsibility of Clinigen, but there are no current plans for it’s use.
3.1 Scope
This Conversion Strategy & Approach document ONLY relates to the migration of data into the
Oracle eBusiness suite application for ClinigenOne.
Once the data has been loaded and reconciled in eBS, it will then be available for analysis from
the BI Applications after running the standard ETL routines. i.e. there is NO separate data
migration into OBI Application.
There are NO plans or obligations from OCS to provide ANY data migration into the Service
Cloud (Service Requests, OPA rules), Cliniport, Single Sign-On, or any other applications forming
part of the overall ClinigenOne solution.
In addition, as per the agreed contract, there will be no migration of any historical transactional
data into the eBusiness suite application. Should this be necessary then this will be subject to
formal change control. (See Open Issues section at the end of this document).
The reconciliation, verification and validation of full source to target traceability to meet the needs
of IV&V, internal QA, audit etc. is the responsibility of Clinigen. Advice & Guidance to the
reconciliation approach and use of standard eBS functionality and reports to support this activity
will be provided by OCS.
4 DATA ACQUISITION AND CONVERSION OVERVIEW

Oracle’s Unified Method®(OUM) is being used on this project. OUM’s Data Acquisition and
Conversion process is being used to accomplish the data acquisition, data conversion and data
quality requirements of this project.
4.1 Project Management

The Manage Focus Area (Project Management) is being used to manage this project and as such
will also be used to manage the Data Acquisition and Conversion process. Please refer to the
Project Management Plan for specific information on the following:
 Issue and Problem Management
 Configuration Management (Version Control)
4.2 Task and Work Products

The tasks that will be executed and the formal work products that will be produced for the Data
Acquisition and Conversion process are as follows:
Task Work Product

CV.020 - Define Data Conversion Strategy & Approach Data Conversion Strategy (Single document)
(OCS)
CV.027 - Perform Data Mapping (OCS/Clinigen) Data Mapping (per conversion object)
CV.040 - Conversion Design (OCS) Conversion Component Designs (for SQL objects – 1
per object)
CV.050 - Prepare Conversion Unit Test Plans (OCS) Conversion Test Plans (for SQL objects – 1 per
object)
IM.090 - Conversion Installation Routine (OCS) Install instructions for SQL based objects (for SQL
objects – 1 per object)
Note: Other outputs from the Conversion workstream may be needed and reflected in the
conversion ‘sub-plan’. The above just comprises the contractual deliverables from OCS.
4.3 Team Organization

4.3.1 CONVERSION TEAM
The organization structure for the Data Acquisition and Conversion team for this project is as
follows:
 Oracle Conversion Team
o Oracle Conversion Co-Ordinator
o Oracle Technical Lead
o Oracle SSI Data Conversion Team
 Clinigen Conversion Team
o Conversion Project Manager
o Master Data Management
o IDIS Oracle 12.1.3 Data Extract Team
o Clinigen Exchequer Data Extract Team
o ClinigenOne SME’s (data mapping, cleansing & reconciliation)
4.4 Resource Requirements

The following software and hardware requirements are considered a part of the Data Acquisition
and Conversion effort:
4.4.1 SOFTWARE
The application software considered as part of this project includes:
4.4.1.1 Legacy Environment (Source):
 Oracle eBusiness Suite R12.1.3 (IDIS)
 Exchequer (Clinigen) – 1 per existing legal entity
 Spreadsheet (off system data) e.g. Asset Register
4.4.1.2 Oracle Environment (Target):
 Oracle MDM (Customer & Product Data Hubs)
 Oracle eBusiness Suite R12.2.5 (ClinigenOne ERP)
4.4.2 NETWORK / FILE TRANSPORT
SFTP will be used to transfer files from a local Clinigen file system to the E-Business Suite Unix
server, which is hosted in a Clinigen/3rd Party Data Center. This will only be used for E-Business
Suite PL/SQL data conversion objects.
All other conversions will be via the desktop.
4.4.3 STAFFING
The combined Clinigen/Oracle staff involved with this project must have the background,
experience, and training where necessary in the following areas:
 PL/SQL
 WebADI
 DataLoad
 E-Business Suite
4.5 Data Cleanup Process

4.5.1 DATA CLEANUP
In all cases, Data Cleansing, Deduplication, Data Mapping (to target configuration as provided on
CV.027 documents) and data manipulation to common naming standards and conventions will be
the responsibility of Clinigen.
Specifically, for Static/Master Data objects, primarily Employees, Items, Customers, Suppliers and
Banks/Branches a FULL and complete dataset will be loaded covering the WHOLE organizational
scope to deployed by ClinigenOne, i.e. UK & US covering BOTH IDIS and Clinigen.
As a consequence of the split go-live, it will be necessary to maintain the above data objects in
parallel between the time of the Clinigen (Burton/Stretton) go-live and the IDIS
(Weybridge/Byfleet) go-live.
The key steps in this cleansing process are:
 The source data needs to be cleansed by Clinigen staff to ensure only the required
data is converted. This would be first activity in the conversion cycle.
 Initially this activity will focus upon Master Data (Items, Customers & Suppliers) by
firstly removing obsolete data (i.e. where there has been no activity for an agreed
period of time and approval of obsolescence obtained) before standardizing the data
to agreed naming conventions etc.
 Duplicate entities should be removed or merged as part of the Data Cleanup

processes. Rules to identify duplicate records will need to be defined and agreed
together with mappings of source to target values to ensure that related transactional
data can be loaded.
 Multiple conversion loads will be conducted in the development environments which
will identify the data dependency/integrity check, based on these results data
fixes/data cleanup will need to be done and managed by ClinigenOne. This activity
will commence significantly in advance of the go-live for Burton/Stretton in order to
mitigate the risk of data migration being on the critical path of the overall
implementation.
 Once a clean and complete dataset for static data has been established, a method for
maintaining this data must be agreed and deployed. This MUST include the period
between the 1st & 2nd go-lives (for Finance & Supply Chain). It is critical that this does
NOT require repetition of the cleansing, de-duplication and mapping for each data
conversion cycle i.e. by means of holding the static data to be converted in a
separate data store.
 Following the loading of the static data, the transactional data can then be mapped
and loaded, ideally following cleansing of open but obsolete transactions (e.g. old
Sales Orders never fulfilled, open/partially open Purchase Orders for which no further
activity is expected, write-off of old/uncollectable debt or liabilities)
4.5.2 KEY DATA TRANSLATIONS

For specific data attributes (mainly on transactional data where automated PL*SQL scripts are to
be used to populate interface tables), it will be necessary to define and build translation or
mapping rules
 An example of this might be taking the date format that exists in the legacy system
and converting it into an Oracle EBS format. There may be several or no translation
programs, depending on both the type of data coming across and the format of that
data.
 Translate reference data from source system (using cross reference data) to Oracle
E-Business Suite when data is loaded e.g. old payment terms to new payment terms.
Mapping of lookup and value set will be provided in the relevant CV.027 mapping
documents.
 Full traceability, extract criteria and data completeness is Clinigen’s responsibility
4.6 Testing Strategy

The agreed upon Data Acquisition and Conversion work products should be signed off by those
client representatives who are responsible for the success of the project. Four levels of Data
Acquisition and Conversion testing has been identified:
 Unit - The unit tests determine that each conversion program module is successfully
completing the task as intended. For example, a unit test should test to verify that the
download program module has extracted the expected number of records from the legacy
system and has loaded the expected number of target records. This will be supplemented
with spot-checking a small data set within the application.
 Business Object - The business object test verifies that all data attributes that have been
converted to the target application is accurate including user definable attributes.
 Validation - Conversion validation testing tests that the converted legacy system data
functions properly within the Oracle E-Business Suite applications and in a consistent
manner with any new data entered as part of normal daily business. The conversion
validation test verifies that the data can complete the entire business cycle for each
specific data object.
 Reconciliation – The reconciliation testing verifies that the result of loading the transaction
data can be financially (or otherwise) reconciled back to the source applications for each
individual sub-ledger level. This also needs to ensure that the lowest level of data is
correct e.g. stock levels by sub-inventory/locator, cost layers, prices on blanket PO’s, LOT
numbers, serial numbers, open sales orders etc.
As a minimum, the following criteria should be considered while performing data integrity and
conversion integration testing:
 record counts
 hash totals
 balances
 Accounting entries (balanced transactions with correct accounting)
4.7 Acceptance Criteria

4.7.1 DELIVERY
All conversions will be deemed to be delivered following successful testing. Data Acquisition and
Conversion data acceptance criteria should include the following:
 ability to transact against the converted dataset in a full lifecycle
 ability to reconcile all loaded information
 definition and acceptance of any variances for each data object (by quantity and/or
amount)
4.7.2 DATA ACCEPTANCE
A conversion’s acceptance criteria will be measured by the completion and sign-off of key
deliverables as specified in the Project Management Plan.
Clinigen must establish specific data ‘owners’ for each data object who will support the
development of reconciliation and acceptance criteria.
Each deliverable in the conversion process will be reviewed and approved by the Clinigen
representative/SME responsible for that business data object.
4.8 Metrics
Key metrics for the Data Acquisition and Conversion process for this project are as follows:
 existing record volumes by entity (total)
 volumes of data to be converted by entity (sub-set once selection criteria applied)
 throughput of the conversion interfaces (to ensure no performance constraints)
 elapsed time by object
 elapsed time in total including dependencies, reconciliations and backups
These are used to confirm that the most appropriate method of data conversion has been
selected and are also needed to establish the elapsed timeframes for the data conversion as a
whole.
The overall timescales for data migration activities will be tightly woven into the overall transition
plan, this must also factor-in the actual time required to extract, prepare and load any transactions
which are to be performed manually.
4.9 Risks
The following Data Acquisition and Conversion key risks have been identified as having an impact
on the overall success of the project:
 Extracting data from the identified source systems
 Performing data cleansing, enrichment & mapping of extracted data (both effort and
qualified resource with appropriate business/data knowledge)
 Approval obtained to use the source data from the business data owners (especially
HR) and or any data ‘obfuscation’ activities
 Management of incremental change of static data once a baseline has been
established
 Risk of continued changes to business mappings as the overall solution evolves from
CRP3 through all testing phases through to go-live
 Scope creep due to source or target data being ‘missed’ upon initial review.
4.10 Responsibilities
The responsibility for performing each detailed activity will be established in detail as part of the
detailed Conversion ‘sub-plan’. However, at a high level (consistent with the formal contract), the
components are split as follows:
1. Data Selection criteria – Clinigen*
2. Data Acquisition, cleaning & mapping to target format – Clinigen
3. Provision of required target mapping values and formats – OCS
4. Provision of input data for loading – Clinigen
5. Sequencing of load process - OCS
6. Execution of load process – OCS**
7. Resolution of source data issues – Clinigen*
8. Quantitative reconciliation – OCS
9. Qualitative reconciliation – Clinigen*
10. Validation & Signoff – Clinigen*
*OCS will support the above Clinigen activities with advice and guidance.
**All programmatic data conversions will be performed by OCS with any ‘manual’ load activities
using WebADI or Dataload done collaboratively with the relevant SME, with any direct manual
input into the application through standard forms being performed by Clinigen
5 DATA ACQUISITION - STRATEGY

This section describes the data acquisition approach to be used for Clinigen to extract data from
different source systems and to prepare data for target system.
Responsibility for the Data Extraction & Preparation from the legacy systems/data stores lies with
ClinigenOne.
Due to the high level of data cleansing, deduplication, enrichment and mapping required, together
with the need to manage the incremental change of static data between conversion cycles it is
recommended that Clinigen develop a separate data conversion data store(s) in which the
extracted data can be managed.
For each object to be migrated, it will be necessary to maintain the referential integrity of the
source to target mapped values to ensure that any transactional data is consistent with the
underlying static/master data.
The extracted data will then be extracted into the required format for loaded as provided by the
OCS team.
5.1 Logical Architecture
5.1.1 DATA STORES

The following table describes the main data stores and their purpose. The data stores are
referenced later in the data flow section of this document.
Seq. Data Store Object/Purpose Comment

1 IDIS eBS All current IDIS Static Data
2 All current IDIS Transactional Data Open transactions only
3 Exchequer All current Clinigen Static Data
4 All current Clinigen Transactional Data Open transactions only
5 Spreadsheet Off system business data e.g. Fixed Assets register
6 DATA CONVERSION - SCOPE

Detailed conversion requirements are documented in the formal contract, the key agreed
approach is as follows:
Migration of historical transactional data will not be performed, with the exception of GL Balance
history for the current and prior financial year at the time of go-live. When there is a business
need to reference historical data, then this will be achieved by retaining the legacy application in
‘Read-Only’ mode. Data migration scripts used for the original IDIS data migration will be
leveraged, although changes to the configuration and architecture will require each script to be
reviewed and adapted individually.
In summary the following legacy system data objects/entities will be converted to the Oracle
applications:
6.1 Objects in Scope (to be

loaded)
6.1.1 PROGRAMMATIC DATA CONVERSION ROUTINES
 STATIC DATA
o Banks & Branches
o Suppliers/Supplier Sites/Contacts
o Supplier Bank Accounts
o AR Customer Data e.g. Profiles – outside scope of MDM **(see note1 below)
 TRANSACTIONAL DATA
o Standard Purchase Orders (approved only and where not fully invoiced or
receipted)** (see note 2 below)
o Inventory Receipts (without requiring any WMS putaway)
o Consignment Stock (Vendor & Customer owned Inventory)
o Stock on Hand with associated Lots & Cost Layers (see note 3 below)
o Sales Orders** (see note 4 below)
o Open (fully unpaid) AP Invoices
o Open (unreceipted) AR Invoices
6.1.2 WEBADI
 FINANCE Related
o General Ledger Balances (Actuals) – loaded as summary journals per period
o General Ledger Balances (Budgets)
o Unreconciled Bank Transactions (as Journals)
o Fixed Assets
 HCM Related
o Current Employees & Address (Staff & Contingent Workers)
o Current Assignment
o Current Payroll Bank Details
o Salary for Current Employees including history
o Current recurring Pay Elements & Last Bonus

o FTE
o Emergency Contacts
6.1.3 BULK DATA LOAD (INTO MDM) -

 Parties/Customers/Accounts – both Persons & Organizations
 Customer Addresses/Site Usages/Contacts
 Customer Relationships (Party Relationships)
 Items & Bills of Material
6.1.4 MANUAL ENTRY (BASED ON VOLUMES AND COMPLEXITY)

 Routings & Operations
 Projects
 Project Agreements
 Project Funding
 Customer Relationships (Account Relationships)
 Non-Inventory Requisitions
 Non-Inventory Receipts
 Stock Reservations (if required)
 Back-to-Back/Drop-Ship Sales Orders
 Pre-Payment Sales Orders
 Unapplied & On-account Cash Receipts
6.1.5 DATALOAD
 Supply Chain
o Pricelists
o Modifiers/Qualifiers
 Finance
o Historic Exchange Rates (relating to open transactions)
**NOTE1: For Customer Information a 2-phase load process will be required. Initially to load base
data into Customer Data Hub using spreadsheet based templates, followed by a separate
process to ‘enrich’ the Customer Account specific data e.g. Customer Profiles with an update
using the Customer Open Interface.
**NOTE2: For blanket purchase orders, any ‘in flight’ releases will be migrated as standard
Purchase Orders. Any BPA’s without pending releases will be converted as per the original full
amount as BPAs
**NOTE3: It is assumed that there will be a full stock-take (in Clinigen’s warehouses) at the point
of migration of stock-on-hand.
**NOTE4: Only ‘standard’ Sales orders which have not been shipped will be migrated
automatically. For ‘special’ scenarios (assumed to be low volume) e.g. Prepayments, Back-to-
Back, Drop-Ship these will be converted manually.
It is critical that there are no outstanding picking or packing tasks at the time of migration.
6.2 Objects out of Scope (not being

loaded)
For purpose of clarity, some of the key objects will NOT be migrated are
 STATIC DATA
o Ex-Employees
o Customers never traded (unless created recently pending new orders)
o Patient data
o Service Cloud Static Data (i.e. Data maintained within Service Cloud
independently of any eBusiness integration)
 TRANSACTIONAL DATA
o Data attachments – any attachments/documents related to existing static or
transactional data will not be converted, but a reference to a document (e.g. URL
can be migrated).
o ANY transactional data to support product ‘recall’ process relating to historical
products and shipments.
o Internal Service requests – any ‘open’ Service requests at the time of data
migration will need to be opened as new ‘incidents’ in the Service Cloud solution
o Inventory Requisitions – all open inventory requisitions will need to be approved
and converted to Purchase orders in advance of migration
o Historical Project Transactions – there will be no transactional history related to
projects migrated (i.e. no historical costs, revenues or invoices)
o Employee Expenses – it is expected that all claims will be processed and paid in
advance of the cutover with a ‘cutoff’ date communicated as part of the transition
planning
NOTE: It should NOT be inferred from the above list that anything not included in the ‘not
in scope’ list is therefore deemed to be in scope !
7 DATA CONVERSION - CONSTRAINTS AND ASSUMPTIONS

The following constraints and assumptions apply:
 Early conversion planning and coordination between Oracle and Clinigen is needed,
in order to stay within agreed timescales.
 Stable connectivity to all instances until completion of migration to production
instance.
 Well-defined Conversion technical architecture and infrastructure, which will allow
conversion teams to hit the ground running.
 Final application setup is performed on instance before data migration activities
 The availability of a stable environment wherein testing of the migration process can
take place without the risk of interference from other aspects of the implementation.
 The availability of the required hardware/software resources for use by the
participants in the data migration.
 The availability of appropriately trained Clinigen staff having knowledge of the various
Source systems to perform identification and completion of key data extracts, clean
up, data joins and transformations.
 Clinigen employees need to be identified as the owners of the data. In certain
scenarios this may be 2 SME’s depending on familiarity of the source systems. They
must be available at regular intervals throughout the activity.
7.1 Cleanup Criteria

As part of the data cleansing in the ‘staging’ database, it is strongly recommended that the
following checks are performed before providing the extract data files.
1) Duplicate records derived from the source system instances have to be eliminated in the
‘staging’ database before data is extracted to target data files, but with mapping cross-
references to source data maintained to enable transactions to be related to the correct target
object.
2) Where ‘NULL’ Effective End Dates are required they will be calculated based on next change
Effective Start Date, otherwise Effective End Date should be the explicit date “4712-12-31” if
there is no next change.
3) Check for active child records where parent record is inactivated and ensure that both are
active (or inactive) depending upon business/data needs
4) Check for child records (orphans) where parent record is not present.
5) Check that none of the source system data attributes includes the ‘|’ pipe character or any
other delimiter or control character which may cause the load process to fail .
7.2 Minimum Attributes

required
Full details of the minimum data attributes required will be provided in each CV.027 mapping
document for each data object to be migrated.
8 DATA LOADING - APPROACH

This section provides a graphical description of the conversion approach which will be used to
convert the data from the existing data sources to the Oracle applications where a programmatic
approach is being taken as in Section 6.1.1 above.
For NON-programmatic conversions i.e. using WebADI spreadsheet templates, Bulk loads or
dataloader, OCS will provide a structured template for completion which we will then load and
revert back to you with any data issues.
NOTE: Non-programmatic data loads will NOT always follow the schematic below as entry may
be via forms or APIs and not open interface tables.
8.1.1 DATA MAPPING

The data mapping process provides detailed lists of the Source System data sets and data
elements that will need to be moved into the Oracle tables during the data conversion. During
this process, some decisions will need to be made with regard to obtaining required information
needed by the target application, which may not be present in the old system. Default settings,
user input, and new data entries are example issues that must be addressed during this phase.
The output of this section is data mapping spreadsheets that show what is needed for the Oracle
target application processing to meet business operational requirements and where these data
elements will come from.
8.1.2 DOWNLOAD PROGRAMS
These programs are used to extract the identified conversion data elements from the current
existing Source Systems. What tool is used to accomplish this task is usually dependent on the
abilities of the current system to develop an ASCII flat file. It is important to remember how the
flat file will be structured (the order of the records as they are pulled); type of delineation used,
number of records, etc. This must match how the interim tables are set up. The output from this
is the ASCII flat files identified in the next section. It is the responsibility of the ClinigenOne team
to develop these extracts
8.1.3 ASCII FLAT FILE
Most database or file systems output data in text form. A comma or space delimited, variable or
fixed format data file from the existing system should be generated. This will be explicitly specified
for each object/attribute.
For each data object, Oracle will provide Clinigen with the required data format needed in column
order presented as either .csv or .xls formats without any embedded control characters.
This is supplementary to the CV.027 mapping document.
8.1.4 UPLOAD PROGRAM
Once data has been put into the required file format and physically moved onto the same server
that has the Oracle RDBMS, the next step is to load the data into the relational database
environment.
Where required, OCS will develop programs to load data, validate data, and insert agreed
standard values into default fields (if not already provided). Usually a single loader program is
written for each data table being loaded.
8.1.5 DESCRIPTION OF INTERFACE STAGING TABLE
The detailed technical description of any interface table that the data is placed into from the ASCII
flat file is described. A temporary table, which mimics the production table that the data will
eventually be loaded into will be built. This allows the manipulation of the data as needed (by
means of applying any mapping or defaulting rules using PL*SQL if required) before loading the
legacy data into the production tables.
8.1.6 CREATION OF INTERFACE STAGING TABLE
Before loading the Oracle application production tables, the legacy data will first be loaded into
temporary or interface tables. The interface tables provide a location for the application of
PL*SQL procedural logic to manipulate and translate the data as needed before validating the
data and loading the application production tables. These temporary interface tables will be
created as part of the installation scripts for conversion objects.
8.1.7 TRANSLATION PROGRAMS
These scripts are developed to translate data from the existing system format into useful data for
the Oracle target application. An example of this might be taking the date format that exists in the
legacy system and converting it into an Oracle format. There may be several or no translation
programs, depending on both the type of data coming across and the format of that data.
Ideally, no translations will be needed.
8.1.8 INTERFACE PROGRAMS

The interface program scripts are used to populate the production database. The purpose of the
interface programs is not only to move the data to the target tables but also to validate the data,
which would be validated by the form in the target module if the data was converted manually.
8.1.9 APPLICATION PRODUCTION TABLE
This is the final production data table where the converted data resides. These tables are
identified early on when doing the initial data mapping. These tables drive some of the translation
programs that must ultimately ensure that 100% of the required information that the target
applications require is present in the final data structures.
8.1.10 TESTING
The testing process is integrated into the entire conversion process so that, even during the pre-
conversion steps, some type of validation reports are generated from the Source systems, to be
compared later with the converted data. This is required to ensure that ‘source to target’
validations can be performed and demonstrated as required to the business or other stakeholders
The approach normally taken is to use as many standard reports available in each legacy source
and target system for the final data validation. If no reports support the validation requirements,
then custom scripts will need to be created for specific validation purposes.
8.1.11 WRITE AND PERFORM CONVERSION EXECUTION PLAN
The conversion execution plan is the execution document to be followed when performing the
actual conversion. This document will be specifically tailored for the ClinigenOne conversion.
Essentially this will consist of a detailed plan showing all dependencies and activities required.
9 DATA CONVERSION – TESTING STRATEGY

The agreed upon conversion work products should be approved by the client representatives who
are responsible for the success of the conversion. In addition, three levels of conversion testing
have been identified and described in the Conversion Test Plans (CV.050).
 Data Migration Validation
 Data Migration Reconciliation
 Functional / Business testing
Test loads will be executed to ensure all modules work together successfully. During these test
loads, Gate Keeping (pre-defined check points) will take place to ensure the full integrity of the
data load is maintained.
Following the initial completion of technical development, Oracle will complete unit testing with
files containing subsets of data.
The test loads for full Data Conversion testing will then be executed to ensure all modules work
together successfully and formal full capacity loads of data will be scheduled into the plan to
refine the conversion to ensure maximum success.
Typically the following schedule of loads is planned.
Load Ref Volume Success Target Environment
Unit Test Sample Data 100% target Development or

successful copy of CRP3
Proof of Concept 20% of Static Data volume loaded 95% target successful System Test
(no transactional data)
Test load 1 100% of full data volume loaded 95% target successful CONV
(Static & Transactional)
Test load 2 100% of full data volume loaded 100% target SIT
(Static & Transactional) successful
Test load 3 (Dry run) 100% of full data volume loaded 100% target UAT
(Static & Transactional) successful &
Reconciled
Production load / 100% of full data volume (Static & 100% target PROD
loads Transactional) successful &
reconciled
Environments provided for the dry testing should be a realistic reflection of production in terms of
both configuration and infrastructure to ensure that no security or performance issues are
encountered in the final migration process.
Earlier cycles should always contain the latest available configuration.
9.1 Data Migration Validation

Data validations are critical to E-Business Suite migration from the various Clinigen source
systems due to the transformations performed during migration. Robust validations should be built
to ensure that:
a) Incoming data is clean and "garbage in and garbage out" situation is eliminated to a
greater extent i.e. approved by the data owner in advance of being loaded
b) Data integrity on the target is maintained after data is transformed
c) E-Business Suite business processes can run successfully on migrated data.
Validations can range from a simple row count check to a complex aggregation including multiple
joins between multiple tables.
Validations can be performed at various phases as mentioned below:

a) In-Migration: Validations that are performed during migration or while data is getting
transformed. This could be validations that occur in Custom Process while transforming
data from the source data to target data or validations that are coded in the import
processes.
Note: In-Migration process will have two stage validations,
i. Validate record counts in the staging table. At this stage the file load (Record Count
Match between file and the staging table) will happen. This will be first step for the
reconciliation which will happen before the loader process is executed
ii. Validate data in the staging table to ensure passed data can be loaded into E-
Business Suite
b) Post Migration: Validations to be performed once the data has been completely migrated
over to E-Business Suite target tables; this is done using Reconciliation process.
9.1.1 SOURCE DATA HEALTH CHECKS

These include any kind of operations performed on the data prior to migration to make sure that
the data chosen for migration is valid and current. Some examples:
a) Identifying Orphan rows
b) Missing rows due to data / broken referential integrity
c) Missing column data
d) Legacy end dated / inactivated data
9.1.2 PRE MIGRATION READINESS CHECKS

These validations are to ensure that all required data for migration like lookups and mapping data
are current and available. An example is:
a) Missing mapping information in value mapping tables
9.1.3 IN FLIGHT VALIDATIONS

There can be a lot of database checks that can be verified during migration itself. Some of the
Database constraints that can be checked are
a) Required column check
b) Primary key
c) Referential integrity / foreign key
The above validations are automatically performed as part of the use of Open Interface tables or
API’s and/or data loaded directly into the application using the standard user interface forms.
These checks would only normally be performed when initially loading data into staging tables to
minimize the number of potential data rejections.
9.2 Quantitative
Reconciliation
This section details how record counts of migrated data will be reconciled during each step of the
process.
 Data Extract
From the extract files (per business object) and check that the count matches the
source system or staging tables.
 Within the E-Business Suite Validation process
Using the extract data count from Clinigen (per business object), check that the number
of records imported into the E-Business Suite Staging tables match. This is first stage
of (mandatory step) reconciliation process where we will decide if we should run the
Load process (to load data from stage to E-Business Suite tables), if the count
matches.
For data loaded via spreadsheets this is a simple row count.
 Within the E-Business Suite Load process
Using the extract data count from Clinigen (per business object) check the number of
records imported into the E-Business Suite tables match. This is used to identify the
total number of records loaded into the actual application. Standard reports provide this
information.
9.3 Functional / Business testing

Following the initial completion of Data Migration Validation and Data Migration Reconciliation, we
need to further ensure that the migrated records are validated by the SME’s & Data owners within
the business.
 This activity needs to be done for all business objects which are loaded through the
various conversion methods.
 SME’s & Data owners will select any random data and check for consistency with non-
migrated data in the target Oracle E-Business system, starting from its creation to
usage in transactions depending on the object
 Issues should be recorded and further discussed with the Clinigen and Oracle
conversion team for data correction or reload.
10 OPEN AND CLOSED ISSUES
10.1 Open Issues
ID Issue Resp Target Date Impact Date
10.2 Closed Issues
ID Issue Resolution Resolved Date

1 Due to the nature of the contracts, SOME MA programs Moved to “Steering Committee Action List” by 06-Jun-17
may require historical shipments to patients – this Steph
could/may need historical data to be available in
eBusiness suite and/or the Service Cloud
2 HFM will already have all historical GL data loaded. Moved to “Steering Committee Action List” by 06-Jun-17
Extreme care must be taken with any transitional Steph
mapping changes within HFM. i.e. downstream impacts
and reconciliations of data may be needed
3 Projects/Agreements/Funding – concern expressed There will be a maximum of 150 Projects of which 05-May-17
about effort/duration to do this manually. 120 are MA programs requiring the full dataset.
These will need to be loaded into Production in
advance of the go-live to enable time for the
Service Cloud configuration to be built.
4 Will the business be able to use Project Accounting Moved to “Steering Committee Action List” by 06-Jun-17
and/or analytics in a meaningful way if project-to-date Steph
history is not available within the PA module?
5 How will any dependencies of Service Cloud Moved to “Steering Committee Action List” by 06-Jun-17
configuration on Static data be managed? Steph

CV020 Data Conversion Strategy Approach Issue 1.0

Uploaded by

Copyright:

Available Formats

You might also like

CV020 Data Conversion Strategy Approach Issue 1.0

Uploaded by

Document Information

Original Title

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

CV020 Data Conversion Strategy Approach Issue 1.0

Uploaded by

Copyright:

Available Formats

CV.

020 DATA CONVERSION STRATEGY

Authors: Adrian Edwards

Last Updated: 29 June 2017

1.1 Change Record

Date Author Version Change Reference

4 Data Acquisition and Conversion Overview...........................................................3

5 Data Acquisition - Strategy......................................................................................8

6 Data Conversion - SCOPE........................................................................................9

7 Data Conversion - Constraints and Assumptions................................................12

8 Data Loading - Approach........................................................................................13

9 Data Conversion – Testing Strategy......................................................................16

10 Open and Closed Issues.........................................................................................19

4 DATA ACQUISITION AND CONVERSION OVERVIEW

4.1 Project Management

4.2 Task and Work Products

Task Work Product

4.3 Team Organization

4.4 Resource Requirements

4.5 Data Cleanup Process

 Duplicate entities should be removed or merged as part of the Data Cleanup

4.5.2 KEY DATA TRANSLATIONS

4.6 Testing Strategy

4.7 Acceptance Criteria

5 DATA ACQUISITION - STRATEGY

5.1 Logical Architecture

5.1.1 DATA STORES

Seq. Data Store Object/Purpose Comment

6 DATA CONVERSION - SCOPE

6.1 Objects in Scope (to be

o Current recurring Pay Elements & Last Bonus

6.1.3 BULK DATA LOAD (INTO MDM) -

6.1.4 MANUAL ENTRY (BASED ON VOLUMES AND COMPLEXITY)

6.2 Objects out of Scope (not being

7 DATA CONVERSION - CONSTRAINTS AND ASSUMPTIONS

7.1 Cleanup Criteria

7.2 Minimum Attributes

8 DATA LOADING - APPROACH

8.1.1 DATA MAPPING

8.1.8 INTERFACE PROGRAMS

9 DATA CONVERSION – TESTING STRATEGY

Load Ref Volume Success Target Environment

Unit Test Sample Data 100% target Development or

9.1 Data Migration Validation

Validations can be performed at various phases as mentioned below:

9.1.1 SOURCE DATA HEALTH CHECKS

9.1.2 PRE MIGRATION READINESS CHECKS

9.1.3 IN FLIGHT VALIDATIONS

9.3 Functional / Business testing

10 OPEN AND CLOSED ISSUES

10.1 Open Issues

ID Issue Resp Target Date Impact Date

10.2 Closed Issues

ID Issue Resolution Resolved Date

You might also like