Purpose-built ETL platform for dynamics gp to oracle fusion migration — GL, AP, AR, Inventory, SOP, POP. SQL Server-direct extractors, multi-company orchestration, ISV add-on inventory, Dexterity/VBA assessment, 40–60% faster than consultant-led programmes.
Most GP-to-Fusion projects don't slip in the SQL extract. They slip in multi-company normalisation, Dexterity/VBA inventory, ISV decommission planning and SmartList rebuild.
Microsoft Dynamics GP — still widely known by its original Great Plains name — has been the workhorse small and mid-market ERP for tens of thousands of US distributors, non-profits, services firms and light manufacturers for two decades. Customers carry deep customisation: Dexterity .dic dictionaries with custom post logic, dozens of Modifier-altered windows, VBA event handlers tied to specific forms, hundreds of SmartList Builder queries and a fleet of ISV add-ons from Mekorma, Greenshades, Integrity Data and Rockton. Consultant-led migrations spend the first three months just cataloguing what exists across all the company databases.
Syntra ETL inverts the sequence. Pre-built GP extractors that read directly from SQL Server (with optional eConnect or Web Services for GP transport where corporate security policy requires it) mean week-one extraction across every company DB. A discovery engine that crawls the DYNAMICS system database to enumerate companies, then walks every customisation table (Modifier resources, VBA project metadata, SmartList Builder definitions, Dexterity dictionary inventories, active ISV product schemas) produces a complete customisation inventory in days. The dynamics gp to oracle fusion migration conversation that traditionally consumes a quarter now happens in week two with hard evidence on the table.
Whether you are moving a single-company GP installation, a 12-company multi-entity consolidation, or a hybrid where GP Payroll stays on Greenshades while financials migrate to Fusion, the same engine handles the workflow — with the same reconciliation rigor and the same audit trail evidence pack.
And how the Syntra ETL platform addresses each one — before they consume your timeline.
GP's multi-company pattern means one SQL Server database per company plus the shared DYNAMICS system DB. Syntra ETL enumerates company DBs from DYNAMICS, parallelises extraction with consistent watermarks, and partitions Fusion FBDI payloads per BU.
GP's account framework can vary across company DBs — segment count and segment width are not always identical. Crosswalks normalise to the unified Fusion 6-segment COA and surface inconsistencies for finance sign-off before load.
Dexterity is a near-extinct skill, but the .dic dictionaries, Modifier-altered windows and VBA event handlers still drive critical business logic. Discovery inventories every customisation, classifies by business purpose, recommends Fusion equivalents (DFF, AMX, OTBI).
Hundreds of SmartList Builder queries don't translate. Inventory, classification, OTBI/BI Publisher rebuild plan. 30–50% typically retired during the cleanup; critical ones rebuilt before go-live.
Mekorma, Greenshades, Integrity Data, Rockton, Encore — partner-built add-ons with their own schemas and data footprints. Inventory + Fusion-native replacement plan + sequenced decommission alongside GP cutover.
Mainstream support ended September 2025; extended support runs through April 2031. Customers waiting for 'one more version' are waiting for a release that isn't coming. Migration sequencing aligns with the Modern Lifecycle clock.
A repeatable, governed workflow built for Great Plains' particular complexity. Typical full-scope timeline: 12–18 weeks.
Discovery engine enumerates company DBs from DYNAMICS, catalogs every active table by row count and history depth, walks Dexterity dictionaries, Modifier resources, VBA project metadata, SmartList Builder definitions and ISV add-on schemas. Output: complete customisation inventory, ISV decommission map, sized assessment with risk register.
Account framework crosswalks (per company DB, with segment-width and segment-count reconciliation), vendor/customer cleanse, item master rationalisation, ISV-to-Fusion functional mapping, Dexterity/VBA retire-or-replace decisions. Reviewed and signed off by finance, AP, AR, ops and IT leads.
GP SQL Server extractors pull GL, AP, AR, Inventory, SOP, POP, Fixed Assets, Bank Rec, Project, Payroll across every company DB. Output staged as Parquet, partitioned by fiscal year, company and document type with hash-signed manifests. Optional eConnect or Web Services transport where security policy requires.
Crosswalks applied, multi-company normalisation, FBDI Journal/AP/AR/Receipt/PO/Item payloads generated, validated against Fusion 26x templates. Errors surfaced locally with row-level diagnostics — not at runtime in a 4-hour Fusion ESS job.
FBDI ZIPs submitted to Fusion ESS, monitored to completion, reconciled at row, sum and hash level per company. In parallel, critical SmartList Builder reports rebuilt in Fusion OTBI/BI Publisher and validated against GP equivalents. ISV decommission sequencing finalised.
1–2 fiscal-period cycles in parallel (GP + Fusion), deltas captured and replayed, reconciled to the cent per company, sign-off pack issued. GP moves to read-only archive mode; new transactions flow to Fusion only. ISV add-ons sunsetted on schedule.
No more bespoke SQL clients or eConnect scaffolding. Just configure scope, run, reconcile.
GL00100 account master, GL10001 open trx, GL30000 posted history, budgets, allocations, recurring batches. Pulled across every active company DB with watermarks. Routed to Fusion GL via FBDI Journal Import.
PM00200 vendor master, voucher headers and distributions, payment history, 1099 history. Multi-company vendor de-duplication during transform; loaded via FBDI Supplier and AP Invoice Import.
RM00101 customer master, open invoices, cash receipts, RM apply history, customer statements. Routed to Fusion Customer Import and AR Invoice Import with full apply history preserved.
IV00101 item master, site quantities, cost layers; SOP10100/SOP10200 sales orders open and detail; POP10100/POP10110 purchase orders open and detail. Loaded via Fusion Item, SO and PO FBDI templates.
Fixed Asset master, book history, depreciation, transfers; Bank Reconciliation transactions and statement detail. Routed to Fusion Assets and Cash Management FBDI.
Dexterity dictionaries, Modifier resources, VBA project metadata, SmartList Builder definitions, ISV add-on schemas — exported and classified, feeds the discovery-classification-rebuild loop without manual screenshots.
A typical dynamics gp to oracle fusion migration covering GL, AP, AR, Inventory, SOP and POP, with 10+ years of GP history across 3–6 company databases, runs 12–18 weeks with Syntra ETL versus 9–14 months on consultant-led projects. Single-module work (GL-only consolidation, for example) completes in 6–8 weeks. The acceleration comes from pre-built Great Plains extractors that already understand the one-DB-per-company SQL Server pattern, governed crosswalks between GP account framework segments and Fusion 6-segment COA, and ISV inventory tooling that maps Mekorma, Greenshades, Integrity Data and similar add-on artifacts. Multi-entity GP shops with five-plus company databases routinely add 2–4 weeks for parallel reconciliation across companies.
Microsoft has put GP into maintenance mode. Mainstream support for Dynamics GP 2018 R2 ended in September 2025; extended support runs through April 2031 under Modern Lifecycle Policy. There are no new GP versions planned after the 18.x line — Microsoft is steering customers to Business Central. For an SMB or mid-market that has outgrown GP, dynamics gp to oracle fusion migration delivers an enterprise-grade GL, multi-org consolidation, modern UX, embedded AI, and an active product roadmap. Customers acquired by Oracle-standardised parents commonly migrate as part of the M&A integration. Others move because Dexterity developers are vanishing, ISV add-on partners are sunsetting products, or because GP's one-DB-per-company architecture has become a multi-entity reporting nightmare.
Syntra ETL supports the full GP footprint. General Ledger: account master (GL00100), open trx (GL10001), posted trx history (GL30000), budgets, allocations and recurring batches. Payables Management: vendor master (PM00200), 1099 history, open and historical voucher detail. Receivables Management: customer master (RM00101), open/historical invoices, cash receipts, RM apply history. Inventory Control: item master (IV00101), site quantities, cost layers. Sales Order Processing: SOP10100/SOP10200 open and detail, SOP30200/SOP30300 history. Purchase Order Processing: POP10100/POP10110 open and detail, POP30100/POP30110 history. Plus Fixed Assets, Bank Reconciliation, Project Accounting, Payroll (US/Canadian), Field Service and Manufacturing where licensed.
Great Plains' multi-company pattern — one SQL Server database per company, plus the shared system database DYNAMICS for users and security — is one of the things that makes dynamics gp to oracle fusion migration uniquely awkward for consultant-led teams. Syntra ETL's GP extractor connects to the DYNAMICS system database first to enumerate active company DBs (TWO, FAB1, customer-specific codes), then parallelises extraction across companies with consistent watermarks per table. The transform layer normalises company-specific account framework variations into the Fusion COA, applies inter-company elimination rules where applicable, and emits FBDI payloads partitioned by Fusion BU so multi-entity consolidation works cleanly on the Fusion side from day one.
Dexterity is a niche skill — Microsoft's proprietary scripting language for GP customizations — and Modifier/VBA event handlers add another layer. None of it translates 1:1 to Oracle Fusion. What Syntra ETL does is inventory every active Dexterity dictionary (.dic file), every Modifier-altered window, every VBA event handler and every SmartList Builder custom report in the source GP installation, classify each by business purpose (auto-populate field, override post logic, custom validation, custom report), and produce a Fusion-equivalent recommendation: Fusion DFF + value-set, Fusion Approval Management Extensions (AMX) flow, OTBI analysis or BI Publisher report. 30–50% of GP customisations typically turn out to be redundant under Fusion's native capability and are retired during the migration.
GP's partner-built ISV ecosystem is sizeable: Mekorma for AP payments and check printing, Greenshades for payroll/tax filings, Integrity Data for payroll add-ons, Rockton Software for utilities, Encore Business Solutions for various add-ons. Many of these vendors have already announced sunsetting of GP products in line with Microsoft's lifecycle. Syntra ETL's assessment inventories every active ISV add-on, its data footprint inside the GP databases, and its functional purpose. The dynamics gp to oracle fusion migration plan maps each to a Fusion-native equivalent (Fusion AP Payments for Mekorma, Fusion Payroll or third-party payroll integration for Greenshades), preserves any historical transaction data the ISV produced, and sequences the ISV decommission alongside the GP cutover.
SmartList Builder reports are the lifeblood of day-to-day GP operations — finance, AP, AR and ops teams have built hundreds of custom queries over a decade of use, and they don't translate to Fusion. Syntra ETL inventories every SmartList Builder query in the GP installation via the SmartList Builder metadata tables, classifies by business value (daily operational query, monthly close report, ad-hoc audit lookup), and produces a Fusion replacement plan: OTBI analyses for ad-hoc query needs, BI Publisher reports for pixel-perfect operational output (1099s, vendor history, customer statements), Smart View for Excel-tethered analysis. The critical SmartLists get rebuilt in Fusion during the migration so go-live includes the reporting layer, not just the data.
No. Syntra ETL's GP extractors run as a read-only SQL Server login with SELECT permissions on the GP system and company databases — no schema modifications, no triggers, no replication. Extracts are throttled to off-peak windows and use read-only snapshot isolation so they don't block GP's posting routines. The Dexterity runtime is untouched. Live GP operations continue uninterrupted throughout the extract, transform and validation phases. The cutover itself is a defined moment — GP moved to read-only after final close, new transactions filed in Fusion — typically scheduled for a fiscal period close-out so the natural cycle break gives breathing room.
Book a 30-minute discovery call. We'll walk through your GP company DBs, Dexterity/VBA inventory, SmartList footprint and ISV add-on stack — and give you a concrete timeline and budget before the call ends.