OracleFree worksheetPDF, Excel, Word exportOracle Fusion Cloud SCM

Oracle Fusion Data Migration Mapping Worksheet

Data migration is where Oracle Fusion SCM projects slip. This worksheet keeps the field level mapping, transform rule and cleansing status in one table that you can export and hand to the loading team.

Free, optional. Reopen it on any device.

Download:

Source table	Source field	Fusion object	Fusion attribute	Transform	Source records	Known bad data (%)	Records after cleansing	Status
							46,754
							47,477
							1,978
							59,780
							8,930

Total source records

168,950

Total after cleansing

164,919

Fields mapped

Share of records surviving cleansing

97.6%

Use the Fusion object and attribute names from the FBDI templates or the REST resource you intend to load through. Check names against your release.

Want the first mapping drafted from your schema?

Optional expert review of your legacy tables against Oracle Fusion load objects.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to fill it in

Start from the source side. List each legacy table and field that matters, then name the Fusion object and attribute that receives it. Choose a transform rule so developers know whether a field moves as is, needs a cross reference table, or is derived. Enter source record counts and the percentage of known bad data from profiling. The sheet then shows the records expected to pass cleansing.

Using the transform column

Lookup rows deserve extra attention because each needs a published cross reference, such as legacy unit of measure to Fusion unit of measure or legacy category to catalog category. Derived rows need written logic. Drop rows should be agreed with the business, since a dropped field is often someone's report column. Keep a count of each type and review them in the mapping sign off.

One row per source field
Cross reference tables are deliverables
Derived logic is written, not verbal
Drops need business sign off

Reading the survival rate

The summary divides cleansed records by source records. It is only as good as your profiling. If a high volume object such as on-hand balances or item attributes shows a poor survival rate, plan extra cleansing cycles before the mock loads. Compare it with load results from each mock cycle, because the real error rate often differs from the profiled rate.

Common mistakes

Mapping to display names rather than the load column, ignoring required attributes that have no legacy source, and forgetting dependency order. Items must exist before structures, and organizations and locations before on-hand quantities. Add a sequence note in the transform column when order matters.

Frequently Asked Questions

Which load method should I map to?

Most bulk SCM loads use File Based Data Import templates, while smaller or ongoing updates often use REST services. Map to whichever you will run in production. Attribute names can differ between methods, so state the method in the Fusion object column.

How many mock loads do projects usually run?

Typically two to four full mock loads before cutover, with each cycle shrinking the error count. The right number depends on volume and cleansing quality, and the plan should hold time for a final dress rehearsal.

What error percentage is acceptable?

There is no universal threshold. Master data such as items and suppliers should be near clean, while historical transactions may be partly archived instead of migrated. Set targets per object and record them in the sign off.

Should inactive records be migrated?

Usually only if they are referenced by open transactions or needed for history. Migrating dead items inflates load times and clutters search. Agree an activity cut off date with the business.

If the source is Infor SyteLine, Baan or another legacy ERP, we can profile the tables and draft the first mapping from the schema.

Talk to an Expert Explore More Free Tools