ERP implementation: from the first process to acceptance.

“We need a new ERP” describes a solution but not yet a business goal. Identify where information gets lost, tasks stall or the same data is entered repeatedly. Record who is affected and how an improvement could later be recognised.

An illustrative example: a service business wants to prevent confirmed orders from being left without an assigned project lead. The goal is a traceable transition from order to project delivery. A suitable test criterion is whether every approved order has an owner and a next task. This produces specific requirements for data, roles and status changes.

Record the starting situation before selecting features. Processing times, follow-up questions and manual handovers can support a later comparison. A target measure needs its own baseline measurement; generic efficiency promises do not replace it.

Choose a work item that delivers a usable result. An isolated entry form is not yet a productive process. In the example, order data, assignment, permission to take ownership and a visible next task belong together.

Separate necessary features from later additions. Necessary means what enables the agreed work item or prevents an unacceptable error. An extra report can wait if the team can manage its work without it. A useful report cannot compensate for missing access controls.

Describe exceptions too: what happens with an incomplete order, a deputy or a later change? Include these cases in acceptance if they matter for launch. Assess new requests separately for benefit, effort and impact on the agreed scope.

If the workflows do not yet fit an existing solution, our page on custom ERP developmentexplains which questions help define the first system's boundaries.

Ask potential systems to demonstrate your own sample work item. Check the same roles, data and exceptions. Document what already works, what will be configured and what requires extra development. This lets you compare the ability to do the work rather than presentations.

The requirements specification describes your needs. The agreed implementation specification then records how the chosen provider will meet them. What matters is that both sides understand the same workflow and acceptance criteria; the documents should do more than list features.

There are several ways to switch. A single cutover moves all affected areas on one date. A phased rollout can proceed by process, location or user group. A pilot first tests a limited use case. The right approach depends in part on whether handovers between the old and new systems can work reliably during the transition. SAP also describes these implementation strategies; this does not establish one model as universally better. Source: SAP, ERP implementation strategies.

A phased implementation needs an explicit rule stating which system is authoritative for which data at every stage. Otherwise, a smaller starting scope can create extra coordination work.

Data ownership and data quality

Create an inventory of the data you need: source, owner, relevant fields and desired target state. Separate master data such as customers and services from open work items and historical information. Not everything needs to move to the new system in the same form. Decide which data the work requires and how necessary history will remain accessible.

Review a representative export early. If you find duplicates, missing required fields or inconsistent numbers, agree a cleaning rule and an owner. The technical team can identify problematic data; the business must decide what is correct.

Test migration and changes before cutover

A successful import initially means only that the transfer ran technically. Also check that relationships, values and open work items are correct in the target system. Agree control totals or other suitable business checks and investigate discrepancies.

New data continues to arise in the legacy system during preparation. Record when work there stops and how changes since the trial export are transferred. Test the actual cutover procedure in advance. Microsoft explicitly includes repeated migration rehearsals and business approvals in launch preparation. Source: Microsoft, data migration and go-live checklist.

The following sequence connects data quality with the launch decision. Each step needs a verifiable result.

1. Select the data. Confirm sources, scope and owners.
2. Perform a trial migration. Apply mapping and cleaning rules.
3. Verify against business requirements. Document errors, correct them and test again.
4. Rehearse the cutover. Account for data changes, the available window and the decision to abort.
5. Approve production launch. Start only with confirmed checks and available support.

For interfaces, test more than a successful transfer. Check how failed transfers become visible, who handles them and how retries avoid unintended duplicates. Record test access and contact people at the providers involved.

For field mapping, test runs and reconciliation of open transactions, the guide to ERP migration includes a dedicated worksheet.

Name an owner and a deputy for each decision. The project lead coordinates dates and dependencies. Business owners decide on workflows and data. The technical team owns implementation and technical checks. Management resolves priorities, budgets and conflicts the project team cannot settle itself.

Involve future users early. They should perform important tasks themselves with the intended permissions. A successful test using an administrator account does not prove that daily work functions for the actual roles.

This matrix is a template for your project. Add specific names and agreed approval dates.

Area	Business owner	Evidence for approval
Workflow	Process owners	Normal and exception cases tested successfully
Data	Data owners	Migration and discrepancies reviewed by the business
Access & integration	IT together with the business team	Roles and interfaces tested, including error cases
Team & support	Business team with support	Tasks practised; help route and responsibilities known
Launch decision	Named decision maker	Open risks assessed; approval recorded

An open issue needs a description, an owner and a decision: resolve it before launch, start with an accepted limitation or postpone launch. Avoid a blanket approval that leaves critical problems hidden.

Check operational readiness against the agreed scope. Do the important workflows work with the intended data, users and integrations? Are the necessary tests documented? Does the team know how to report errors and who is available after launch?

Also agree a fallback procedure for cutover: who may abort launch, until when is that possible and how will work continue? What happens to data already created in the new system is particularly important. A backup alone does not answer these organisational questions. The procedure must fit your systems and the timing of the switch.

Training should happen before production use. Let users complete typical tasks themselves and record any difficulties in understanding. This feedback helps distinguish a technical error from an unclear workflow or a need for further training.

Derive dates from work packages, dependencies and available capacity. Extra development time cannot replace a missing business decision or test access. Reserve time for decisions, data checks and acceptance as firmly as you reserve technical implementation dates.

A smaller first version can bring initial production use closer. It does not automatically shorten the whole implementation. Additional stages also need tests, handovers and support. A realistic plan therefore distinguishes completion of the initial usable scope from later expansion.

For financial planning, consider provider services and internal effort together. Our guide to ERP costs shows how to record implementation and operating costs on a comparable basis.

Plan available contacts and a clear error-reporting route for the initial operating period. Separate failures within the agreed scope from new requests. Otherwise, stabilising operations competes with features that were not needed for launch.

Then review the goals you originally set. Does order handover work? Is the required data maintained? Which manual steps remain? Prioritise extensions based on these observations and assess their impact on workflows already in use.

Implementation of a defined scope ends with a clear handover. Further development begins on a tested foundation, with its own decision about benefit, effort and responsibility.