A phased ERP rollout: deciding what goes live first
Choose the first ERP release using workflow dependencies, usable scope, acceptance criteria, and a practical recovery plan.
On this page
A phased ERP rollout should move a complete, usable slice of work into the new system. Choose that slice by examining dependencies and business readiness. Starting with the smallest module is not useful if staff still cannot complete the task it supports.
Map the dependencies first
For a proposed sales-order release, list customer records, items, pricing, stock visibility, permissions, reporting, and any downstream invoicing connection. Identify what must be live, what can remain in another system temporarily, and how the boundary will be reconciled.
A boundary creates operating work. Someone must own any temporary export, reconciliation, or duplicate entry that the phased approach introduces.
Define a release contract
| Decision | What to document |
|---|---|
| Scope | The workflows and user groups included |
| Exclusions | Work that remains in the old process |
| Data cutover | Which records move and when |
| Acceptance | The business evidence required for launch |
| Support | Who handles first-use problems |
| Recovery | The conditions and method for restoring service |
Assign a decision owner for readiness. A list of completed configuration tasks is not equivalent to business acceptance.

Pilot with representative work
Use ordinary transactions and difficult exceptions. A pilot group should represent the actual roles and conditions of the release, including someone who did not build the configuration.
In a hypothetical rollout, one branch tests order entry and stock visibility before wider adoption. Its test set includes a missing item, a returned order, and an unavailable approver. Record problems and resolve the release blockers before copying the setup to other branches.
Plan the point of no simple return
Before live transactions begin, document how new records would be reconciled if the launch were reversed. A database restore alone may lose work performed since the backup. Assign responsibility for preserving and replaying that work where necessary.
ERPNext's data import documentation is relevant to preparing records, but migration tooling does not replace a cutover and reconciliation plan.
Expand based on evidence
Review support demand, completed workflows, data differences, and user feedback. Decide whether to stabilize the current phase or start the next one. Avoid expanding simply because a calendar date has arrived.
Prepare one release contract and a sample acceptance test before discussing an ERP rollout. It makes the proposed first phase concrete enough to estimate and challenge.