Microsoft Dynamics GP Migration Cutover Strategy — Multi-Company, Phased, Defensible

A dynamics gp migration cutover is the orchestrated moment when Microsoft Dynamics GP stops being the operational system of record and Oracle Fusion takes over. The work covers final-period close in GP across every company database, final delta extracts with consistent watermarks across companies, FBDI load of every delta into Fusion, end-to-end reconciliation per company per BU per period to the cent, formal signoff from finance, AP, AR and ops leads, hard cutover of users to Fusion, GP databases moved to read-only archive mode, and final ISV add-on decommission sequencing (Mekorma, Greenshades, Integrity Data). Typical full-company cutover window is 48–72 hours over a weekend; phased cutover by company DB stretches over 4–8 weeks depending on entity count.

Two patterns. Big-bang cutover: every GP company database cuts to Fusion at the same moment. Lower coordination overhead during steady-state, but higher cutover-weekend risk and harder rollback. Phased cutover: companies cut to Fusion one or two at a time over 4–8 weeks. Hybrid coexistence integration runs during the phased window — GP companies not yet cut continue posting locally, with subledger-to-GL feeds rolling up into Fusion. Most multi-company GP customers choose phased cutover because it spreads risk and lets the cutover team build muscle memory on smaller entities before tackling the largest ones. Syntra ETL's dynamics gp migration cutover platform supports both patterns natively.

At the moment of cutover, every GP company database is quiesced — no new postings, no batch jobs, no user activity. The standard sequence: (1) all users logged out of GP and Web Services for GP, (2) any in-flight eConnect batches drained or rolled back, (3) the Process Server stopped, (4) the SQL Server database set to read-only via ALTER DATABASE for each company DB plus DYNAMICS. The dynamics gp migration cutover runbook captures the exact sequence, the responsible owner per step, and the validation checks per step. Once read-only is confirmed, the final delta extract runs against a stable image of every company DB and the FBDI load to Fusion proceeds without race conditions.

GP ISV add-ons — Mekorma for AP payments and check printing, Greenshades for payroll/tax filings, Integrity Data for payroll add-ons, Rockton utilities, Encore add-ons — each have their own decommission sequence. Some have their own SQL Server objects that need to remain queryable for audit (Mekorma payment history, Greenshades W-2 history); some have annual subscription contracts that need to lapse at the right moment; some have data that needs to migrate to a Fusion-native equivalent (Mekorma payment data → Fusion AP Payments, Greenshades payroll → Fusion Payroll or successor third-party). The dynamics gp migration cutover plan includes a per-ISV decommission sequence with contract end dates, data preservation strategy, and Fusion-equivalent go-live dates.

Two-tier rollback. Tier 1 (low-impact rollback during cutover weekend): if the cutover validation pack reveals a critical issue, GP databases are restored from read-only mode to read-write, the FBDI load to Fusion is voided, users continue in GP, cutover is rescheduled. Tier 1 rollback is feasible up to 72 hours post-cutover. Tier 2 (post-go-live rollback): after Monday-morning go-live, full rollback becomes operationally complex because new Fusion-only transactions exist. The dynamics gp migration cutover plan instead provides a 'forward-fix' path — keep Fusion live, address the issue via correction journals and master-data fix, and document the residual variance in the reconciliation pack. Rollback drills are run during parallel-run weeks so the team has rehearsed the Tier 1 path.

For a single-company GP installation with moderate footprint (GL + AP + AR + IV, 5–7 years of history), cutover window is 24–48 hours over a weekend. For a 3–6 company multi-entity installation, big-bang cutover is 48–72 hours; phased cutover stretches over 4–8 weeks with each company taking a single weekend. The dynamics gp migration cutover window is dominated by three things: final delta extract per company (typically 4–8 hours), FBDI load to Fusion plus ESS processing (6–12 hours), and end-to-end reconciliation per BU per period to the cent (8–16 hours). Validation buffer time is built in so the team can address last-mile reconciliation variances before Monday-morning go-live.

Every dynamics gp migration cutover ends with a signed reconciliation pack: per-company GP trial balance vs Fusion trial balance per period to the cent, AP aging GP vs Fusion vendor by vendor, AR aging GP vs Fusion customer by customer, inventory on-hand by site, fixed asset NBV by class, bank rec reconciled bank balance by account. The pack is signed by finance lead, AP lead, AR lead, ops lead and IT lead — and retained for the full SOX/IRS/HMRC window. The dynamics gp migration cutover audit trail also captures every step of the runbook with timestamps, responsible owner and validation evidence — so when external auditors ask for cutover documentation, the answer is a single signed PDF, not a frantic reconstruction.

Post-cutover, GP company databases are moved to read-only archive mode via ALTER DATABASE SET READ_ONLY. They remain queryable for any operational lookup (historical voucher detail, customer statements pre-Fusion) for 90–180 days, then are migrated to Syntra ETL's long-term cloud archive for the remainder of the IRS/HMRC/SOX retention window. The GP application runtime (Dexterity, eConnect, Process Server) is shut down once the read-only window closes, freeing the SQL Server licence and the application server infrastructure. ISV add-on contracts (Mekorma, Greenshades, Integrity Data) lapse on their pre-planned dates. Total infrastructure cost savings post-cutover are typically £40–120K/year for a mid-sized multi-company GP installation.