A 2–3 week structured discovery of your B1 deployment — data volumes, UDF/UDO inventory, partner add-on catalog, report library, integration map — producing a sized, costed, risk-assessed migration plan to Oracle Fusion.
Two SMBs nominally running 'B1 on HANA' can have wildly different complexity profiles. Without an assessment, the first 3–4 months of every migration become a hidden discovery phase.
SAP Business One is sold and implemented through the SAP Partner Edge channel, which means almost every B1 deployment reflects a specific partner's design opinions: their preferred UDF naming conventions, their bolt-on SDK or Service Layer add-on architecture, their Crystal Report style, often their own intercompany or multi-entity workaround. The result is that no two B1 instances are alike — even when both are nominally running the same B1 version on the same HANA or SQL Server backend.
This matters for migration because Oracle Fusion implementation partners and migration tooling vendors typically quote based on generic assumptions: 'mid-sized B1 with standard modules, moderate customisation'. The reality is rarely standard. The assessment phase that traditional consultant-led migrations spend 3–4 months on is essentially re-discovering what the specific B1 deployment actually does — UDF by UDF, add-on by add-on, Crystal Report by Crystal Report. Cost overruns and timeline slippage trace back to this hidden assessment work almost every time.
A SAP Business One migration assessment makes this work explicit. 2–3 weeks of structured discovery: data volumes per table, UDF inventory from CUFD, UDO inventory from OUDO, add-on registry from SBO-COMMON, report library catalog, integration touchpoint map, partner-specific extension identification. The output is a sized, costed migration plan — and the actual migration project starts with the assessment phase already complete, eliminating 3–6 months of timeline drift.
Every dimension that drives migration cost, timeline, and risk — quantified and documented.
Per-table row and byte counts across all fiscal years: OJDT/JDT1 (journal entries), OINV/INV1 (AR), OPCH/PCH1 (AP), OINM (inventory postings), OCRD (BPs), OITM (items). Growth rates calculated. Sized against Fusion FBDI throughput for cutover load-time prediction.
Every UDF on every base table enumerated via CUFD (typical mid-sized B1: 100–500 UDFs). Every UDO enumerated via OUDO (typical: 5–30 customer-specific objects). Frequency-of-use analysis to drive disposition decisions.
SDK add-ons (.NET-based) and Service Layer add-ons from SBO-COMMON catalog. Each classified by source (SAP-delivered, partner-built, third-party), business purpose, and Fusion-equivalence path.
Every Crystal Report (.rpt files), B1 Studio dashboard (HANA-based B1), PLD layout, Formatted Search. Indexed by name, last-used date, business owner. Frequency-of-use analysis drives retire/replace decisions.
Every Service Layer REST consumer, DI API .NET integration, B1iF flow, custom database trigger, scheduled job. Mapped to OIC/REST/ESS replacement strategy. Critical for not breaking upstream/downstream systems at cutover.
Identification of design patterns specific to the original SAP Partner Edge partner who installed and customised B1. Common patterns: partner-specific intercompany hack, partner-specific multi-entity workaround, partner-specific approval workflow.
2–3 weeks elapsed, 4–7 person-weeks effort, fully read-only against live B1.
30-minute kick-off with finance, operations, IT. Confirm B1 backend (HANA or SQL Server), number of companies, fiscal-year history depth, target Fusion modules, any known integration complexities or partner constraints. Establish read-only access (Service Layer user or DB role).
Extractor connects to B1, enumerates installed schema (delivered tables + CUFD UDFs + OUDO UDOs), counts rows per table per fiscal year, samples representative data for shape analysis. Outputs: per-table volume report, schema map with UDF/UDO annotations.
Discovery crawls SBO-COMMON add-on registry, Crystal/B1 Studio/PLD report library, Formatted Search definitions, B1iF flows, custom database triggers. Each item classified by business purpose and given Fusion-equivalence recommendation. Partner-specific design patterns identified.
OACT analysis produces Fusion 6-segment COA design proposal. OCRD CardType split with de-dup analysis. Item-class mapping. UDF disposition matrix. FBDI/HDL load sequence designed. Integration replacement strategy mapped per touchpoint.
Project plan sized phase-by-phase with 80/20 confidence bands. Cost estimate for migration plus 3- and 5-year Fusion TCO vs current B1 TCO. Risk register populated with quantified impact and mitigation strategies.
Interactive workshop with finance, operations, IT leads (2–4 hours). Crosswalks reviewed and signed off. Scope decisions made (which modules first, parallel-run duration, cutover date). Project plan signed off. Ready to start migration execution.
The findings that consistently change project scope, cost, or timeline — discovered up-front rather than mid-project.
Mid-sized B1 typically has 100–500 UDFs of which 30–60% are unused or used by a single departed employee. The assessment surfaces these so they can be retired during migration rather than carried as DFFs in Fusion.
Registered SDK or Service Layer add-ons whose vendors have ceased trading, whose licences have lapsed, or whose functionality is no longer used. Identified early so they can be cleanly retired.
Typical SMB B1 carries 50–200 Crystal Reports of which 30–50% are never opened. Frequency-of-use analysis identifies the 20–40 reports that actually matter — these get rebuilt in OTBI/BI Publisher; the rest retire.
Service Layer REST consumers, scheduled DI API jobs, B1iF flows, and database-trigger-driven integrations that no one remembers setting up. Found via SBO-COMMON catalog + log analysis. Each needs an OIC/REST/ESS replacement strategy.
SAP Partner Edge partner contracts often have notice periods (3–6 months) and knowledge-transfer obligations that affect decommissioning timing. Surfaced during assessment so the partner wind-down is planned correctly.
Most B1 OACT charts of accounts carry design debt — historic accounts added ad-hoc by previous controllers, duplicate accounts that should have been merged, inactive accounts that should have been archived. Assessment proposes Fusion COA cleanup as part of migration.
A SAP Business One migration assessment is a structured 2–3 week discovery process that catalogues every relevant aspect of an existing B1 deployment — data volumes, module usage, partner-built customisations, UDFs/UDOs, integrations, reports, infrastructure — and produces a sized, costed, risk-assessed migration plan to Oracle Fusion (or another target). SMBs need one because B1 deployments vary wildly: two SMBs nominally running 'B1 on HANA' can have completely different complexity profiles depending on which partner installed them, what add-ons they've accumulated, and how heavily they've customised UDFs. Without a proper assessment, migration projects routinely slip 3–6 months because the first 3–4 months of the project become a hidden assessment phase. With one, the actual cutover work starts on day one of the project.
Typically 2–3 weeks elapsed time, with 4–7 person-weeks of effort from the assessment team. Week 1: data inventory and volume analysis (extractor connects to B1 HANA or SQL Server, enumerates installed schema including UDFs/UDOs via CUFD/OUDO, counts rows per table per fiscal year, samples representative data for shape analysis). Week 2: customisation inventory (SDK and Service Layer add-on enumeration, Crystal/B1 Studio/PLD report library catalog, Formatted Search analysis, integration touchpoint mapping via B1iF or other middleware, partner-specific extension identification). Week 3: target design and sizing (Fusion COA design from B1 OACT analysis, FBDI/HDL load sequence, parallel-run plan, cutover risk register, sized project plan with 80/20 confidence estimates).
All in-scope tables across all fiscal years. The key tables for sizing: OJDT (journal entry headers — typically 100K–10M rows for SMBs) and JDT1 (journal entry lines — typically 1M–100M rows, scales with company size and history depth); OINV/INV1 (AR invoices — 50K–5M rows); OPCH/PCH1 (AP invoices — similar volumes to AR); OINM (inventory postings — often the largest table at 1M–500M rows); OCRD (business partners — 1K–500K rows); OITM (items — 1K–500K rows); UDF columns on each (count and volume); UDO data tables (highly variable). The assessment produces a per-table row count, byte count, and growth rate, sized against Fusion FBDI load thresholds to predict load times during cutover.
The customisation inventory is the most labour-intensive part of the assessment because partner-built B1 customisations are unique per customer. The assessment queries CUFD to enumerate every UDF on every base table (typical mid-sized B1 carries 100–500 custom UDFs). Queries OUDO for every UDO (typical 5–30 customer-specific objects). Reads the SBO-COMMON registered add-on catalog for every SDK and Service Layer add-on. Catalogues every Crystal Report (.rpt files in the report library), B1 Studio dashboard (HANA-based B1 only), PLD layout, Formatted Search SQL. Each item gets classified by business purpose (when known) and given a Fusion-equivalence recommendation: native, DFF, Application Composer, OIC, OTBI/BI Publisher, or retire. The output is a partner-customisation disposition matrix that drives the actual migration scope.
Yes. The assessment runs entirely read-only against B1 — typically via the Service Layer REST API with a dedicated read-only B1 user, or via a granted database role with SELECT on the company schema (HANA or SQL Server). The extractor and discovery engine are throttled to keep impact below 10% of source capacity. Sales orders keep getting entered, invoices keep posting, the warehouse keeps shipping. For partner-customised B1 instances where direct database access is restricted by partner contract, the entire assessment can run via Service Layer alone — slower for high-volume historical tables but operationally invisible. Assessment output is a set of artifacts (inventory CSVs, sizing reports, design diagrams) delivered to the SMB without any B1 system changes.
A structured pack with five components. (1) Inventory artifacts: per-table row/byte counts, UDF catalog, UDO catalog, add-on registry, report library, integration touchpoint map. (2) Crosswalk drafts: OACT to Fusion COA segment design, OCRD CardType split plan with de-dup analysis, item-class mapping, UDF disposition matrix (which UDFs become DFFs, which retire, which become Application Composer extensions). (3) Sized project plan: phase-by-phase breakdown with effort estimates, FBDI/HDL load sequence, parallel-run plan, cutover risk register. (4) Cost estimate: migration project cost, ongoing Fusion cost, eliminated B1 cost, net TCO impact over 3 and 5 years. (5) Risk register: identified risks (partner support gaps, regulatory deadlines, integration complexities) with mitigation strategies. Delivered as a workshop, not a static deck — finance and operations leads work through the pack interactively.
Each B1 company is assessed independently because B1 stores each company in its own database with its own OACT/OJDT/OCRD/OITM. The assessment runs the discovery engine against each company, produces per-company inventory and sizing, then synthesises a cross-company analysis: which companies share customers (OCRD overlap analysis), which share items (OITM overlap), which share UDFs/UDOs (CUFD/OUDO overlap), which have the most customisation divergence. This is critical for M&A roll-ups onto Oracle Fusion: the assessment identifies which acquired SMBs have similar B1 setups (easy to consolidate) versus heavily-customised outliers (need bespoke handling). The output drives a per-company migration wave plan — typically simpler companies first, more complex companies last.
No. The assessment deliverable is your data regardless of who runs the migration. The inventory artifacts (per-table row counts, UDF catalog, add-on registry, report library) and the design crosswalks (OACT to Fusion COA, OCRD split plan, UDF disposition) are useful inputs to any migration approach — Syntra ETL, your SAP partner, an Oracle Fusion implementation partner, or a hybrid team. That said, customers who run a Syntra ETL assessment typically also run the migration with Syntra because the assessment has already produced the configured crosswalks, extraction profiles, and validation rules — the migration is essentially a continuation of the assessment rather than a fresh start. Either way, the assessment derisks the migration regardless of execution path.
Book the 2–3 week assessment. Read-only access to live B1, structured discovery of data + UDFs/UDOs + add-ons + reports + integrations, workshop delivery of sized migration plan. Derisks your Fusion migration before you commit to it.