Working sage 300 migration checklist used on programmes from Sage 300 (Accpac heritage) to Oracle Fusion. Per-company SQL DB inventory, SDK/VB customisation, Crystal Reports library, ISV partner sunset, integration map, compliance jurisdiction.
Not a slide-deck artifact. Not a tickbox-and-forget compliance document. A living runbook referenced at every steering committee, every parallel-run review, every cutover dress rehearsal.
Sage 300 — formerly Sage Accpac, before that Computer Associates Accpac, originally Basic Software Group 1979 — carries four decades of accumulated mid-market deployment context. The sage 300 migration checklist that works on a real programme has to respect that context line by line. Per-company SQL Server databases (the one-database-per-company architecture is Sage 300's defining technical signature). SDK customisations (.NET modules wired into Sage 300's screens and transactions). Visual Basic scripts (attached to screens, often undocumented). Crystal Reports (Sage 300's primary reporting engine, hundreds or thousands of reports per customer). ISV partner add-ons (Orchid Systems, Pacific Technology, GenesysWorld, ProvenCFO, Spire, Altec, dozens of vertical-specific partners).
A generic 'ERP migration checklist' downloaded from a consultancy website covers extraction, transformation, loading, reconciliation and cutover but treats the source ERP as a black box. That document is useless for a Sage 300 migration. A working sage 300 migration checklist is source-specific — every item knows about Sage 300's architecture, customisation patterns, reporting engine, ISV ecosystem and module conventions. The 60+ items in the framework below are derived from dozens of field programmes and validated against the patterns of failure that recur when the items are missed.
Every item has named owner (named individual, not 'IT team'), named output (specific artifact, not 'documentation'), named sign-off (specific authority, not 'as appropriate'). The checklist is the runbook — referenced at every checkpoint, signed off section by section before cutover, used as evidence pack post-cutover for SOX, GoBD or audit examination.
Each category breaks down into 6–15 working items. Every item has owner, output and sign-off authority.
12+ items per database. Configuration profile, active modules, table row counts, master record counts, custom SDK tables, VB scripts, Crystal Reports, integration touchpoints, compliance retention, cutover sequencing role, quiesce mechanism, reconciliation owner.
8+ items. Unified CUSTOMER dictionary with deduplication candidate review. Unified VENDOR dictionary. Unified ITEM dictionary with item-catalog mapping. GLAMF chart-of-accounts walk and Fusion COA segment mapping. TCA party design. Cross-reference attribute preservation.
10+ items. .NET SDK module inventory with call signature. Visual Basic script inventory. Custom SQL table dependencies. Business-purpose classification. Fusion-equivalent design (native / AMX / OIC / OTBI / BI Publisher / VBCS). Re-implementation effort sizing.
7 items. Library crawl (every .rpt file, every Crystal Reports Server report, every embedded report). Usage signal capture. Business-value classification. Replacement strategy per report. Critical-report rebuild prioritisation. Replacement validation. Cutover sign-off.
8 items per ISV. Contract terms. Functionality inventory. Data extraction plan. Replacement decision. Replacement validation. Partner notification (90+ days). Final data extraction. Contract exit confirmation.
30+ items across integrations, compliance jurisdictions, parallel-run, cutover orchestration, hypercare model. Bank feeds, payment processors, payroll providers, expense systems, BI tools, EDI, POS, e-commerce. SOX, GoBD, IRS, CRA, HMRC, GDPR, state tax. Smoke tests, sign-off matrix, roll-back triggers.
The 60+ items don't all happen in one phase. They sequence across the migration lifecycle. Sequence matters — late execution is the most common source of cutover slippage.
Per-company database inventory items (all 12 per database). SDK + VB + Crystal Reports inventory items. ISV partner inventory items. Integration touchpoint map. Compliance jurisdiction map. Multicurrency and intercompany footprint items. Output: complete inventory across all 9 categories.
Master-data harmonisation decisions signed off. SDK customisation triage decisions (retire vs re-implement). Crystal Reports replacement strategy per report. ISV partner sunset path per partner. Integration re-design per touchpoint. Compliance retention strategy per jurisdiction.
Per-company SQL extraction with harmonisation. FBDI emission per module. Fusion ESS load. Row-level reconciliation per company per period. Crystal Reports replacement rebuilds. ISV partner notification at 90-day mark. Integration re-pointing rehearsal builds.
1–2 fiscal-period cycles in parallel. Per-company reconciliation to the cent. Crystal Reports replacement validation against Crystal output. ISV partner replacement validation. Integration re-pointing rehearsal. UAT smoke tests. Cutover dress rehearsals.
Quiesce per-company simultaneously. Final delta extraction in parallel. FBDI loads in parallel. Per-company reconciliation + sign-off pages signed. ISV partner sunset. Integration touchpoint re-pointing in defined sequence. T+24 consolidated sign-off.
Variance disposition. 4–6 weeks elevated support. Sage 300 environment moves to read-only archive. Long-retention archive configured per compliance jurisdiction. SQL Server licence cancellation. ISV partner billing cessation confirmed. Final checklist sign-off as audit evidence pack.
Each of these has caused a Sage 300 migration to slip when missed on customer-led scoping. Every working checklist surfaces them.
Customers who 'have 8 entities' often have 12+ active Sage 300 databases — historical subsidiaries kept alive for tax filing, M&A acquisitions never decommissioned. Each is migration scope and reconciliation scope.
VB scripts attached to Sage 300 screens are nearly invisible until inventoried by call-signature crawler. Often 50–100 scripts per deployment, undocumented, written by departed contractors.
SDK modules write to custom SQL tables outside the standard Sage 300 schema. Inventory is required so custom-table data is captured in extraction and migrated (or archived) appropriately.
Crystal Reports Server (commercial standalone deployment) is separate from Sage 300's embedded Crystal Reports. Both have to be crawled. Server-side reports often forgotten in initial scoping.
Orchid Document Management blob storage, Pacific Banks reconciliation history, GenesysWorld extension tables. ISV-specific data is outside core Sage 300 SQL and requires its own extraction workstream.
Customers with 10+ years of Sage 300 history often have manual rate-entry periods (pre-automated-feed era). Rate gaps blow up Fusion revaluation parity. Surface in extraction, not at cutover.
A working sage 300 migration checklist covers 60+ pre-cutover items across nine categories: per-company database inventory (configuration, modules, table volumes, masters), master-data harmonisation (CUSTOMER/VENDOR/ITEM deduplication, GLAMF mapping), SDK and Visual Basic customisation inventory (classification, business purpose, Fusion-equivalent design), Crystal Reports library inventory (usage, classification, replacement strategy), ISV partner sunset coordination (contract terms, notice periods, replacement validation), integration touchpoint mapping (bank feeds, payroll, expense, BI, EDI, e-commerce, POS), compliance jurisdiction mapping (SOX, GoBD, IRS, CRA, HMRC, GDPR, state sales tax), multicurrency and intercompany footprint (currencies, rate sources, IC counterparty pairs, consolidation methodology), and parallel-run / cutover orchestration (reconciliation rigor, sign-off matrix, roll-back triggers, hypercare model). Every item has named owner, named output, named sign-off.
A generic ERP migration checklist covers data extraction, transformation, loading, reconciliation and cutover — but treats the source ERP as a black box. A working sage 300 migration checklist is source-specific: every checklist item knows about Sage 300's one-database-per-company architecture, its SDK customisation patterns, its Crystal Reports primacy, its Visual Basic screen-script convention, its ISV partner ecosystem (Orchid Systems, Pacific Technology, GenesysWorld, ProvenCFO, Spire, Altec), its Multicurrency module rate-type taxonomy, its Intercompany Transactions module convention, its Sage 300 Payroll US/Canada coverage. A Sage 300 (formerly Accpac, originally Basic Software Group 1979) deployment carries four decades of accumulated context, and a working checklist respects that context line by line rather than treating Sage 300 as 'generic ERP'.
Ten checklist items routinely missed on customer-led migration scoping. (1) Latent company databases — historical subsidiaries kept alive for tax filing, M&A entities never decommissioned. (2) Visual Basic script inventory — VB scripts are nearly invisible until inventoried by call-signature crawler. (3) Custom SDK table dependencies — SDK modules often write to custom SQL tables that aren't in the standard Sage 300 schema. (4) Crystal Reports Server vs embedded reports — both have to be crawled. (5) ISV-specific data extraction (Orchid Document Management blob storage, Pacific Banks reconciliation history). (6) Manual-entry-era multicurrency rate history. (7) Sage 300 Payroll YTD and tax-form continuity across cutover (W-2 / T4 / state). (8) Bank Services reconciliation history continuity. (9) Project & Job Costing WIP continuity into Fusion PPM. (10) Pre-cutover sign-off pages with named finance/ops/IT/audit signatories — without these the cutover lacks accountability discipline.
Per-company database section of a sage 300 migration checklist runs 12+ items per Sage 300 company database. For each company database: (1) Configuration profile (fiscal calendar, COA segments, currency, posting profiles). (2) Active modules inventory (GL, AP, AR, IC, OE, PO, PJC, FA, BS, Multicurrency, IC, Payroll). (3) Table row counts per module. (4) Master record counts (CUSTOMER, VENDOR, ITEM, GLAMF). (5) Custom SDK tables specific to this database. (6) Visual Basic scripts specific to this database. (7) Crystal Reports specific to this database. (8) Integration touchpoints consuming this database. (9) Compliance retention requirement (per legal entity jurisdiction). (10) Cutover sequencing role (wave 1, wave 2, simultaneous). (11) Quiesce mechanism (SQL Server role-based, log shipping target). (12) Reconciliation owner (finance leadership for the entity). All 12 items signed off per company before cutover.
ISV partner sunset section of a sage 300 migration checklist runs 8 items per ISV partner. For each ISV partner (Orchid Systems, Pacific Technology, GenesysWorld, ProvenCFO, Spire, Altec, vertical ISVs): (1) Contract terms inventory (start date, renewal date, notice period). (2) Functionality inventory (what the ISV does, what Fusion-native or replacement provides). (3) Data extraction plan (ISV-specific data outside core Sage 300 SQL — Orchid Document Management storage, Pacific Banks reconciliation history). (4) Replacement decision (Fusion-native / equivalent Fusion ISV / retire as redundant). (5) Replacement functionality validation in parallel-run. (6) Partner notification (sent 90+ days before cutover sunset date). (7) Final data extraction (completed and reconciled before cutover). (8) Contract exit confirmation (signed by ISV partner, billing cessation confirmed).
Crystal Reports section of a sage 300 migration checklist runs 7 items: (1) Crystal Reports library crawl (every .rpt file, every report on Crystal Reports Server, every report embedded in Sage 300 menus). (2) Usage signal capture (run frequency from Crystal logs, last-run dates, modifying-user identity). (3) Business-value classification (statutory / board / AR aging / AP cheque / sales / inventory / project billing / payroll). (4) Replacement strategy decision per report (OTBI / BI Publisher / Smart View / retire). (5) Critical-report replacement rebuild prioritisation (statutory financials and audit-required reports first). (6) Replacement validation against Crystal output (rebuilt report matches Crystal report data and presentation). (7) Cutover sign-off for replacement reports live in production. Approximately 50–70% of Crystal reports retire across this section; only 30–50% rebuild.
Cutover orchestration uses the sage 300 migration checklist as the runbook. Pre-cutover (T-7 days): final dress rehearsal completed, ISV partners notified of sunset date, integration partners notified of endpoint switch, user communications sent, steering committee approves cutover. Cutover quiesce (T=0): every company database placed in read-only mode, application servers stopped, log shipping completed. Final delta (T+0–6 hr): per-company final delta extracts, hash-signed manifests, source SQL cross-checked. Final load (T+4–18 hr): FBDI payloads emitted, Fusion ESS loads monitored, row-level reconciliation. Reconciliation + sign-off (T+12–30 hr): per-company reconciliation packs signed, consolidated sign-off. ISV + integration (T+24–48 hr): ISV partners sunset, integration touchpoints re-pointed. Go-live validation (T+24–72 hr): smoke tests, operational validation, T+24 sign-off.
Yes — the sage 300 migration checklist is a working artifact, not a fixed template. Every Sage 300 estate carries its own particular footprint, and the checklist for a given programme is shaped during the assessment phase based on the per-company database inventory, customisation inventory, Crystal Reports library, ISV partner inventory, integration touchpoint map and compliance jurisdiction map. The 60+ item baseline checklist is the starting point — customer-specific items get added (specific ISV partners the customer uses, specific compliance jurisdictions the customer operates in, specific integration touchpoints the customer maintains). The result is a customer-specific working checklist that is referenced at every steering committee, every parallel-run review, and every cutover dress rehearsal — not filed away as a deliverable and forgotten.
Syntra ETL's assessment phase produces a customer-specific 60+ item sage 300 migration checklist tailored to your per-company database inventory, customisation footprint, Crystal Reports library, ISV partner profile, integration touchpoints and compliance jurisdictions. Used as the runbook — not filed and forgotten.