Phased Custom ERP Rollout: Choosing the First Working Release

Start the ERP rollout with one complete operational cycle: accept an order, reserve stock, dispatch and return the status to sales. The first release needs clear ownership and a working response to shortages, cancellations and interrupted exchanges.

Start with the business outcome, systems that remain and the people who can accept the result. This guide uses a fictional distributor to build a release boundary and a decision sheet. The ERP cost guide↗ explains how modules, source-specific work and operation fit into the budget; this article focuses on introducing the release into daily work.

01Choose one complete operational loop

For the distributor, the proposed pilot covers one warehouse and one operations team: accept an order, confirm availability, reserve stock, dispatch and show the status to sales. If an item is unavailable, an authorised operations owner decides whether to split or defer the order. A cancellation before dispatch releases the reservation.

The pilot includes the users and permissions needed for that loop, order and stock identifiers, exception ownership and an open-order report. It excludes supplier forecasting, production planning, extra warehouses and replacement of the accounting ledger.

Agree how to measure handling time, manual corrections and unresolved orders before the pilot. Use the same definitions during the observation period so that the decision to expand rests on comparable results.

02Assign stock ownership before and after the switch

Before the pilot, the existing warehouse system remains authoritative for stock. During a controlled rehearsal, the new system can read or mirror agreed data without directing live reservations. At the approved switch, one named system becomes the reservation authority for the pilot population.

Sales continues to own customer conversations. Operations owns fulfilment decisions. Accounting keeps posted entries and payments. Define where an amendment is permitted after an order has been accepted, and how the other systems learn the outcome.

Avoid a vague instruction to “run both systems in parallel”. Specify whether that means observation, reconciliation or live processing. Two independent live reservations for the same stock would invalidate the pilot. The CRM–ERP integration guide↗ explains field ownership and failed exchanges.

03Write the acceptance sheet before scheduling cutover

Proposed boundary for the fictional distributor. Passing the data checks alone does not approve the ownership switch.

1. 01Before the pilot

   The existing warehouse system controls live stock reservations. Sales and accounting continue in their current systems.

   Reconciled rehearsal data →
2. 02Rehearsal · read and compare

   The new system mirrors an agreed dataset. Check order IDs, quantities, exceptions and permissions; do not create a second live reservation.

   Approved evidence and cutover →
3. 03Approved pilot · one reservation authority

   After acceptance, the designated system owns reservations for the pilot population. Accept → reserve → dispatch → return status to sales.

Stays in existing systems

CRM keeps customer conversations. Accounting keeps posted entries and payments. Orders outside the pilot stay on the agreed existing route.

Deferred from this release

Additional warehouses, supplier forecasting, manufacturing and replacement of the accounting ledger. Assess dependencies before adding any of them.

Hold or recover

An untested critical scenario means hold. Recovery must reconcile orders and external actions created after the switch; reopening the old screen is insufficient.

Record the observed result, evidence and reviewer for each scenario, with a status of pass, fail or not run. For this distributor, the acceptance sheet includes:

1. Normal order: ten units available, four requested. Expect four reserved and six available, with one order reference shared across the agreed views.
2. Shortage: while that reservation remains active, request seven units. Expect the agreed shortage route; no silent over-allocation.
3. Cancellation: cancel the first order before dispatch. Expect availability to return to ten, while order history remains inspectable.
4. Interrupted handoff: lose the response after an order is saved. Retry and expect one destination order, with the unresolved exchange visible until confirmed.
5. Restricted role: attempt to open another operating team's protected order or export its details. Expect access to be denied across the agreed interfaces.
6. Report: compare open-order IDs and quantities with the same source cutoff. A matching headline count is insufficient if the underlying records differ.
7. Return after dispatch: ship four units, then receive one returned unit. Keep the original dispatch and record a linked return. The returned unit stays unavailable until the authorised warehouse inspection accepts it into sellable stock. Accounting decides any credit or refund separately; receiving the return must not automatically mark a refund as paid.
8. Partial fulfilment: use a separate order for ten units with six available. After an approved split, ship six, cancel two of the four remaining units, then replenish and ship the final two. Expect eight shipped, two cancelled and zero open; the cancellation must not release stock that was never reserved. Preserve each shipment and cancellation in the history.

The client operations owner accepts the business scenarios. The assigned technical lead supplies test evidence and documents unresolved defects. The person responsible for support demonstrates how a failed exchange is found and escalated. Use the migration rehearsal example↗ for record-level reconciliation, alongside these workflow checks.

Make the ERP pilot decision reviewable

Define the release boundary and test each required scenario. The filled decision example holds launch because the shortage check has not run.

• Pilot scope, exclusions and ownership transfer
• Eight acceptance scenarios with evidence fields
• Hold, launch, recovery and expansion decisions

Download the ERP pilot acceptance sheet↓

Editable text file (.txt)

Fill it in locally using a text editor or your own document. Share a non-confidential summary when you contact us.

04Separate a data pass from permission to launch

In the migration example, a repaired customer mapping makes three required orders reconcile. That is one gate. The pilot still needs its critical workflows, permissions, final source cutoff, recovery procedure and support access checked.

For a filled decision example, assume data and normal-order checks pass but the shortage scenario has not run. The decision is hold: the pilot cannot yet demonstrate how to avoid an incorrect reservation. The operations owner reviews the shortage rule, engineering runs the scenario and the evidence is reviewed again.

Record the conditions that block launch, the exceptions an authorised owner may accept and their consequences. This gives the release decision a clear basis and identifies the checks still required.

05Rehearse recovery around new work

Before switching, identify the last legacy snapshot and how changes after it are recorded. A recovery plan must account for new orders, reservations, dispatches and financial messages created during the pilot. Returning users to the old screen does not reverse those actions.

Name who can pause new intake, reconcile the pilot's changes and approve the recovery route. Record the constraints and test the procedure in an appropriate environment. Determine the maintenance window from those results rather than promising zero downtime in advance. Our mission-critical software guide↗ explains how recovery requirements shape that decision.

The reporting integration example↗ shows why orders, shipments and payments need different definitions during reconciliation. Use the same cutoff in each comparison and explain pending exchanges.

06Prepare the pilot team for ordinary work and exceptions

Select people who actually accept, pick and dispatch the pilot orders, including the person who covers an absent colleague. Give each role a short guide showing where to work, which decisions it can make and how to report a blocked order. Training should use the agreed pilot rules and a safe dataset.

Before launch, ask a representative user in each role to complete a normal order and its relevant exception without the trainer taking over. Record the result, any workaround and who will resolve it. If a required step cannot be completed independently, improve the process or guidance and repeat the check before releasing that part of the workflow.

At handover, the support owner should demonstrate how to find a failed exchange, identify the affected order and reach the operations decision-maker. Agree coverage hours, escalation contacts and who communicates with the pilot team during a disruption. Put unresolved training and support tasks in the same release decision record as technical gaps. The sample decision brief↗ provides a structure for agreeing the assessment's inputs and outputs before building the pilot.

07Agree the conditions for the next warehouse

Define the pilot observation period and its exit criteria before launch. Review real exceptions, staff completion of the workflow, reconciliation results and support's ability to respond. Any target numbers should come from agreed requirements and observed conditions.

If the pilot meets those criteria, assess the next warehouse's differences: identifiers, local stock rules, devices, permissions and operating hours. Expansion may need additional work even if the interface looks identical. If essential checks fail, hold the scope, fix and retest; use the rehearsed recovery route when its trigger is met.

Review our custom ERP development approach↗ and share the first operational loop you want to introduce↗. Include the current systems, pilot team, key exception and person who can approve the release.