Sage 300 Migration Cutover — Per-Company Orchestration

Sage 300 migration cutover is the orchestrated event — typically a 36–72 hour window over a fiscal-period close-out weekend — when production Sage 300 stops taking new transactions and Oracle Fusion starts. For a multi-company Sage 300 estate, cutover orchestrates: SQL Server quiesce per company database (Sage 300 read-only, new transactions blocked), final delta extract per company, final delta load to Fusion, final reconciliation per company per ledger, sign-off pages signed by finance/ops/IT/audit leadership, Fusion sub-ledger period open for new transactions, integration touchpoints re-pointed from Sage 300 endpoints to Fusion endpoints, ISV partner sunset (where applicable), Crystal Reports access frozen (with replacement OTBI/BI Publisher reports live), and user access switched. Done well, sage 300 migration cutover is undramatic — every step is rehearsed multiple times in parallel-run before the live event.

Sage 300's one-database-per-company architecture means cutover orchestrates per-database sequencing. Common cutover pattern: all company databases are quiesced simultaneously at T=0 (read-only mode, new transactions blocked across the estate); final delta extracts run in parallel across databases; final loads to Fusion run in parallel per business unit; reconciliation runs per company; sign-off per company (finance leadership for each entity signs the per-company reconciliation pack); consolidated sign-off across the estate; Fusion sub-ledger periods opened for new transactions across all business units. Some customers prefer a phased cutover where company databases cut over in waves (e.g. North American entities in wave 1, EMEA in wave 2, APAC in wave 3) — Syntra ETL supports both patterns.

For a single-company financials-only Sage 300 deployment, the cutover window is typically 24–36 hours over a long weekend. For a multi-company estate with 5–10 entities, 36–48 hours. For complex estates with 10+ entities, deep intercompany consolidation and active operations modules, 48–72 hours. The variables: number of company databases (parallel extraction has limits), total transaction volume of the final delta period, intercompany reconciliation depth, ISV partner sunset coordination, integration touchpoint re-pointing complexity. Most customers schedule cutover over a fiscal-period close-out weekend (typically month-end or quarter-end) so the period boundary aligns cleanly: prior period closes in Sage 300, new period opens in Fusion.

Most Sage 300 deployments carry one or more commercial ISV partner add-ons — Orchid Systems (Inquiry Tool, Document Management, Process Server), Pacific Technology (Pacific Banks, Pacific Recurring Entries), GenesysWorld (sub-ledger extensions), ProvenCFO, others. ISV partner sunset is coordinated within the cutover plan. For each ISV: license cancellation timing confirmed (usually aligned to month-end matching the cutover), data extraction from the ISV add-on completed and reconciled, functionality replacement validated live (Fusion-native, equivalent Fusion ISV, or retired-as-redundant), and partner contract exit negotiated. ISV sunset is one of the workstreams most likely to slip cutover timing — partner notice periods of 90 days are common — so the assessment phase establishes the sunset timeline and the cutover plan respects it.

Sage 300 deployments typically integrate with: bank feeds (Sage 300 Bank Services consuming MT940/BAI2 from banks), payment processors (Sage Payment Solutions, Stripe, others), payroll providers (ADP, Ceridian, others where Sage 300 Payroll isn't used), expense systems (Concur, Expensify), BI tools (Power BI, Tableau, Qlik reading from Sage 300 SQL or ODBC), custom EDI feeds, retail point-of-sale aggregators, e-commerce platforms (Shopify, Magento, BigCommerce), and warehouse management systems. At cutover, each integration touchpoint is re-pointed from Sage 300 endpoints to Fusion endpoints. The re-integration design (drafted in assessment, validated in parallel-run) is what makes the cutover re-pointing mechanical rather than improvised.

SQL Server quiesce means the Sage 300 SQL Server databases are placed in read-only mode at T=0, blocking new transactions. Mechanism: Sage 300 application servers stopped (no UI sessions, no Web Services), SQL Server database role-based access modified to deny INSERT/UPDATE/DELETE on transaction tables, SQL Server log shipping to read-replica completed and replica promoted to read-only authoritative source for the final extract. The quiesce is reversible (read-only flag can be cleared) until cutover sign-off completes — providing roll-back capability if reconciliation fails. After sign-off, the SQL Server databases remain read-only as the archive of record until decommissioning is complete (typically 3–6 months later).

Cutover rollback is defined explicitly in the cutover plan with named triggers. Roll-back triggers: critical reconciliation variance that can't resolve in the cutover window (typically per-company trial balance variance, intercompany equilibrium failure, multicurrency revaluation parity failure); critical integration touchpoint failure (bank feed not connecting to Fusion, payment processor not posting); critical user-acceptance failure (period-open users can't post a transaction). On trigger, the cutover team escalates to the steering committee for a continue/extend/roll-back decision. Roll-back path: SQL Server quiesce flag cleared (Sage 300 returns to read-write), Fusion period kept closed, integration touchpoints kept on Sage 300 endpoints, root cause investigation in the following week, re-cutover scheduled for the next fiscal-period close. Roll-back is rare but the option being on the table is what disciplines the resolution work.

Cutover validation runs at three levels in the 24 hours post-Fusion-open. Smoke tests: representative users (one per business unit, one per active module) execute predefined test transactions — post a journal, enter an AP invoice, create an AR receipt, run a sales order, run a PO, run a project transaction. Each smoke test is timed and pass/fail signed. Operational validation: real production transactions for the first business day in Fusion are monitored with elevated attention. Variance from expected volumes triggers investigation. Reconciliation validation: end-of-day Fusion totals reconcile against the expected post-cutover baseline. Final cutover sign-off page is signed at T+24 hours by finance, ops, IT and audit leadership. After T+24, cutover team transitions to hypercare (typically 4–6 weeks of elevated support before standard operations).