A time-boxed 60–72 hour microsoft dynamics nav migration cutover. Period-end timing, NAV Server quiesce, partner add-on sunset, banking/EDI/statutory endpoint switch, opening-balance reconciliation, NAV read-only transition, Fusion go-live, hyper-care. Every step owned, timed and signed.
It is not the load. The load runs on automation. The hard part is the simultaneity — partner add-ons, banking endpoints, statutory submission points and operational user populations all switching together in a 60-72 hour window with no slack.
NAV cutover is unusual among ERP migrations because the surface area is so large. A NAV deployment isn't just SQL Server and an RTC client — it is a constellation: NAV Server (or NAS in older versions), partner add-ons each with their own integrations (Anveo edi, ChargeLogic vault, Continia document hub, Insight Works mobile), Jet Reports Excel templates on finance laptops, EDI feeds from trading partners through NAV, banking files through NAV, statutory submission endpoints through NAV (UK MTD bridging tool, German GoBD GDPdU export, Italian SdI gateway, EU SAF-T per-country submissions), payroll feeds for the local payroll bureau. Every one of those connections has to be severed cleanly at the cutover moment and re-established on the Fusion side without losing transactions in flight.
Syntra ETL's microsoft dynamics nav migration cutover playbook treats this as an orchestration problem. Every connection has an explicit owner. Every endpoint switch has an explicit sequence. Every potential rollback point has explicit criteria. The cutover runbook is signed off at dress-rehearsal stage two weeks before the real cutover weekend — and the dress rehearsal runs against production data on a parallel Fusion environment, so by the time the real cutover happens, every step has already been executed once.
Whether the cutover is a single-company NAV 2016 site in a German factory, a multi-region NAV 2018 estate across UK, Ireland and France, or a Navision-era database merging into a multi-company Fusion ledger — the same orchestration discipline runs, the same runbook structure applies, the same dress-rehearsal-then-real sequence executes.
Each stage has an explicit owner, an explicit duration window, an explicit success criterion and an explicit rollback criterion.
NAV period-end close runs as normal: final-day postings, period-end accruals, FX revaluation, intercompany. Post-close balances are the cutover snapshot. Owner: NAV finance lead.
NAV Server quiesce: RTC sessions terminated gracefully, web-service and OData requests rejected, scheduled jobs drained, NAS shut down, database read-only. Owner: NAV IT lead.
Full SQL Server extract against the quiesced database. Manifest signed and hash-stamped. Output partitioned by company and fiscal year. Owner: Syntra ETL platform.
Final delta replay into Fusion via FBDI + REST. Opening-balance reconciliation runs immediately. Pass criterion: zero delta in LCY/ACY at G/L Account + period level.
Banking, EDI, payroll, statutory submission endpoints switch from NAV to Fusion at controlled moments. Each switch has owner + rollback path.
Fusion sanity test with operations sample users, NAV moves to read-only archive mode, go-live announced, hyper-care command centre stays open for 2 weeks.
A typical 60–72 hour cutover window. Friday 18:00 to Monday 06:00 local time. Every hour accounted for, every step owned.
NAV final-day postings complete. Period-end accruals and FX revaluation run. Intercompany reconciliations close. Period-end balances locked. Cutover command centre opens.
Partner add-ons sunset per vendor playbook. NAV Server quiesce sequence executes — RTC sessions warned and terminated, web-service and OData rejected, scheduled jobs drained, database transitioned to read-only. Final SQL Server extract starts.
Extract complete with hash-signed manifest. Delta replay into Fusion begins via FBDI + REST. Opening-balance reconciliation runs in parallel for each company in scope.
Opening-balance reconciliation pages signed by finance and audit leads. Rollback gate passed — migration commits to go-live. In-flight transaction validation runs. Document-chain spot-check executed.
Banking, EDI, payroll, statutory submission endpoints switched from NAV to Fusion. Fusion sanity test with operations sample users. NAV transitioned to read-only archive mode.
Fusion go-live announced to all users. Hyper-care command centre starts 2-week window. Daily standup with finance, operations and IT for first week. Microsoft dynamics nav migration cutover sign-off signed.
Each one a real failure seen on consultant-led NAV → Fusion cutovers — and the runbook discipline that prevents it.
Without period-end timing discipline, cutover lands mid-period, dual close required, statutory submissions complicated. Runbook standardises period-end timing as non-negotiable.
Without strict NAV Server quiesce, NAV continues to take transactions during the final extract, the extracted dataset is inconsistent, post-load reconciliation fails.
Without partner add-on sunset playbook, ChargeLogic vault or Continia document hub keeps writing to NAV after quiesce, data divergence accumulates.
Without explicit endpoint-switch sequencing, banking files stop flowing Sunday night, payments don't go out Monday morning, vendor escalation cascades.
Without explicit rollback criteria, an opening-balance variance turns into a multi-day investigation while Fusion is already live to users, no clean revert path.
Without a dedicated cutover command centre with named ownership, Sunday-night issues route to whoever's email is checked first, response times collapse.
Microsoft dynamics nav migration cutover is the orchestrated, time-boxed moment when NAV stops being the operational system of record and Oracle Fusion takes over. It is not a single event but a tightly choreographed weekend (or long weekend, or three-day window depending on scope) covering: NAV final-day operations, NAV Server quiesce, final SQL Server extract, delta replay into Fusion, opening-balance reconciliation to the cent, NAV transition to read-only archive mode, Fusion go-live to operations users, banking and EDI cutover, statutory-submission point handover, partner add-on sunsetting, and the cutover sign-off ceremony. Done right it is uneventful. Done wrong it dominates Monday morning across finance, operations and IT.
Period-end timing is non-negotiable. Cutover on a mid-period date forces dual-system close for the cutover period, which inflates the finance burden and complicates statutory submissions. The microsoft dynamics nav migration cutover playbook standardises on the closing weekend of a fiscal period — typically the last weekend of a calendar month for monthly closers, or the last weekend of a quarter for quarterly closers. For multi-jurisdiction estates, the cutover weekend respects the jurisdiction with the earliest statutory submission deadline (Italian SdI day-1 obligations, French SAF-T deadlines, German GoBD digital-records cut-off). For seasonal businesses, the cutover weekend avoids peak shipping windows (no retailer cuts over the weekend before Black Friday).
A typical full-scope microsoft dynamics nav migration cutover is a 60–72 hour window — Friday 18:00 local time NAV close, through Monday 06:00 local time Fusion go-live. Friday evening: NAV final operations end-of-day, NAV Server quiesce, final extract starts. Saturday: full extract completes, delta replay into Fusion, opening-balance reconciliation runs. Sunday morning: opening-balance sign-off, in-flight transaction validation, banking and EDI endpoint switch. Sunday evening: Fusion sanity testing with operations sample users, statutory-submission endpoint switch, NAV moves to read-only archive mode. Monday morning: Fusion go-live to all users, hyper-care support starts, command centre stays open.
NAV Server (the middle-tier service for NAV 2009 RTC and later) is quiesced cleanly at the start of the cutover window: incoming web-service and OData requests rejected with a maintenance message, RTC client sessions warned and terminated gracefully, scheduled jobs (job queue entries) drained, NAV Application Server (if running) shut down, SQL Server database transitioned to read-only after the final commit. The quiesce sequence is documented in the cutover runbook with explicit timestamps for each step. Once NAV Server is quiesced, the final SQL Server extract runs against a stable snapshot — no concurrent writes — which means the extracted dataset is provably the cutover-moment state.
Partner add-ons (Anveo eCommerce/EDI, ChargeLogic credit-card processing, Continia OPplus/document-capture/expense, Insight Works WMS/manufacturing/shipping, LS Retail POS, Tasklet Factory mobile WMS, Mekorma cheque printing, regional specialists) each have their own sunsetting playbook. Add-ons being retired in favour of Fusion-native equivalents are switched off at NAV Server quiesce. Add-ons being replaced by a Fusion-side equivalent need an integration cutover step in the same window (e.g. Concur replacing Continia Expense at the same moment Fusion goes live). Add-ons being kept alongside Fusion need their NAV-side connection severed and a Fusion-side connection lit. Each decision is in the cutover runbook with explicit responsibility ownership.
Cutover on the last business day of a fiscal period is the gold standard: NAV closes the period as normal (final-day postings, period-end accruals, FX revaluation, intercompany), the post-close balances become the opening balance for Fusion, and the next period starts in Fusion with a clean boundary. The cutover runbook explicitly sequences NAV period-close before the final extract — the final extract captures the post-close state, not the in-period state. For multi-company estates the period-close runs per company in parallel; for multi-jurisdiction estates the period-close respects each jurisdiction's regulatory deadlines for the cutover period (e.g. UK MTD for VAT submitted from NAV for the cutover quarter, then SaaS pipeline switches to Fusion for the following quarter).
A signed, time-boxed runbook with: per-step owner, per-step expected duration, per-step success criterion, per-step rollback criterion. Stages: pre-cutover dry run sign-off; NAV final operations end-of-day; partner add-on sunset sequence; banking/EDI/payroll endpoint pre-switch; NAV Server quiesce; final SQL extract + manifest signing; delta replay into Fusion; opening-balance reconciliation; in-flight transaction validation; document-chain spot-check; statutory submission endpoint switch; NAV read-only transition; Fusion sanity test; go-live announcement; hyper-care start. Every step has an owner name, a phone number, a Slack channel and a green/red criterion.
Rollback is on the table until the opening-balance reconciliation signs off. Up to that gate, NAV is in read-only mode but the database is preserved in full — re-enabling NAV writes is a configuration change, not a restore-from-backup operation. Banking, EDI and statutory endpoints can be reverted to NAV in minutes. After opening-balance sign-off, rollback transitions to forward-fix (any Fusion issue is fixed in Fusion, not by reverting). The microsoft dynamics nav migration cutover runbook documents the rollback criteria explicitly: a material opening-balance variance that cannot be explained in a defined time window triggers rollback; a successful opening-balance reconciliation triggers go-live commitment.
Book a 30-minute discovery call. We'll walk through your NAV Server topology, partner add-on inventory, banking and statutory endpoints, period-end calendar — and give you a concrete cutover-runbook outline before the call ends.