Home / Case Studies / SAP ECC to Oracle Fusion Cloud

CASE STUDY · ERP DATA MIGRATION · ENTERPRISE · LONDON, UK

Enterprise SAP ECC to Oracle Fusion Cloud Migration

A large enterprise organisation headquartered in London used Syntra ETL to support its transformation from SAP ECC to Oracle Fusion Cloud, moving critical business and historical data out of the legacy SAP environment and into Oracle. Syntra ETL provided the end-to-end migration framework: SAP extraction, mapping and transformation to Oracle Fusion structures, automated validation, Oracle-compatible load-file generation, exception management and reconciliation across multiple migration cycles.

Planning an SAP to Oracle migration? →← All Case Studies

SAP ECC

Legacy source platform

Oracle Fusion

Target cloud platform

Multi-cycle

Rehearsals before cutover

London, UK

Enterprise programme

The challenge: SAP structures do not map cleanly onto Oracle Fusion

SAP ECC is a deep, highly configured environment. Years of operation leave complex data structures, dense code schemes and business relationships that are only meaningful inside SAP's own model. Oracle Fusion Cloud expects something else entirely.

The central difficulty of this programme was translating those SAP structures, codes and business relationships into the corresponding Oracle Fusion objects while maintaining data integrity — and doing it without losing the thread back to the source record. In a transformation programme, the ability to answer "where did this Oracle value come from?" is not a nicety; it is what makes the migration approvable.

Historical data raised the stakes. Moving current balances is one problem; carrying the historical record that finance, audit and the business still rely on is another, and it has to survive the same translation intact.

Challenges we solved

Moving an enterprise off SAP ECC is a translation problem before it is a loading problem.

🧩

Complex SAP data structures

SAP ECC structures had to be interpreted and mapped onto the corresponding Oracle Fusion objects, rather than exported and reshaped by hand for each run.

🏷

Dense legacy code schemes

SAP codes were crosswalked to Oracle Fusion values as part of an explicit transformation layer, so the conversion was repeatable across every migration cycle.

🔗

Business relationships across objects

Relationships between SAP records had to be preserved through transformation so the data arrived in Oracle Fusion connected and usable, not flattened.

📜

Historical data, not just balances

Critical historical data was migrated alongside current business data, carrying the record the business still depends on into the new platform.

✅

Validation before the load

Automated pre-load validation raised data-quality and structural issues as exceptions before Oracle Fusion rejected them, keeping load cycles productive.

🔍

Traceability through every cycle

Source-to-target traceability was maintained across multiple migration cycles, so each run could be reconciled and compared against the last.

The end-to-end migration framework

The same pipeline run across multiple migration cycles, with reconciliation and traceability at each pass.

SAP ECC→Extract→Map→Transform→Validate→Generate Oracle load files→Load→Exception management→Reconcile

What the framework covered

Syntra ETL provided the migration framework end to end rather than a point tool for one stage of it.

SAP extraction

Extract business and historical data from SAP ECC
Repeatable across migration cycles
Preserve relationships between records

Mapping & transformation

Map SAP structures to Oracle Fusion objects
Automated transformation of complex enterprise data
Crosswalk SAP codes to Oracle Fusion values

Validation

Automated pre-load validation
Data-quality checks on prepared data
Issues raised as exceptions before loading

Load generation

Oracle-compatible load files
Load-ready output for Oracle Fusion Cloud

Exception management

Controlled exception handling
Exception reporting per cycle
Resolution carried into the next cycle

Reconciliation

Comprehensive source-to-target reconciliation
Traceability maintained through multiple cycles
Evidence for programme sign-off

Getting data out of SAP ECC

SAP ECC is a normalised, client-partitioned, heavily code-driven database. Extraction is less about reading tables than about reconstructing meaning that SAP keeps spread across them.

MANDT — the client keyAlmost every application table in ECC is client-dependent, with the client as the leading key field. An extract that ignores it silently mixes production data with test and training clients — the kind of error that reconciles perfectly against itself and is still wrong.

BKPF / BSEG — accounting header and lineFinancial documents are split across a header and its line items. Reconstructing a complete posting means joining them and preserving the document key, and BSEG is a cluster-style structure rather than a simple transparent table, which constrains how it can be read.

KNA1 / LFA1 / MARA — master dataCustomer, vendor and material master general data. Each is the general-view head of a wider family of company-code and organisational-level tables, so a usable master record is always an assembly rather than a single row.

Check tables and domain valuesSAP validates codes against check tables and domain fixed values rather than storing labels. Extracts that take the code and leave the check table behind produce data nobody can interpret later — so reference and text tables are extracted alongside the transactions.

Internal vs external number rangesSAP assigns many keys internally from number ranges. Those keys are meaningful only inside SAP, so the migration has to decide, per object, whether the legacy key is carried into Oracle as a cross-reference or dropped in favour of a target-generated key.

BUKRS / KOSTL / HKONT — organisational keysCompany code, cost centre and G/L account. These carry the organisational meaning of every posting and are the values that have to line up with the Oracle Fusion enterprise structure before any transactional data can land.

How Oracle Fusion Cloud accepts data

Oracle Fusion does not accept direct database writes. Data enters through defined load utilities that stage into interface tables and then import into the base tables, and each stage can reject rows independently.

1Choose the load mechanism per objectFBDI (File-Based Data Import) for Financials, Procurement and SCM objects; HDL (HCM Data Loader) for HCM; ADFdi spreadsheets for smaller or corrective loads; REST and SOAP services for integration rather than bulk migration. The mechanism dictates the file format, so it is chosen before transformation is built, not after.
2Build to the Oracle template, exactlyFBDI templates are column-position-sensitive CSV. A shifted column or an unexpected delimiter does not raise a helpful error — it loads the wrong value into a valid field, which is why generated output is validated against the template rather than eyeballed.
3Stage the enterprise structure firstChart of accounts, ledgers, legal entities, business units, cost centres and the value sets behind them. Transactional data referencing a structure that does not yet exist fails at import, so structure precedes transactions in every cycle.
4Load master dataSuppliers, customers, items and the wider master families. These become the reference points that transactional records resolve against, and they carry the cross-reference back to the SAP key where one is retained.
5Upload and invoke the importCSV files are zipped and uploaded to UCM, then the Load Interface File for Import job moves them into the interface tables and the object-specific import process promotes them into the base tables.
6Work the interface-table rejectionsRows can pass the file load and still fail the import. Errors surface per object with reason codes; these are categorised, corrected at source or in the transformation rules, and reprocessed — which is the loop the rehearsal cycles exist to shorten.
7Load transactional and historical dataBalances, open items and the historical record, in the order the target's own validations require.
8Reconcile before sign-offCounts and totals compared across the SAP source, the prepared data and what Oracle actually accepted — the three points that have to agree before a cycle is signed off.

The three-point comparison matters more than it sounds. Source-to-file reconciliation proves the transformation was right; file-to-target reconciliation proves Oracle accepted it. A migration that only checks the first will report success while rows sit rejected in an interface table.

Which Syntra products did the work

One platform, three products, each doing a distinct job on the same programme.

DataMove

SAP ECC extraction, mapping, transformation, validation and Oracle Fusion load-file generation.

DataVault

Source-to-target reconciliation, migration lineage and the audit evidence behind each cycle.

DataLens

Migration visibility across cycles — records processed, validation exceptions and reconciliation status.

Key outcomes

What the programme delivered.

✓Successful migration from SAP ECC to Oracle Fusion Cloud.

✓Automated transformation of complex enterprise data structures.

✓Reduced manual migration effort across multiple cycles.

✓Improved data quality through pre-load validation.

✓Controlled exception management rather than informal correction.

✓Comprehensive source-to-target reconciliation supporting sign-off.

✓Data integrity and traceability maintained throughout the transformation.

SAP ECC connectorExtracting data from SAP ECC SAP data solutionsMigration and integration Oracle Fusion migrationERP, HCM, SCM and financials ERP data migrationAcross enterprise platforms Legacy system archivalHistory that need not migrate Migration reconciliationSource-to-target evidence

Frequently asked questions

Can Syntra ETL migrate SAP ECC data to Oracle Fusion Cloud?

Yes. This programme covered the full path: SAP ECC extraction, mapping and transformation to Oracle Fusion structures, automated validation, Oracle-compatible load-file generation, exception management and source-to-target reconciliation.

What is the hardest part of an SAP to Oracle Fusion migration?

Translating complex SAP data structures, codes and business relationships into the corresponding Oracle Fusion objects while maintaining data integrity and keeping traceability back to the source record.

Can historical SAP data be migrated as well as current data?

Yes. This programme moved critical business and historical data from the legacy SAP environment into Oracle. Where history does not need to live in the new ERP, it can instead be archived and kept searchable — see legacy system archival.

How many migration cycles does an SAP to Oracle move need?

This programme ran multiple cycles. Rehearsing the migration at full scale before cutover is what turns mapping and data-quality problems into corrections rather than go-live incidents.

How is an SAP to Oracle Fusion migration reconciled?

Through comprehensive source-to-target reconciliation with traceability maintained across cycles, so each run can be compared and the final migration approved on evidence.

How is data loaded into Oracle Fusion Cloud from SAP?

Through Oracle's own load utilities rather than direct database writes: FBDI for Financials, Procurement and SCM, HDL for HCM, ADFdi for smaller corrective loads, and REST or SOAP for ongoing integration. Prepared data is generated to the Oracle template, zipped, uploaded to UCM, moved into interface tables by the Load Interface File for Import job, then promoted into base tables by the object's import process.

Why is the SAP client field important during extraction?

Most ECC application tables are client-dependent, with the client (MANDT) as the leading key. An extract that does not constrain it can pull production, test and training data together into one set that reconciles against itself and is still wrong.

What happens to SAP document numbers in Oracle Fusion?

It is decided per object. Where the legacy key has ongoing business or audit value it is carried into Oracle as a cross-reference so the record can be traced back to SAP; otherwise the target generates its own key and the mapping is retained in the migration lineage.

Why do rows fail after a successful file load into Oracle Fusion?

Because the file load and the import are separate stages. A row can be structurally valid and still be rejected by the import process for a referential or business-rule reason. Both stages have to be reconciled, which is why the comparison runs across source, prepared data and loaded data rather than source and file alone.