Planning an ERP cutover: switching in controlled stages

Clarify dependencies before the cutover date

A combined cutover requires master data, open transactions, integrations and users to be ready for the intended scope. A missing prerequisite needs an explicit decision on launch, limited scope or postponement.

Switching in stages means one clearly bounded area goes live and is checked in agreed operating conditions before the next follows. Timing, dependencies and the fallback plan are set for the project. This helps contain risks; it does not guarantee a disruption-free switch.

Which area goes first

Choose an area with clear benefit and manageable dependencies. Whether purchasing, inventory or another workflow fits first depends on data, integrations and available owners.

What goes first is decided by your processes, not by a general recommendation. That is exactly what the setup check is for.

What running two systems really costs

Maintaining two systems at once is expensive and error-prone, so the phase should be short and clearly bounded. It makes sense where an area still needs figures from the old system, open items across a month-end for instance.

The important part is deciding in advance which system leads during that time. Without that decision you get two versions of the truth, and cleaning that up costs more than the switch itself.

Check the fallback before launch

Before each stage, assess which data state can be restored, who decides and how newly created transactions are handled. The fallback needs rehearsal; its duration should not be assumed without testing.

Make a go/no-go decision before each cutover.

A cutover plan needs a defined data state, an owner for the final reconciliation and the point from which new transactions enter the target system. Existing open orders and integrations need an unambiguous assignment.

Before launch, check agreed quantities or totals, a representative end-to-end workflow and failure handling. Define which discrepancy stops launch and who decides on approval or postponement. Criteria need to be set before cutover time pressure.

A backup is not yet a tested fallback. Frappe restore documentation distinguishes database and file archives and notes version constraints. The project needs to establish which state can actually be restored and how business transactions created since then will be handled.

After switching, assess errors, reconciliation and support ownership during an agreed observation period. Parallel maintenance needs a clear boundary. Stages can contain risks; timing, downtime and recovery remain dependent on the specific plan and its rehearsal.

Frappe: restore and version constraints · Migration with validated data · Define the first implementation stage

A cutover plan with an explicit decision.

Before switching, record the last entry in the old system, final export state, authoritative system afterwards, permitted interruption and sign-off owner. Define which integrations pause and when they may resume sending.

Illustrative scenario, not a client case: an order arrives after the final export. The plan must determine where it is recorded and how reconciliation includes it. Restoring the old backup alone would not account correctly for that new transaction.

Postpone launch when an agreed stop criterion is met, such as an unresolved stock discrepancy or an untested recovery path. Recovery time and acceptable data loss need tests and operational requirements, rather than a blanket zero-downtime promise.