SAP Business One Migration Checklist for SMBs Moving to Fusion

A complete SAP Business One migration checklist for SMBs covers six tracks in parallel: B1 backend confirmation (HANA vs SQL Server vs hybrid post-M&A), data inventory with row counts per OCRD/OITM/OJDT/OINV/OPCH/ORDR partition, partner-built add-on catalogue (SDK/.NET add-ons, Service Layer add-ons, B1iF flows), UDF/UDO inventory from CUFD and OUDO, Crystal/B1 Studio/PLD report library with frequency-of-use telemetry, and Fusion target-state design (6-segment COA, BU model, SLA rules). The checklist also covers operational items SMBs miss: SAP Partner Edge contract notice periods, B1 licence wind-down timing, intercompany add-on retirement, and Crystal Reports licence sunset. Each item has owner, deadline, status, and cross-reference to the master timeline.

Because SAP Business One has SMB-specific quirks no generic ERP migration checklist captures. The OCRD combined customer/vendor table needs CardType split logic before any FBDI Customer or Supplier Import can run. The flat OACT chart of accounts needs collapsing into Fusion's 6-segment COA — and the implicit segmentation pattern is buried in OJDT/JDT1 posting behaviour, not in OACT metadata. Partner-built SDK add-ons need a registered-component inventory crawl against SBO-COMMON. UDFs live in CUFD with a naming convention defined by your B1 partner rather than SAP. Crystal Reports, B1 Studio reports, and PLD print layouts each have different rebuild approaches. A SAP Business One migration checklist treats every one of these as a named, owned line item — not a footnote.

Discovery starts day one with a read-only crawl of SBO-COMMON to enumerate every registered SDK add-on (.NET-based, COM-registered), every Service Layer add-on, every B1iF flow, every UDO from OUDO, and every UDF from CUFD. Each item is logged with: vendor (often the SAP Partner Edge partner that deployed B1), licence status, last-modified date, business owner, and frequency of invocation derived from B1 audit logs where available. The output is a partner-customisation inventory that becomes a tracked artefact in the migration checklist. Each add-on gets a Fusion disposition recommendation: replace with native Fusion functionality, replace with Application Composer extension, replace with OIC integration flow, or retire outright. Typically 50–70% of partner add-ons are retired during cleanup.

Both backends host the same logical B1 application but differ in extraction mechanics and operational impact. The SAP Business One migration checklist accounts for: extraction interface (HANA SQL via JDBC against the column-store, SQL Server JDBC against the row-store), batch-window timing (HANA-based B1 typically has shorter overnight windows because it powers more analytical reporting), licence model (HANA-based B1 carries a separate HANA licence whose decommissioning needs synchronising with the B1 wind-down), and operational read-replica options (HANA system replication vs SQL Server log shipping vs Always On). The checklist surfaces these as concrete tasks with owners — not as background notes — because every one of them has a deadline that affects the cutover plan.

The pre-migration phase — assessment, inventory, target design, sign-off — runs 2–4 weeks elapsed for a typical SMB. Week one is discovery: extractor connects to B1, enumerates schema, counts rows, samples data, crawls SBO-COMMON. Week two is customisation inventory: UDFs/UDOs/add-ons/reports/integrations catalogued and classified. Weeks three and four are target design and sign-off: Fusion COA mapping, OCRD split rules, item-class mapping, FBDI sequence, integration replacement strategy. The SAP Business One migration checklist makes every artefact visible: who owns each item, what's signed off, what's pending. Most SMBs find this phase the most productive part of the project because it forces decisions that have been deferred for years.

Yes — retention is a named track on the checklist. SMBs running B1 typically face overlapping retention requirements: IRS 7-year tax record retention (US), HMRC 6-year retention (UK), GoBD 10-year retention with immutable storage (Germany), French CGI 10-year retention, Italian SDI multi-year retention, Brazilian SPED retention. The migration checklist captures which entities are subject to which regimes, current retention coverage (which years of OJDT/OINV/OPCH still need to be preserved), and the target archive design (loaded into Fusion archive history, routed to Syntra cold archive, or kept read-only in a decommissioned B1 read replica). Every regime has an owner, a deadline, and an audit-evidence requirement that maps to a specific deliverable.

Crystal Reports, B1 Studio reports (on HANA-based B1), and PLD (Print Layout Designer) print layouts each get a dedicated checklist track. PLD layouts — used for invoices, purchase orders, delivery notes — need rebuilding in Fusion BI Publisher because they don't carry over. Crystal Reports get inventoried with frequency-of-use telemetry: typically 50–70% are never opened and can be retired outright. B1 Studio dashboards get rebuilt in OTBI. The checklist tracks each report with: business owner, frequency of use, business value classification (critical/important/nice-to-have), Fusion equivalent (OTBI dashboard, BI Publisher report, FRS report, Smart View), rebuild owner, and sign-off status. The output is a complete reporting-cutover deliverable, not a post-go-live rebuild backlog.

Yes — multi-company consolidations (often M&A roll-ups where each acquired SMB ran its own partner-customised B1) get a tailored variant. The checklist tracks per-company inventory: each B1 company gets its own OACT analysis, its own OCRD split rules, its own UDF/UDO inventory, its own add-on catalogue, its own partner contract status. A master consolidation track maps each company's OACT to a unified Fusion 6-segment COA, identifies de-duplication candidates across OCRDs (the same vendor appearing in multiple acquired B1 instances), and sequences cutovers (typically wave-based — finance-light entities first, complex manufacturing entities last). Partner contracts are tracked per company because acquired entities often have different SAP Partner Edge partner relationships with different notice periods.