ERP Migration & SelectionFree calculatorPDF, Excel, Word export

ERP Mock Data Load Rehearsal Planner: How Many Mock Loads Do You Need?

Nobody gets a clean data load first time. The usual question is how many mock loads you need before the cutover. This planner uses throughput, cycle time and an error-reduction assumption to show the reject count you can expect and whether the load fits the weekend.

Your numbers

records

All master and open transaction records across objects.

records/hour

Measured end to end, including validations and sequencing waits.

hours
hours
%
50 %

How much of the remaining errors you fix before the next mock.

3 loads
hours

Your results

Total rehearsal elapsed time
108 hrs
Expected rejected records at last mock
37,500
Load duration per run
6 hrs
Hours per mock cycle
36 hrs
Expected reject rate at the last mock
1.25
Percent of records rejected.
Share of cutover window used by the load
12.5%

Assumes a constant percentage of errors is fixed between mocks. Measure your actual throughput on a production-sized volume.

Save results:

Expected rejected records by number of mock loads

Sweeps Number of mock loads from 1 to 8, holding your other inputs fixed.

Need help with data cleansing before the mock?

An optional review of your migration approach and reject patterns.

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

How to use it

Count records for every object in scope, including open transactions such as open sales orders, purchase orders, work orders and balances. Measure throughput from a real trial, not the vendor's quoted rate. Enter the validation and fix time between cycles, the reject rate on the first mock and how much of that rate you usually eliminate by the next one. Vary the number of mock loads to see rejects and elapsed time trade off.

  • Measure throughput at production volume
  • Include open transactions, not just masters
  • Add validation and reconciliation time
  • Plan at least one full-volume dress rehearsal

The calculations

Load duration = records / throughput. Cycle time = load + validation + fix. Rehearsal elapsed time = cycle time x number of mocks. The reject rate after n mocks is the first rate x (1 - reduction) to the power n - 1, a geometric improvement. Rejected records = total records x that rate. Window use = load duration / available cutover window. If window use is above about seventy percent, tune throughput or split the load into phases.

Reading the result

The chart shows diminishing returns: the first extra mock removes the most errors, later ones remove fewer in absolute terms. Pick the number of mocks where the expected rejects are small enough for the cutover team to fix by hand in the window. Add a mock if the final rejects still need more than a few hours of manual correction, or if reconciliation to the source ledger still shows differences.

Common mistakes

Teams plan mocks with sample data and then find production volume doubles the load time. Others skip reconciliation, so a load looks clean but balances do not tie. A third mistake is treating the improvement rate as fixed when new extraction logic or mapping changes can reset it.

  • Using sample volumes for timing
  • No balance reconciliation per mock
  • Assuming errors fall at the same rate every time
  • Letting the last mock happen too close to cutover

Frequently Asked Questions

How many mock loads are typical?

Three is a common minimum and complex programs use four or more, including a full-volume dress rehearsal. The right number depends on the reject trend and reconciliation results, not a fixed rule.

What is an acceptable reject rate?

It depends on the object. Master data should reach near zero rejects, while history or low-value transactions may tolerate a small agreed number. Define the threshold per object in the migration plan.

Why measure throughput at full volume?

Load time often grows faster than volume because of index maintenance, locking, number range handling and validation lookups. A small sample can mislead the cutover timeline significantly.

What if the load does not fit the window?

Options include loading static masters earlier, using delta loads for changing data, running objects in parallel where dependencies allow, or tuning indexes and batch sizes. Rehearse the new approach before relying on it.

If you want AI-assisted mapping checks and reject analysis over your source and target data, kept entirely on your own infrastructure, Netray can build that.