Pre-built SAP Business One data migration for every B1 module. Service Layer + DI API + direct HANA/SQL Server extraction. OCRD customer/vendor split, OACT → 6-segment COA, UDF/UDO disposition, FBDI emission, row-level reconciliation.
The hard part isn't moving rows out of OINV. It's translating B1's SMB-shaped data model into Fusion's enterprise-shaped data model without losing meaning.
SAP Business One and Oracle Fusion both store ERP data, but their assumptions about how an SMB or enterprise runs that data are completely different. B1 was designed for a 50-employee distributor in 2002 — a single combined customer/vendor table (OCRD with CardType), a flat OACT chart of accounts, a Formatted-Search-and-UDF extension model, partner-deployed customisations baked into every install. Fusion was designed for global enterprises — separate supplier and customer masters, a 6-segment COA, DFF/Application Composer extensions, declarative configuration. SAP Business One data migration has to bridge these worlds.
Custom SQL or hand-coded Service Layer pulls can bridge it, but every table is a multi-week negotiation between the SMB's finance team, their B1 partner (who may or may not be cooperative with the migration), and the Fusion implementation team. Syntra ETL replaces that with pre-built crosswalks refined across dozens of B1 → Fusion conversions: OCRD splits by CardType with de-duplication, OACT analysis with implicit-segmentation detection, UDF/UDO classification with DFF routing, OJDT/JDT1 journal load with sub-ledger preservation.
The same engine handles three common deployment scenarios: full single-company B1 to Fusion replacement, multi-company consolidation (often M&A roll-ups where each acquired SMB ran its own partner-customised B1), and hybrid setups where one entity stays on B1 because of a vertical-specific add-on while the rest move to Fusion.
The transformations Syntra ETL ships pre-built. No custom code, no multi-month bespoke development.
OCRD rows split by CardType (C=customer, S=supplier, L=lead). Fuzzy-match de-duplication where the same legal entity appears as both. FBDI Customer Import + FBDI Supplier Import emitted in parallel with preserved cross-reference.
Flat OACT chart parsed for implicit segmentation, cross-validated against OJDT/JDT1 posting patterns, Fusion 6-segment design proposed. Accounts that don't fit route to DFFs or analytical-only archive.
CUFD + OUDO catalog enumerated, each UDF/UDO classified by frequency of read/update and Formatted Search/Crystal Report dependency, mapped to Fusion DFF, Application Composer custom field, OIC external attribute, or retire.
OITM Item Master normalized to Fusion's item-class structure, OITB item groups mapped to Fusion categories, costing methods (Moving Average, FIFO, Standard) migrated with full posting history per warehouse from OINM.
OJDT header + JDT1 lines converted to Fusion GL_INTERFACE FBDI. Sub-ledger source preserved (TransType, BaseRef tracing back to OINV/OPCH/ORCT/OVPM). Multi-currency, multi-branch posting preserved.
Registered SDK and Service Layer add-ons inventoried with business-purpose classification. Each add-on routed to native Fusion functionality, Application Composer extension, OIC integration, or retire. Typical outcome: 50–70% retired.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your AP load fails on missing vendors.
Fusion enterprise structures, ledgers, BUs, COA segments, value sets, calendars configured. Loaded via FSM tasks or migration utility — not user-facing data, but everything downstream depends on it.
Chart of Accounts segment values, value sets, account hierarchies loaded via FBDI ChartOfAccounts and Value Set templates. Validated against B1 OACT trial balance for parent-child integrity.
Suppliers (FBDI Supplier Import — from OCRD CardType=S), customers (FBDI Customer Import — from OCRD CardType=C), items (FBDI Item Import — from OITM). Loaded in dependency order — items before sales orders, vendors before AP invoices.
GL period balances from OJDT/JDT1 (FBDI Journal Import), AP open invoices from OPCH (FBDI AP Invoice Import), AR open invoices from OINV (FBDI AutoInvoice), open POs from OPOR, warehouse balances from OINM. Each load reconciled to B1 before next stage.
Closed-period historical OJDT/OINV/OPCH loaded if Fusion is the target archive, or routed to Syntra archive if cold-data lifecycle dictates. Either way queryable for IRS/HMRC/GoBD audit during the retention window.
Final delta replay via Service Layer change tracking, parallel-close reconciliation, sign-off pack generation (trial balance, aging, inventory valuation — B1 vs Fusion to the cent). Production cut to Fusion.
Every SAP Business One data migration load produces signed, drill-downable reconciliation reports.
Source B1 row count (from OCRD, OITM, OJDT, OINV, OPCH) vs Fusion-loaded row count per table, per period, per business unit. Variance threshold zero for GL; configurable for archival domains.
Debit, credit, amount, quantity, and balance sums from JDT1, INV1, PCH1, RDR1 reconciled per period per ledger. Variance flags surfaced before any subsequent load is allowed to proceed.
Each record content-hashed at B1 source (Service Layer payload hash or row hash) and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff.
B1 trial balance from OJDT/JDT1 per period vs Fusion trial balance, drillable to journal line, sub-ledger source (OINV, OPCH, ORCT, OVPM, OINM), and originating document.
Open OPCH AP aging in B1 vs open AP invoice aging in Fusion, bucketed and reconciled by vendor; same for OINV AR by customer. Internal audit signs the pack directly without rebuild.
OITM/OINM warehouse-by-warehouse inventory valuation in B1 (Moving Average, FIFO, or Standard) vs Fusion Costing inventory valuation. Costing-method continuity validated before cutover.
SAP Business One data migration is the process of moving master data (business partners in OCRD, items in OITM, chart of accounts in OACT, warehouses in OWHS), open transactional records (sales orders, AR invoices, AP invoices, journal entries), and historical archives from a SAP Business One instance — whether running on SAP HANA or Microsoft SQL Server — into a target system such as Oracle Fusion Cloud. The technical heart of the work is schema transformation: B1's combined customer/vendor OCRD record is split into Fusion's separate supplier and customer masters; B1's flat OACT chart of accounts is collapsed into Fusion's fixed 6-segment COA; B1's UDF/UDO extensions are mapped to Fusion DFFs or Application Composer extensions. Syntra ETL handles every transformation with governed crosswalks and Oracle-validated FBDI output.
All three, depending on the table and the customer's preference. The B1 Service Layer (REST/OData) is the modern, SAP-supported interface and is preferred for master-data tables like OCRD, OITM, and OACT where row counts are moderate. The DI API (the older COM-based .NET API) is used for tables where the Service Layer has gaps. Direct database extraction via HANA SQL or SQL Server JDBC is used for high-volume historical tables like OJDT/JDT1 and OINV/INV1 where the SQL path is 10–50x faster than the API path. Syntra ETL automatically picks the right path per table based on volume and table characteristics, and customers can override per-table if their B1 partner has placed restrictions on direct database access.
SAP Business One stores customers and vendors in a single OCRD table, differentiated by the CardType column (C=customer, S=supplier/vendor, L=lead). Oracle Fusion uses separate Trading Community Architecture customer accounts (HZ_CUST_ACCOUNTS) and supplier records (POZ_SUPPLIERS_ALL_M). Syntra ETL's converter reads OCRD, splits rows by CardType, applies de-duplication where the same legal entity appears as both customer and vendor (common in services businesses), produces FBDI Customer Import payloads for the C rows and FBDI Supplier Import payloads for the S rows, and preserves the cross-reference so consolidated reporting on the same trading partner still works post-migration.
SAP Business One's OACT is a flat hierarchical chart of accounts — typically 200–2,000 accounts depending on company complexity — that uses a segment-style account code but isn't truly multi-segment in the Fusion sense. Oracle Fusion uses a fixed 6-segment Chart of Accounts (commonly: Company, Cost Centre, Account, Product, Project, Intercompany). Syntra ETL's COA analyser parses OACT account codes, identifies the implicit segmentation pattern, cross-references with OJDT/JDT1 posting patterns to validate the analysis, and proposes a Fusion 6-segment design. Account codes that don't fit cleanly route to DFFs or analytical-only archive. Every mapping is reviewed and signed off by finance before any load.
Yes — UDFs (User-Defined Fields) and UDOs (User-Defined Objects) are first-class citizens in the migration. The discovery engine queries CUFD (the UDF metadata table) and OUDO (the UDO metadata table) to enumerate every customer-specific extension on every B1 table, plus child UDF tables like @CUFD-extended item or business-partner attributes. Each UDF/UDO is classified by business usage (frequency of read, frequency of update, referencing reports and Formatted Searches) and given a Fusion disposition: DFF on the corresponding Fusion entity, Application Composer custom field, OIC-managed external attribute, or retire. The same disposition logic applies to Formatted Searches that read or compute against UDF values.
Syntra ETL emits FBDI (File-Based Data Import) ZIPs for every Fusion module that supports them: Supplier Import, Customer Import, Item Import, Journal Import, AP Invoice Import, AR Invoice Import (AutoInvoice), Purchase Order Import, and Sales Order Import. For Fusion entities without FBDI templates, the REST API path is used for incremental delta loads. Each payload is validated against the current Oracle Fusion 26x release schema before submission, so validation errors are caught locally — not in a 2-hour Fusion ESS job that fails on row 23,000. The output bundle includes a manifest, row counts, sum totals, and SHA-256 hashes per file for audit evidence.
Every record extracted from SAP Business One is hashed at the source (via Service Layer payload hash or direct database row hash). Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts, sum totals (debits, credits, invoice totals, quantities), and hash signatures per table, per period, per business unit. Any record that fails Fusion validation is captured in an error report with the exact field-level reason. The output is a signed, timestamped reconciliation pack: B1 trial balance from OJDT vs Fusion trial balance to the cent; OINV-derived AR aging vs Fusion AR aging; OPCH-derived AP aging vs Fusion AP aging. Internal audit signs off on the pack directly.
Yes. After the initial bulk load, Syntra ETL captures B1 deltas via Service Layer change-tracking (UpdateDate filtering on OCRD/OITM/OJDT etc.) and replays them into Fusion through REST APIs. This supports the standard parallel-run pattern: B1 continues taking production traffic (sales orders entered, invoices posted, warehouse moves recorded) for 1–2 close cycles while Fusion is validated against B1 to the cent. Once finance, sales, and operations are comfortable, traffic cuts to Fusion and B1 moves to archive-only mode. For multi-company B1 consolidations onto a single Fusion tenant, each company can cut over independently or on a coordinated calendar.
30-minute call. Walk through your B1 backend, data volumes, UDF/UDO inventory, partner-built add-on profile, and target Fusion design — leave with a concrete data-migration plan and FBDI emission strategy.