SAP Business One Migration Cutover for SMBs

A SAP Business One migration cutover for an SMB typically runs over a single weekend — Friday evening to Monday morning — for a single-company B1 instance, or a coordinated multi-weekend wave for multi-company consolidations. Friday evening: stop all B1 user sessions, quiesce SQL Server / HANA, run final delta extract via Service Layer with UpdateDate filtering on OCRD/OITM/OJDT/OINV/OPCH/ORDR/OPOR. Saturday: load delta into Fusion via FBDI and REST, run reconciliation pack, fix any variances. Sunday: parallel-close test, sub-ledger-to-GL ties, AR/AP aging tie-out, inventory valuation tie-out, signed sign-off. Monday morning: Fusion goes live, B1 moves to read-only archive mode. In-flight order handling, partner sunset coordination, and rollback plan are all pre-staged.

In-flight transactions are the trickiest part of any B1 cutover. The SAP Business One migration cutover playbook freezes new order entry in B1 at a defined cutover-start timestamp, then handles in-flight items in three categories. Sales orders entered in B1 but not yet delivered: migrated to Fusion as open ORDR records, Fusion takes over the delivery cycle. Deliveries posted in B1 but not yet invoiced: migrated as in-progress fulfilment, Fusion AR raises the invoice. AP invoices received in B1 but not yet matched to PO/GR: migrated with PO match status preserved, Fusion AP completes the match cycle. Each category has dedicated reconciliation logic so no transaction is lost or double-counted across the cutover boundary.

Quiescing the B1 backend during cutover ensures the final delta extract sees a consistent point-in-time view. For SQL Server-based B1, the playbook uses SQL Server's snapshot isolation level on the company database or, for high-volume environments, takes a read-only database snapshot from which the extract runs. For HANA-based B1, the playbook uses HANA's time-travel queries (AS OF SYSTEM TIMESTAMP) to read from a consistent commit boundary or operates against a HANA system replication standby. Either way, B1 users are logged off at the cutover-start timestamp, no new transactions can post, the extract runs against the quiesced backend, and the FBDI loads to Fusion proceed from a known consistent source state. The quiesce window is typically 4–8 hours for a mid-sized SMB.

The SAP Partner Edge partner who deployed B1 needs to be coordinated through the cutover because their access, their support agreement, and their licence wind-down are all on contracted timelines (typically 3–6 month notice periods). The cutover playbook coordinates: partner notice issued at project kickoff (so the notice period runs in parallel with the project, not after), partner read-only access during pre-migration and migration phases for any required help on partner-built add-ons, partner sign-off on add-on retirement decisions during data mapping, partner-supplied knowledge transfer documents archived as part of the migration evidence pack, partner final invoices reconciled and paid, partner B1 licence transfer-or-terminate paperwork filed at the SAP Partner Edge portal. By cutover weekend, the partner relationship is fully wound down or transitioned.

Every SAP Business One migration cutover includes a documented rollback plan with explicit trigger conditions, named owners, and time-boxed decision windows. Trigger conditions include: trial balance variance >$10,000 that can't be resolved within 4 hours, AR or AP sub-ledger tie failure that can't be resolved within 4 hours, item count mismatch >0.5% that can't be resolved, business-critical functionality (order entry, invoice printing, payment processing) failing acceptance test. Rollback procedure: B1 backend reactivated (it's still quiesced, not decommissioned), Fusion load reversed (FBDI ZIPs documented and reversed via Fusion's data deletion process or by aborting the conversion and reloading at the next attempt), partner notified, new cutover date scheduled. Rollback has only been triggered in a small minority of real-world cutovers but the plan exists for every project.

Multi-company consolidations onto a single Fusion tenant get a coordinated wave-based cutover plan rather than a single weekend. A typical pattern: wave 1 (lightest entity, often a finance-only acquired SMB) cuts over weekend 1 to derisk the playbook, wave 2 (medium-complexity entities, perhaps 3–5 SMBs) cuts over weekends 3–7, wave 3 (most complex entity, often the parent or the largest manufacturing operation) cuts over weekend 9 or later. Each wave runs the same SAP Business One migration cutover playbook against its B1 instance, lands as a Fusion BU in the unified tenant, and gets its own reconciliation sign-off. Inter-company eliminations are handled in Fusion's native intercompany model once all relevant entities are live. Total elapsed for a 10-entity roll-up: typically 3–5 months across waves.

After cutover, B1 typically stays in read-only archive mode for 60–180 days. During this window: finance teams can drill back to B1 for any go-live questions, internal audit can validate any reconciliation finding against the source, external auditors (in the first post-conversion year) can walk through the conversion evidence with both systems live, the partner can complete final knowledge transfer if needed. After the archive window closes, B1 is fully decommissioned: HANA or SQL Server backend taken down, licences terminated through SAP Partner Edge, hardware released, and the closed-period historical data either migrated into Fusion archive or routed to Syntra's long-term cold archive with auditor-grade query access for the remaining IRS/HMRC/GoBD retention period (7–15 years).

Yes — many SMBs prefer a long-weekend cutover (Thursday evening to Tuesday morning) over a single-weekend cutover because the extra day reduces stress on the reconciliation and sign-off cycle. The Syntra ETL cutover playbook accommodates either pattern: single-weekend (Friday evening start, Monday morning live) for SMBs with simpler data shapes and good pre-migration validation, long-weekend (Thursday evening start, Tuesday morning live) for SMBs with more complex data or those wanting extra parallel-run buffer. Some customers extend even further with a Wednesday-to-Wednesday cutover that runs B1 and Fusion in true parallel for a week post-load, with Fusion taking primary status only after a full close cycle is validated in both systems. The choice depends on SMB risk tolerance and the post-go-live support model.