What is a parallel run in an ERP migration?

Running the new ERP system and the legacy system side by side against the same live transactions for a defined period, before cutting over fully, so that discrepancies surface while the legacy system is still available as a source of truth to compare against.

Why does the close simulation depend on the parallel run instead of running independently?

Because a close simulation is only meaningful with real transactional volume behind it. A close simulation run against test data or a partial period tells you the process works mechanically, not that it produces correct numbers; that requires the parallel run's real transactions to actually be in the system by the time the close simulation happens.

What dependency type models this relationship correctly?

Finish-to-Finish, not Finish-to-Start. The two activities can run for overlapping periods. The parallel run doesn't have to fully complete before close-simulation work begins, such as preparing the close process or setting up reconciliation reports, but the close simulation can't be marked *finished* until the parallel run is also finished, because that's what makes its numbers real rather than provisional.

How long does a parallel run need to be?

Long enough to span at least one complete month-end close, not a fixed number of weeks picked in isolation. A parallel run that stops short of a close cycle never actually tests the one process an ERP migration is most likely to get wrong on the first real attempt.

What goes wrong if this gate is skipped or modeled as unrelated tasks?

The close simulation gets marked complete on schedule regardless of what the parallel run actually found, and a completed-looking checklist item hides a genuine unresolved question: whether the new system's numbers match reality under a real close. That gap surfaces at the first live close after go-live instead, which is a far more expensive place to find it.

Guides / ERP Data Migration Timeline: The Parallel-Run and Close-Simulation Gate

ERP Data Migration Timeline: The Parallel-Run and Close-Simulation Gate

The one judgment call generic ERP migration checklists never make: when does the parallel run actually prove the new system is ready to close the books on.

By Vishal Gungah, Project delivery professional

Most ERP migration checklists list "parallel run" and "close simulation" as two separate line items, each with its own checkbox. Treating them as independent tasks misses the one relationship between them that actually matters: the close simulation's result is only trustworthy once the parallel run has produced real numbers to test it against.

What a parallel run is actually for

A parallel run means operating the new ERP alongside the legacy system against the same live transactions for a defined window, so any discrepancy shows up while the legacy system is still there to compare against. It is expensive: it means double-entry, double-reconciliation, and real people's time spent running two systems instead of one, which is exactly why it's tempting to compress it or treat it as a formality once go-live pressure builds.

Why the close simulation can't run on its own

A month-end close simulation tested against clean test data, or against a partial period, proves the mechanics work: the process can be executed, the reports generate, the steps complete in order. It does not prove the numbers are right, because that requires closing against transactions the parallel run actually produced. A close simulation scheduled to finish before the parallel run has generated enough real activity to close against isn't testing anything real yet; it's rehearsing a process against numbers nobody has verified.

The dependency type that gets this right

This is a Finish-to-Finish relationship, not Finish-to-Start. The two activities can genuinely overlap: close-simulation preparation, setting up reconciliation reports, building the close checklist, none of that needs to wait for the parallel run to be complete. What can't happen early is the close simulation being marked done. That has to land no earlier than the parallel run's own finish, because the parallel run is what supplies the real numbers the close simulation is meant to validate. See the dependency types guide for how Finish-to-Finish compares to the other three link types GanttFlow supports.

GanttFlow's ERP implementation template models exactly this: the parallel run against the legacy system carries a Finish-to-Finish link into the month-end close simulation. Delete that link on your own copy and the close simulation can slide earlier on the chart without anything flagging that its numbers are no longer backed by a completed parallel run, which is precisely the gap this dependency exists to prevent.

Sizing the parallel run correctly

A parallel run measured in an arbitrary number of weeks, rather than in close cycles, routinely undershoots the one test that matters most. A parallel run has to span at least one genuine month-end close to be worth running at all; anything shorter tests day-to-day transaction processing without ever exercising the close process a business actually depends on the ERP to get right.

What this looks like when it goes wrong

The failure mode isn't dramatic: it's a checklist that reads as complete. Close simulation: done. Parallel run: done. Both checked off on schedule, with no visible sign that the close simulation's numbers were never actually reconciled against a completed parallel run. The gap surfaces at the first real month-end close after go-live, which is the most expensive place an ERP migration can discover a numbers problem, with real financial reporting obligations attached instead of a project milestone.

Applying this beyond ERP

The same shape, a validation step that's only meaningful once a longer-running parallel process has actually finished, shows up anywhere a new system is being proven against a live comparison baseline before cutover, not just in ERP finance modules. If a migration in progress has a verification step that keeps getting marked complete ahead of the data it's meant to verify, a Finish-to-Finish link is usually the fix, not a schedule compression.

Start free See pricing

Common questions

What is a parallel run in an ERP migration?: Running the new ERP system and the legacy system side by side against the same live transactions for a defined period, before cutting over fully, so that discrepancies surface while the legacy system is still available as a source of truth to compare against.
Why does the close simulation depend on the parallel run instead of running independently?: Because a close simulation is only meaningful with real transactional volume behind it. A close simulation run against test data or a partial period tells you the process works mechanically, not that it produces correct numbers; that requires the parallel run's real transactions to actually be in the system by the time the close simulation happens.
What dependency type models this relationship correctly?: Finish-to-Finish, not Finish-to-Start. The two activities can run for overlapping periods. The parallel run doesn't have to fully complete before close-simulation work begins, such as preparing the close process or setting up reconciliation reports, but the close simulation can't be marked *finished* until the parallel run is also finished, because that's what makes its numbers real rather than provisional.
How long does a parallel run need to be?: Long enough to span at least one complete month-end close, not a fixed number of weeks picked in isolation. A parallel run that stops short of a close cycle never actually tests the one process an ERP migration is most likely to get wrong on the first real attempt.
What goes wrong if this gate is skipped or modeled as unrelated tasks?: The close simulation gets marked complete on schedule regardless of what the parallel run actually found, and a completed-looking checklist item hides a genuine unresolved question: whether the new system's numbers match reality under a real close. That gap surfaces at the first live close after go-live instead, which is a far more expensive place to find it.