Microsoft DynamicsFree calculatorPDF, Excel, Word exportMicrosoft Dynamics 365 Finance and Supply Chain Management

D365 Data Migration Cutover Duration Calculator

A cutover plan lives or dies on the data load estimate. This calculator converts row counts and measured throughput into hours, adds error rework and reconciliation, and compares the total with your downtime window.

Your numbers

rows

Sum across all entities: customers, vendors, items, open orders, balances.

rows/min

Measured in a mock load, per import thread.

6 threads
70 %
%
hours

Balance tie-outs, count checks, sign-off.

hours

Final extract, configuration switches, user access, smoke tests.

hours

Your results

Total cutover duration
18 hrs
Slack against window (negative means overrun)
30 hrs
Effective threads
4.5
Initial load time
8 hrs
Error rework time
1 hrs
Reload cost is doubled to include analysis and correction effort.
Window used
38.2%

A planning estimate. Dependencies between entities force some loads to run in sequence, so parallelism is rarely perfect. Always base throughput on a timed mock cutover.

Save results:

Cutover duration vs import threads

Sweeps Parallel import threads from 1 to 24, holding your other inputs fixed.

Source data quality profiling

Optional: an expert profiles your legacy ERP data to predict migration error rates before mock loads.

Optional. The tool and every export work without this. No spam.

How to use it

Add up rows for every entity in the cutover load, including open balances and open transactions. Use the throughput measured in your last mock cutover per thread, then set the thread count and an efficiency that reflects entity dependencies. Enter reconciliation and other task hours from the cutover runbook. If slack is negative or under 20 percent of the window, plan more mocks, trim history or loosen the dependency order.

How the estimate is built

Load time is rows divided by the throughput of the effective threads. Rework is the share of rows needing correction times load time, doubled to account for investigation. Reconciliation and fixed tasks are added as flat hours. Because entities have dependencies, such as items before open purchase orders, the effective thread count is deliberately lower than the thread count.

  • Effective threads = 1 + (threads - 1) x efficiency
  • Load hours = rows / (rows per minute x effective threads) / 60
  • Total = load + rework + reconciliation + other tasks

Reducing the window

Migrate static data such as customers, vendors and items ahead of go-live and load only deltas during the window. Cut history to what the business needs. Run mock cutovers at production volume and track the timings per entity so the plan improves each time. Validate that data is clean in earlier mocks, because error rework is the most volatile part.

Common mistakes

Extrapolating from a small test load, ignoring the time to extract and transform source data, and leaving no time for rollback decisions all shorten the plan on paper only. Agree a go/no-go checkpoint partway through the window. Keep a record of actual versus estimated hours after each rehearsal so you can recalibrate efficiency and error rate.

Frequently Asked Questions

What throughput should I assume?

Do not assume. Time a mock load for each major entity, because rates vary a lot between simple master data and entities with many validations or number sequences. Use the slowest realistic figure for the plan.

How many mock cutovers are typical?

Most projects run at least two or three full-volume rehearsals. Each should be timed, reconciled and followed by a lessons review, so the final estimate is built on measured numbers.

Does this cover data transformation?

Not by default. Add extract and transform time to other cutover tasks if those steps run inside the downtime window. Preparing transformed files in advance is a better approach.

What if the total exceeds the window?

Options include loading static data earlier, delta loading, increasing parallelism where entities allow it, trimming history, or lengthening the window with business agreement.

If you need help profiling legacy ERP data quality before the mock loads, Netray can run read-only analysis on the source data with your migration team.