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

> Source: https://netray.co/tools/erp-mock-data-load-rehearsal-planner
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate load time, rehearsal effort and the expected reject rate after each mock load, and check the load fits your cutover window.

## Category

erp-migration

## Audience

- Data migration lead
- ERP project manager
- Cutover manager

## Tool

**Kind:** calculator

**Inputs:**

#### Total records to load

**Key:** total_records

**Type:** number

**Default:** 3000000

**Min:** 1

**Step:** 10000

**Unit:** records

**Help:** All master and open transaction records across objects.

#### Effective load throughput

**Key:** load_rate

**Type:** number

**Default:** 500000

**Min:** 1

**Step:** 10000

**Unit:** records/hour

**Help:** Measured end to end, including validations and sequencing waits.

#### Validation and reconciliation per cycle

**Key:** validate_hours

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 1

**Unit:** hours

#### Fix and extract-rerun time between cycles

**Key:** fix_hours

**Type:** number

**Default:** 24

**Min:** 0

**Step:** 1

**Unit:** hours

#### Reject rate on mock load 1

**Key:** first_err

**Type:** number

**Default:** 5

**Min:** 0

**Max:** 100

**Step:** 0.5

**Unit:** %

#### Reject rate reduction per extra mock

**Key:** improve

**Type:** slider

**Default:** 50

**Min:** 0

**Max:** 90

**Step:** 5

**Unit:** %

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

#### Number of mock loads

**Key:** mock_loads

**Type:** slider

**Default:** 3

**Min:** 1

**Max:** 8

**Step:** 1

**Unit:** loads

#### Cutover window available for the load

**Key:** window_hours

**Type:** number

**Default:** 48

**Min:** 1

**Step:** 1

**Unit:** hours

**Outputs:**

#### Load duration per run

**Key:** load_hours

**Expr:** total_records / load_rate

**Format:** hours

#### Hours per mock cycle

**Key:** cycle_hours

**Expr:** load_hours + validate_hours + fix_hours

**Format:** hours

#### Total rehearsal elapsed time

**Key:** rehearsal_hours

**Expr:** cycle_hours * mock_loads

**Format:** hours

**Primary:** true

#### Expected reject rate at the last mock

**Key:** final_err

**Expr:** first_err * pow(1 - improve / 100, mock_loads - 1)

**Format:** decimal

**Description:** Percent of records rejected.

#### Expected rejected records at last mock

**Key:** final_rejects

**Expr:** total_records * final_err / 100

**Format:** integer

**Primary:** true

#### Share of cutover window used by the load

**Key:** window_use

**Expr:** load_hours / window_hours * 100

**Format:** percent

**Chart:**

#### Expected rejected records by number of mock loads

**Type:** bar

**X:** mock_loads

**From:** 1

**To:** 8

**Steps:** 8

**Series:**

- final_rejects

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

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Cta:** 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.

**Faq:**

#### How many mock loads are typical?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

erp mock data load, mock load rehearsal plan, data migration mock cycles, how many mock loads erp, cutover load time estimate, data migration reject rate, erp trial conversion, data load rehearsal

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json