The characteristics that shape every migration off this platform.
Interface and base tablesEBS keeps a well-documented schema per module — AP, AR, GL, PO, INV, HR — with base tables and their own open-interface tables. Extraction reads the base tables directly rather than replaying the interfaces, because the interfaces are built for loading in, not reading out.
Multi-Org and operating unitsEBS partitions transactional data by operating unit. An extract that ignores the org context either misses rows or blends organisations that must stay separate in the target.
FlexfieldsKey and descriptive flexfields hold organisation-specific meaning in generically-named columns. ATTRIBUTE1 means nothing until someone tells you what it was configured to hold, so flexfield definitions are extracted as reference data alongside the values.
Value sets and lookupsCodes validate against value sets and lookup types rather than storing labels. These are pulled with the transactions or the migrated data becomes uninterpretable once EBS is switched off.
Set of books / ledger structureChart of accounts segments, sets of books and the accounting calendar define what every balance means. They are established first because everything financial hangs off them.
Attachments in FND tablesDocuments attached to transactions live in the FND attachment tables with a separate content store. Carrying the row without the attachment loses the evidence the record existed for.