Pre-built Unit4 data conversion for Business World (Agresso), ERPx, and Coda Financials. Coding-structure → COA crosswalks, Flexi-Field routing, project/WBS to Fusion PPM, FBDI/HDL emitters, row-level reconciliation. Audit-ready evidence at every load.
The hard part isn't moving rows. It's translating Unit4's project-centric, services-firm data model into a general-purpose ERP target without losing meaning.
Unit4 and Oracle Fusion both descend from a relational lineage, but their data models diverge in ways that matter. Unit4 uses a flexible seven-series coding structure, customer-specific Flexi-Fields on every meaningful record, an effective-dated and project-centric core, and a delivered SQL Server schema (Agresso/Business World) or cloud-tenant schema (ERPx) with thousands of tables. Fusion uses a fixed 6-segment COA, business-unit-driven security, reference-data sets, project-and-task-driven PPM, and a Cloud-native schema accessed through FBDI/HDL/REST.
Every Unit4 data migration to Oracle Fusion has to bridge these gaps — and the bridging is where projects slip from quarters into years. Custom SQL written by hand against Unit4's schema can do it, but each table is a multi-week negotiation between functional, technical, and audit teams, and the project-model translation alone consumes months. Syntra ETL replaces that with pre-built crosswalks refined across dozens of Unit4 data migration projects across higher ed, public sector, and professional services.
The same engine handles three deployment scenarios: full Unit4 replacement (all modules → Fusion), single-pillar migration (Financials-only or Projects-only), and the hybrid pattern where Unit4 Business World goes to Fusion while specialty modules like a separate HCM or T&E tool stay in place and integrate to Fusion via OIC.
The transformations Syntra ETL ships pre-built for Unit4 data migration. No custom code, no multi-month bespoke development against the Agresso schema.
Unit4's seven flexible code series collapsed into Fusion's fixed 6-segment COA. Usage analyser identifies material splits; non-material series route to DFFs, PPM attributes, or analytical archive.
Every Flexi-Field inventoried, classified, and routed: Fusion DFF, EFF, PPM attribute, HCM extensible flexfield, or retire. Validation rules preserved, not flattened to generic notes.
Multi-level WBS walked per project, tasks classified into Fusion PPM task-types, resource assignments mapped, revenue-recognition rules converted to Fusion PPM revenue events. 20+ year history.
Coda Financials' management/statutory/tax/consolidation book structure preserved through extract, routed to Fusion primary/secondary ledgers or EPM consolidation per book-routing design.
Unit4 employeehistory and position-history effective-dated chains walked per worker, converted to Fusion HDL worker/assignment/salary event sequences with full 15+ year history.
Timesheet and expense claim history converted to Fusion PPM project actuals with full WBS allocation, billing-rate context, and approval state. Critical for services-firm migrations.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your project actuals load fails on missing projects.
Fusion enterprise structures, ledgers, BUs, COA segments, value sets, calendars, PPM project types and templates configured. Loaded via FSM tasks — 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 FBDI templates. Validated against Unit4 trial balance for parent-child integrity.
Suppliers (FBDI Supplier Import), customers (FBDI Customer Import), items (FBDI Item Import), employees + jobs (HDL Worker.dat + Assignment.dat), project templates and WBS (FBDI PPM Project Import). Loaded in dependency order.
GL period balances (FBDI Journal Import), AP open vouchers, AR open invoices, open POs, asset CIP and in-service balances, open project actuals. Each load reconciled to Unit4 before next stage begins.
Closed-period historical Financials data and 10–20 years of project actuals/billings loaded if Fusion is the target archive, or routed to Syntra archive if cold-data lifecycle dictates.
Final delta replay, parallel-close reconciliation, sign-off pack generation (trial balance, AP/AR aging, project actuals by WBS, asset register, worker headcount — Unit4 vs Fusion to the cent). Production cut to Fusion.
Every Unit4 data migration load produces signed, drill-downable reconciliation reports — including the project-centric checks general ETL tools miss.
Source Unit4 row count vs Fusion-loaded row count per table, per period, per business unit, per project. Variance threshold zero for GL; configurable for archival domains.
Debit, credit, amount, quantity, hours, billable-amount sums reconciled per period per ledger per project. Variance flags surfaced before any subsequent load proceeds.
Each record content-hashed at Unit4 SQL Server source and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff.
Unit4 trial balance per ledger per period vs Fusion trial balance, drillable to journal line, sub-ledger source, and originating voucher/invoice/project actual.
Unit4 project actuals by WBS vs Fusion PPM project actuals by task. Burn rates, utilization, revenue-recognition, billing — all reconciled per project per period.
Active worker counts, position rollups, billable resource counts in Unit4 vs Fusion. Salary and compensation totals reconciled per pay group; utilization targets preserved.
Unit4 data migration is the work of moving master data (coding structure values, customers, suppliers, projects, WBS, employees, resources), open transactional records (vouchers, invoices, journals, project actuals, timesheets, expenses), and historical archives out of Unit4 into a target system — typically Oracle Fusion, sometimes SAP S/4HANA or Microsoft Dynamics 365. Unit4 system migration is the broader project — application setup, security model, integration rewire, training, change management — of which data migration is one stream. Syntra ETL focuses on the data layer, where the technical risk concentrates: schema transformation, coding-structure collapse, Flexi-Field routing, project-model translation, FBDI/HDL emission, and row-level reconciliation. Customers pair Syntra ETL with their preferred SI for the broader programme.
In practice the terms are used interchangeably, but the technical distinction matters: migration is the end-to-end project (extract + transform + load + reconcile + cutover), while conversion is the transformation layer specifically — the rules that turn Unit4 data structures into target-system-shaped data. Syntra ETL's Unit4 data conversion engine ships with pre-built rules for coding-structure collapse, Flexi-Field classification, customer/supplier de-duplication, employee effective-dated history flattening, project/WBS translation to Fusion PPM, and Coda multi-book ledger remapping. These are the rules that, on a consultant-led Unit4 data migration project, would otherwise consume four to six months of bespoke SQL Server scripting against the Unit4 schema.
Unit4 is project-centric to a degree most other ERPs aren't — projects have multi-level WBS, project-driven revenue recognition, project-resource scheduling, time entries that post directly to project actuals, expense claims allocated to project tasks. Syntra ETL's project converter walks every Unit4 project through its WBS, classifies tasks into Fusion PPM task-types (capital, expense, billable, non-billable), maps resource assignments to Fusion PPM resources, converts Unit4 revenue-recognition rules to Fusion PPM revenue events, and produces FBDI PPM load files. For services firms with 20,000+ active projects and 10–20 years of project history, the converter parallelises across project IDs and typically loads at 1–2 million project transactions per hour. Project status, lifecycle, and approval state are all preserved.
Yes. Coda Financials (acquired by Unit4) has a distinctive multi-book ledger architecture — separate books for management, statutory, tax, and consolidation views over the same underlying transaction. Syntra ETL's Coda converter preserves each book during extract, applies book-specific transformation rules, and routes each book to the appropriate Fusion ledger or secondary ledger configuration. Customers migrating Coda specifically often choose to flatten consolidation books (since Fusion EPM handles consolidation natively) while preserving management/statutory book separation in Fusion's primary and reporting ledgers. Every book-routing decision is reviewed and signed off by group finance and statutory-reporting leads before any load runs.
Syntra ETL's Unit4 data migration emits all three Fusion-native load formats. FBDI (File-Based Data Import) ZIPs for Financials, SCM, and PPM — GL_INTERFACE, AP_INVOICES_INTERFACE, AR_INTERFACE_LINES, PJI_PROJECTS_INTERFACE, PJI_TASKS_INTERFACE, and the rest. HDL (HCM Data Loader) bundles for HCM — Worker.dat, Assignment.dat, Salary.dat, Element.dat, Position.dat. REST API payloads for incremental delta loads, supplier portal updates, and real-time integration. Each format is validated against the current Fusion 26x release schema before submission, so validation errors are caught locally — not in a 4-hour Fusion ESS job that fails on row 47,000.
Every record extracted from Unit4's SQL Server source is hashed at extract time. Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts, sum totals (debits, credits, amounts, quantities, project actuals), and hash signatures per table, per period, per business unit, per project. Any record that fails Fusion validation is captured in an error report with the exact field-level reason — ready for bulk fix or escalation. Output: a signed, timestamped reconciliation pack. Unit4 trial balance vs Fusion trial balance to the cent. AP aging vs AP aging. Project actuals by WBS vs Fusion PPM actuals by task. Internal audit signs off on the pack directly; no rebuild needed.
Yes. After the initial bulk load, Syntra ETL captures Unit4 deltas via SQL Server LAST_UPDATED watermarks (Unit4 maintains last-changed timestamps on most transactional tables) or optionally via SQL Server Change Data Capture (CDC) for high-velocity tables. Deltas replay into Fusion through REST APIs on a configurable cadence (15 minutes to hourly). This supports the standard parallel-run pattern: Unit4 continues taking production traffic for 1–2 close cycles while Fusion is validated against Unit4 to the cent. Once finance, project accounting, and audit are comfortable, traffic cuts to Fusion and Unit4 moves to archive-only mode.
Unit4's UK higher-education and public-sector customers carry specific data shapes: HESA student-finance returns, REF (Research Excellence Framework) cost capture, OfS data templates, funding-council split rules, NAO audit packs. Syntra ETL's higher-ed and public-sector templates preserve these data structures during extract and route them appropriately during transformation — most to Fusion DFFs/PPM attributes/grants module, some to long-term archive where the reporting requirement is statutory but operational use ends with the migration. Nordic public-sector customers (Swedish kommun, Norwegian fylke, Danish region) get a parallel template set for their specific reporting regimes.
30-minute call. Walk through your Unit4 product (Business World, ERPx, or Coda), data volumes, coding-structure design, project-history depth, and target — leave with a concrete Unit4 data migration plan.