Checklist item Planned?

Phase 1: Planning
Define the objectives and scope of the data migration

Identify the source and target systems for the migration and draft an inventory of your data ecosyste
Determine
Analyze thethe data
data migration
to be timeline
migrated, and its
including deadlines
size,
complexity, and quality
Identify any data dependencies or relationships that need to
be maintained
Determine the migration approach (e.g., big bang(when the
entirety of your day is migrated all in a single operation.),
phased, or parallel)
Identify the data migration, including personnel, hardware,
and software
Develop a risk management plan for the data migration,
including contingency
Determine plans for
the data mapping andunexpected issues
transformation
requirements
Develop a testing plan to ensure the accuracy and
completeness of the
Identify any legal migrated data
or regulatory requirements that must be
considered during the migration
Create a communication plan to keep stakeholders informed
throughout the
Determine the data
data retention
migrationrequirements
process after the
migration
Develop a is complete
plan for training users on the new system and
processes
Identify the key performance indicators (KPIs) that will be
used to measure the success of the data migration
Identify the chain of custody requirements for the data
migration project, including any legal or regulatory
requirements that must be met
Phase 2: Analysis
Develop a plan for data analysis and reporting, both during
and after the data migration process
Define the data analysis tools and techniques to be used,
including data profiling, data quality analysis, and data
lineage
Create aanalysis
data validation plan to ensure the accuracy and
completeness of the migrated data
Developany
Identify a plan forgaps
data dataorreconciliation andand
inconsistencies error resolution
develop a plan
to address them
Determine the data governance requirements for the
migrated data, including data ownership, data privacy, and
data security
Develop a plan for data integration and consolidation, if
necessary
Identify any
Develop data
a plan forcleansing or dataorenrichment
data archiving requirements
data deletion, if
necessary
Determine the reporting requirements for the migrated data
and develop a plan for creating reports
Identify any data visualization requirements and develop a
plan for creating visualizations
Create a plan for data governance and maintenance,
includingadata
Develop planquality monitoring
for data and dataand
analytics training stewardship
support for end-
users
Test and validate all analytics components and processes
Phasea3:
Select Pilot migration
representative subset of data to migrate during the
pilot phase
Develop a pilot migration plan, including timelines and
milestones
Establish a test environment for the pilot migration
Test the migration tools and processes on the pilot data set
Verifythe
Test themigrated
migrateddata
datafor
inaccuracy,
the targetcompleteness,
system and
consistency
Validateany
Identify the issues
data governance andpilot
or gaps in the maintenance
migrationprocesses
and develop
a plan to address them
Monitor the performance of the migrated data in the target
system
Collect feedback from end-users on the migrated data and
processes
Assess the success of the pilot migration against the defined
KPIs
Analyze the results of the pilot migration to identify any areas
for improvement
Refine the migration processes and tools based on the results
of the pilot
Create migration
a plan to address any issues or gaps identified during
the pilot migration
Prepare for the full-scale migration based on the lessons
learned during the pilot migration
Phase 4: Full migration
Follow full
Identify themigration plan,toincluding
defined data timelines
be migrated and milestones
and verify that it is
complete and accurate
Verify the readiness of the target system for the migration
Confirm the migration approach defined in the migration plan
(e.g., big bang, parallel, or phased)
Verify the defined data mapping plan to ensure the data is
mapped correctly to the target system
Verify the defined data transformation plan and steps to
ensurethe
Verify thedefined
data is validation
transformed correctly
plan for the
to ensure the migrated
target system
data
is complete
Verify and accurate
the defined data reconciliation plan to ensure any data
inconsistencies are resolved
Verify the migrated data in the target system
Test and validate the migrated data for accuracy,
completeness, and consistency per the data validation
requirements
Follow any
Monitor thedata governance
performance andmigrated
of the maintenance processes
data in the target
system
Collect feedback from end-users on the migrated data and
processes
Assess the
Analyze thesuccess
results of
of the
the migration
migration against theany
to identify defined
areasKPIs
of
improvement
Refine the migration processes and tools based on the results
of the migration
Create a plan to address any issues or gaps identified during
the migration
Implement chain of custody procedures for the full migration
process
Prepare for post-migration activities, such as data governance
and maintenance, data quality monitoring, and user training
and support
Phasethat
Verify 5: Post-migration
all data has been successfully migrated to the
target system
Validate that the migrated data is complete, accurate, and
consistent
Conduct data quality monitoring to ensure the migrated data
continuesthat
Validate to meet the governance
the data required quality
and standards
maintenance
processes
Monitor theare working as of
performance expected
the migrated data in the target
system
Collect feedback from end-users on the migrated data and
processes
Analyze the feedback received and identify areas for
improvement
Conduct user training and support sessions to help end-users
become proficient in using the new system and processes
Provide ongoing support to end-users to help them
troubleshoot any issues they encounter
Conduct periodic data reviews to ensure that the migrated
data continues to meet the required quality standards
Conduct periodic data audits to ensure that the migrated data
is being used
Establish and maintained
a process correctly
for handling any data-related issues that
may arise
Continuously monitor and improve the data governance and
maintenance processes
Update the data governance policies and procedures to
reflect any changes resulting from the migration
Conduct a post-migration review to assess the success of the
migration
Verify the against the of
completion defined
chain KPIs
of custody for the migrated
data
Owner Completed? Risks
Notes
Component

Banks,bank branches and Accounts

Internal

External Bank and Bank Branches

Location

Grade

Shared HR – Work Structure

Job& Job Family

Department

Position
Shared HR – Employee

Customer
Header

Customer
Accounts

Customer Sites

Customer
Customers Referance
Accounts

Customer
Contacts &
Relationships

Customer
Profiles

Customer Bank
Accounts

Suppliers

Supplier
Addresses

Suppliers
 Supplier Sites
Supplier Site
Suppliers Assignments
Supplier Site
Contacts

Supplier
Products and
Services
Categories

Supplier Tax
profiles

Supplier Bank Account Supllier Bank

Information
Supplier Invoices Payable Invoices

GL Balances –
Opening
General Ledger Balances
GL History -
Period Balance
six (2) Years

COA
 • Mass
Additions
Fixed Assets • Mass
Addition
Distributions
 • Invoice Lines
Customer Invoices • Invoice
Distributions

Customer Receipts

• Header
• Requisition
Purchase Requisitions - Open Line
• Requisition
Distribution
Purchase Orders - Open

• Purchase
Order Header
• Purchase
Order Lines
• Purchase
Order Schedules
• Purchase
Order
Distributions
Purchase Receipts – Open TBD

Buyer's List
user Information and User roles

Project

Contracts - Subscription
Contracts and Project - PPM
Items
 SOW Scope
Source

Only active Internal Bank Accounts will be

created during configuration

MSD
Only active External Bank and Branches will be
created in Oracle
MSD

Active Work Structure components will be

MSD
loaded into the Oracle Cloud
Active employees will be loaded into the Oracle
Cloud system

Active customers will be loaded into the

MSD
Oracle Cloud system

Active suppliers will be loaded into the

Oracle Cloud
 Active suppliers will be loaded into the
Oracle Cloud

MSD

NA

Yet To Finalize

All Active Bank Info Will Be Loaded

Open invoices will be loaded into the Oracle
Cloud

General ledger MSD

Fixed Assets MSD
 EBS 12.1
· Transactions having negative balance of minimal amount needs to
be closed in MSD and not migrated to Oracle Fusion Cloud.

Purchasing
Coupa
Contracts - Subscription
Contracts and Project - PPM
Items
Tool

Rapid Implementation

DMF / Rapid
Implementation

DMF / HDL
DMF / HDL

FBDI
DMF / FBDI
DMF / FBDI

DMF / FBDI

FBDI
 DMF / FBDI

DMF / FBDI
DMF / FBDI
Data Migration Approach
• Any Internal bank accounts will be created as part of
Eand
configuration activity. Eand will be
• Bank information requires the country, name, and number. providing the
• Branch information requires name, number, BIC code, and necessary extract
alternate name. information to
• Account information requires name, number, currency, legal Infolob for the
entity, type, and IBAN. purpose of data
• Existing bank accounts cannot be modified through Rapid Eand will be This
verification.
Implementation. step is crucial
providing the to
• Payment Documents and Formats will have to be manually ensure that
necessary extract all
configured in Cloud. data is accurate
information to
• Additional configuration such as Bank Statement before
Infolob for thewe
Reconciliation, DFF’s, Security and Business Unit will have to be proceedof
purpose with
datathe
manually configured. loading process.
verification. This
• Internal bank accounts will be extracted as part of step is crucial to
configuration workbook and setup while environment build. ensure that all
data is accurate
• All active work structure components will be migrated as of before we
cut over date. proceed with the
• The order of loading of 6 basic work structures should be: loading process.
a) Location
Eand will be
b) Grade
providing the
c) Job Family
necessary extract
d) Job
information to
e) Departments with classifications
Infolob for the
f) Positions
purpose of data
• Other work structure components (like Department Tree,
verification. This
Position Hierarchy etc) should be loaded only after the above
step is crucial to
work structure components are loaded successfully.
ensure that all
• Most of the work structure objects are date tracked, so the
data is accurate
way EffectiveStartDate and EffectiveEndDate attributes are
before we
defined in SQLs should not be changed without proper
proceed with the
understanding.
loading process.
• Some of the inactive work structures may be assigned to
employee assignments in Oracle EBS as there is no check.
However, in fusion inactive work structures can't be assigned to
active assignments. This will create a conflict while loading
worker data in Fusion and some of the worker records may fail.
• If the project team encounters issue due to inactive work
structure, the corresponding work structures should be loaded
as Active first (or made Active from UI) and post worker
assignment load, the relevant work structures should be made
inactive.
• It is advised to load only the below mandatory worker
business objects in first round of each iteration:
o Worker
o Person Name
o Person Legislative Data
o Work Relationship
o Work Terms
o Assignment
• The other objects (like email, address, phone, supervisor etc)
should be loaded in second round once the mandatory worker
data is loaded successfully.
• Most of the worker objects are date tracked, so the way
EffectiveStartDate
• and EffectiveEndDate
All active customer accounts andattributes are defined
sites are
in SQLs should not be changed
considered as of cut over date. without proper understanding.
Any modification in standard worker queries will need rigorous
• New customers created in source system after
extract for production migration will be created
manually in Fusion.
• Customer bank accounts and receipt method would
be migrated only for Direct Debit customers.
• Customer contact details would be migrated.
• Customer Sharing - Multiple customer accounts to
be created for same party if customer is shared
between sub-processes. This step is crucial to
ensure that all data is
• It is recommended to migrate Customers prior to accurate before we proceed
with the loading process.
loading any other TCA entities like Suppliers,
Employees, etc. because Customer FBDI provides a
place holder for migrating Party Number
(REGISTRY_ID) to Fusion while for other TCA entities, it
is generated as a sequence value by Fusion. This will
make sure that the party numbers used by Customer
extract are not utilized while creating other TCA
entities.
• All data transformation and mapping will be
completed before it is loaded into the template (e.g.,
Customer Account type, Customer Site Purpose such
• Both PROSPECTIVE
as Bill-to, Ship-to). and SPEND AUTHORIZED suppliers will be Oracle will be
migrated. providing the
• If Paysafe uses supplier qualification process, then they necessary extract
should review and try to close any unapproved suppliers before information to
migration. If any PROSPECTIVE supplier at source is under
approval process during data migration cut over, then it will be
migrated as a PROSPECTIVE supplier only. Any incomplete
approval process to be re-initiated by Paysafe manually in
target system after data migration is over.
• All active Suppliers and Supplier Sites for the OU name from
the Source System to be considered.
• Employees will not be migrated as Suppliers.
• New suppliers created in Source System after extract for
production migration will be created manually in Oracle Fusion
should review and try to close any unapproved suppliers before
migration. If any PROSPECTIVE supplier at source is under
approval process during data migration cut over, then it will be
migrated as a PROSPECTIVE supplier only. Any incomplete
approval process to be re-initiated by Paysafe manually in
target system after data migration is over.
• All active Suppliers and Supplier Sites for the OU name from
the Source System to be considered.
• Employees will not be migrated as Suppliers.
• New suppliers created in Source System after extract for
production migration will be created manually in Oracle Fusion
cloud.
• Supplier addresses to have one to one mapping with site to
facilitate storage of tax code. Supplier addresses shall be same
as the site name to create unique address in Fusion.

All Active supplier tax profiles will be migrated

• All active Supplier Bank Accounts will be loaded as of Cut of

date.
• Employee bank accounts will not be loaded. Use HCM to load
them
migration (Partially Paid Invoices)
• For the Supplier that are currently inactive for Procurement
purposes and still has open invoices, these must be made active
for migration and after migration, they need to make inactive.
• Accounting Date should be same on all invoices for
reconciliation purposes.
• Migrated invoices will create accounting in GL. Since we are
also migrating GL balances, we will need to reverse the
accounting from AP migration.
• Payment Term in Cloud derives the due date.
• Currency (transaction currency) of an invoice may be
different from functional currency.
• Conversion rate required for foreign currency invoice.
Therefore, conversion rate of the original invoice from legacy
system to be retained.
• Open Asset Invoices that have been processed completely
will be paid and transferred to Assets before migration.
• If, for any reason, any asset invoices that are completely
processed and transferred to Assets module cannot be paid, the
‘track as asset’ flag needs to be turned off after the invoices are
migrated in AP.
• Open Project-related invoices (POET-CF) that have been
processed and interfaced into projects will need to be paid off in
EBS before migration.
• If for any reason any open Project-related invoices (POET-CF)
are not paid in EBS, they will be migrated with the POET-CF
information on a DFF. Drill down for these invoices will not be
available in PPM.
• Fully paid invoices, cancelled invoices, reference data (e.g.,
PO, PA, FA) will not be migrated.
• Journal Detail extract only from (period name) period in
current fiscal year.
• All detailed journal information for the period will be
extracted up until Go-Live.
• The balances should be reconciled and signed-off by Eand
pre and post data load activity.

Received Latest V1.11

MSD
• All in Service Assets i.e., Assets that are not retired or
disposed in EBS application at the time of migration will be
migrated.
• All transactions may be performed in MSD till the cut-over
date in the period prior to go-live period in Cloud.
• Irrespective of the actual go-live date (staring of the
month/mid of the month/end of the month), all go-live period
asset activity such as
Additions/Adjustments/Transfers/Retirements should not be
performed in source system.
• All go-live period asset transactions should be performed in
cloud post go-live.
• After all active assets migration is completed, depreciation
will be run in cloud and MSD simultaneously. The results will be
reconciled.
• All Assets must be accounted in legacy system before start
of migration.
• The account code combination in the Assets being converted
should be as per the COA defined in ERP Cloud.
• Asset Numbering – bring as per MSD convention.
during receipt application in search criteria. Also, it will be easy
to pull up all BFB (Balance Forward Billing) related partial paid
invoices.
• Fully applied invoices or cancelled invoices will not be
migrated.
• Migration specific account combinations will be deactivated
post data migration and reconciliation.
• Tax rules will be configured for migration purpose to avoid
recalculation by fusion application. These rules will be disabled
after the data migration activity is completed.
• If the accounting needs to be changed users should follow
the change accounting process on migrated transactions.
• Outstanding transactions that are not fully received at the
time of cutover.
e.g., AR Invoice of $10,000 with remaining balance of $2,000 is
migrated as a new invoice for $2,000 only.
• While migrating Partially Paid Transactions from MSD,
calculation formula will be Transaction Line Quantity kept as 1
multiplied by Unit Selling Price as the Outstanding Balance
Amount from MSD.
• All transactions must be accounted in legacy system before
start of migration.
• Tax Lines, if any, will be brought in as is from MSD.
• Freight amounts will be extracted to the extent of open
freight amount in the transaction.
• Transaction Number will be extracted as is from MSD to
Cloud
• The account code combination in the Transactions being
migrated should be as per the COA defined in ERP Cloud.
• Accounting Date should be the last day of the month of go-
live.
• Identify any impact on AR Transactions migration due to new
business units, which may require change in the mapping.

• Approved purchase requisition which are not yet converted

to purchase order will be migrated.
• Purchase requisition converted to a Purchase Order would
not be considered for migration, instead the purchase orders will
be migrated as part of open purchase order transaction.
• Charge account will be derived based on accounting rule
defined in Fusion application – This is subjected to Chart of
Account design decision.
• Fusion application will retain the same Legacy Requisition
number.
• Business Unit Mapping/Transformation will be done as per
the final design of Enterprise Architecture.
• There will not be any link or reference to Projects while
migrating Requisition data as projects solution doesn’t exist at
source system.
• All Open Standard Purchase Orders (PO) will be considered
for migration.
• Fully open Purchase Order with no receipts performed in
Oracle MSD will be migrated. In-case of partially
received/invoiced purchase order in Oracle MSD application, the
balance open purchase order quantity will be migrated to Oracle
Fusion Cloud.
• PO Approval: Approvals will be bypassed during migration.
• PO Numbering: Retain source system PO numbers.
• PO Creation date will be migration system date.
• PO History: Change order, Approvals and PO life cycle history
would not be part of the migration.
• PO Status: Draft, Incomplete, Closed, Cancelled, Withdrawn,
finally closed PO Headers, PO Lines/Shipments and/or similar
statuses in source systems would NOT be part of the migration.
• Profile “PO_Control_Supplier_Communication” to be disabled
during migration.
• Communication method and email address will be set as
NONE for initial load.
• Purchase Orders created from backing requisitions in Source
System will not carry any requisition references in Cloud.
• Charge account will be derived based on accounting rule
defined in Fusion application – This is subjected to Chart of
Account design decision or Charge account will be kept same as
MSD application.
 Data volume (number of
Data source description
records)

All Internal Bank Accounts will be migrated 4

 5000

All Active(having any transaction recorded

in last 5 years
such as all Open PO
All active and Inactive suppliers

All Active Suppliers

5,000
All Active Suppliers
5,000

All Active Suppliers

Supplier Contacts are required for
Procurement solution and the contacts are
currently managed

All Active Suppliers

All Active Suppliers

All Active Supplier Bank Info

to be captured in Oracle Fusion. We need
this as Opening Balances for 2023.
2. 2023 & 2024 – All months GL Balances
to be captured in Oracle Fusion. We need
this for prior year lookback and
comparisons from within Oracle Fusion.

Load Latest Version

All Open Invoices will be migrated
migrated
which are yet to apply and unidentified ,on
account

Approved and Accounted PO,

associated open lines will be migrated.
• For Partially received/invoiced
shipment, only the amount which is yet to
be received/billed would be considered for
migration.
In case of 2 Way match,
Remaining Amount = Ordered amount –
Billed amount
Whereas in case of 3 Way match,
Remaining Qty = Ordered qty – received
qty,
if there are multiple schedules for single
line, sum of the scheduled qty at line level
is considered & if there are multiple
distribution against single schedule, sum of
distributions qty at schedule level is
considered.

Below scenarios are considered as a

reference to understand extraction logic
• Need by date would be system date if
it’s a past date in source system.
• Purchase Orders with backing
requisitions in Source System will not carry
any Requisition References in Cloud.
• All PO s will be entered with the
respective distribution accounts as per
Chart of Accounts structure defined in
Cloud.
All Po Receipts for all Open Transactions
• It is recommended that Open receipt
are addressed in source system to the
extent possible.
• Receipt migration is applicable only
where match option is 3-way match.
• Appropriate open PO quantity to be
addressed in respective PO migration.
• Receipt migration will be with
migration/system date.
• On migration the receipts, inventory
flushing, accrual reversal, PPV and ERV to
be addressed manually
• Un-invoiced Receipts will be migrated.
• Examples of un-invoiced receipts:
o PO 100, Receipts 80 and Invoiced 60
the Receipts will be created only for 20.
o PO 100, Receipts 100 and Invoiced 0
then full receipts 100 should be migrated.
All
All Active
Active Buyers
EmployeeListRecords User
Information & user Roles
Bank , Bank Branch, person Payment
method, External Bank Account, Payroll
Relationships
Contracts - Subscription
Contracts and Project - PPM
Items
 Mapping Data
Data size Migration
requiremen cleansing
(GB/TB) priority
ts requirements

Based on country
validations, Bank
-Duplicates
Code/Number
-Country specific &
defaulting rules
Validation issues.
needs to be
agreed.

High
 Notes

1. 2 Banks and Bank Branches is loaded

2. 2 USD and 2AED accounts is loaded
 Comments From E and Status Action Owner

Loaded Loaded

Preparing the Data (Stopped due

to not yet decided the cutoff go Not Yet
live date) Started Waiting for the Data

Confirmed Completed Loaded

Extraction Sent Completed loaded

Completed loaded
Extraction Yet to Send

Completed loaded
Extraction Yet to Send

Completed loaded
Extraction Yet to Send

No Referance accounts are

maintained at customer level-
Descoped NA NA

Completed loaded
Extraction Yet to Send

Not Loaded , Need to finalize the Not Yet

Customer Profiles Started Waiting for the Data

No bank Accounts NA NA

Completed Loaded

Extraction sent Completed Loaded

 Extraction sent

Completed Loaded

Completed Loaded

Extraction Sent
Completed Loaded

Not Yet Loaded , Due to duplicate

registrations Not Yet
Started Waiting for the Data

E and Provide the details

Not Yet
Started Waiting for the Data
 Not Yet
Cut off date is Postponing and waiting for the
Started Waiting for the Data

Not Yet
Not Yet Started Data Received upto Aug-24
Started

Not Yet
Not Yet Started Data Received upto Aug-24
Started

Verified and Confirmed Completed Loaded

Reconcilation file sent and confirmed the
Completed Loaded
asset balances upto Aug-24
 Not Yet
Not Yet Started Waiting for the Data
Started

Not yet started Not yet started Not yet started

Not yet started Not yet starNot yet started
S.No Objects
Finance
Master Data
1 AP - Master Data(Supplier)
2 AR - Master Data(Customer)
3 COA V1
4 Internal Bank Account
5 Supplier Bank Account
Transactional Data
1 AP - transactional Data
2 AR - transactional Data
3 Trial balance
3 Fixed Asset Data
 Date Cleanising ,
configuration,Mapping and Loading(D Reconcilati
validation,approval for signoff ays) on(Days)

1 1 1
1 1 1
1 1 1
1 1 1
1 1 2

1 Day( Depends master day and configuration) 1 2

2 days( Depends master day and configuration) 2 2
2 days( Depends master day and configuration) 3 2
1 Day( Depends master day and configuration) 1 2
COA Values Enterprise Structure Report - Attached
Item details by LOB (with Accounts) No Data found
Asset Categories Attached
Asset Locations Attached
Asset Keys LOB's
Assets Attached
Internal Bank Accounts Attached
Suppliers attached
Supplier Sites attached
Supplier Bank Accounts NO Banks account is loaded
Customers attached
Customer Sites attached
GL Balances until Jul 2024 --- Send to Qazi if we can upload to attached & Sent mail to Qazi
e Structure Report - Attached

s account is loaded

& Sent mail to Qazi