An ERP implementation plan that starts before configuration

Give every process an owner

Name a sponsor who can resolve scope conflicts, and an owner for each end-to-end process. Record current exceptions and decide which ones must be preserved. Do not start configuration with an unprioritized wish list. Separate launch-critical requirements from improvements that can wait until the business is stable.

Prove the data path early

Load a small, representative dataset before migrating the full history. Test item units, BOM revisions, opening stock, customer balances and open orders. Keep the original export and a transformation log. Reconcile counts and values, and have the relevant business owners sign off the results.

Rehearse cutover and recovery

A cutover plan needs a transaction freeze, final extracts, validation steps, named owners and a decision time. Rehearse it with realistic volumes. Decide in advance which failures stop launch and how operations continue if the new system is unavailable. A backup is useful only when the team can restore and reconcile it.

Define what happens after launch

Publish support hours, escalation paths and responsibility for each integration. Track defects separately from new feature requests. Set a review cadence for stock, work in progress and financial balances until the process is stable. Evaluate any promised implementation timeline against your scope and readiness; a vendor headline is not your project schedule.

Choose a first release that can close a complete loop

A phase should have a useful operating boundary. Launching purchasing without reliable receiving or inventory ownership can leave the business reconciling two incomplete truths. Define which order types, sites and entities enter the first release and which stay elsewhere. Describe how transactions cross that temporary boundary and how it will eventually be removed. A narrow end-to-end scope can be safer than deploying isolated modules across every location at once. Ask the sponsor to approve explicit exclusions and the consequences for reports. Maintain a dependency map linking process decisions, data, integrations and user training so a late item is assessed against its downstream impact.

Make process decisions before configuration hardens

Maintain a decision log with the question, options, owner, selected approach and reason. Typical decisions include when ownership changes, how substitutions are approved and when a customer order becomes firm demand. Set an escalation date for unresolved launch-critical choices. Avoid silently rebuilding the old system's screens when a simpler process would work, but do not remove an exception merely because a demonstration did not include it. Have operators explain what the exception protects. Where a customization is proposed, compare configuration, process change and extension costs including future maintenance. The decision is ready when the business owner can describe both ordinary processing and correction.

Train on the work people must recover

Use role-based exercises with migrated data rather than presentations organized by menu. A receiver should practice an overdelivery, a damaged carton and the reversal of a wrong receipt. A planner should handle a late component; finance should investigate the resulting valuation. Measure whether the person completes the task and recognizes when to escalate. Keep job aids short enough to use during a shift. Provide a training environment with realistic permissions so superuser access does not mask design gaps. Track coverage by shift and backup role, including people who miss the first session. Training completion is useful evidence only when the critical tasks can actually be performed.

Rehearse with a clock and a reconciliation pack

Illustrative example: a plant has a 30-hour weekend window. Reserve time for extraction, transformations, loading, validation, a business decision and recovery before the first shift. These timings are planning inputs, not a recommended universal window. Run a rehearsal and measure the slowest steps. Inventory counts and open-order amendments may take longer than the file transfer. Retain source totals and signed reconciliation worksheets for each load. Define a last safe decision time: waiting until operators arrive to discover a failed migration removes useful options. Microsoft publishes a Dynamics 365 go-live checklist covering migration, acceptance and support readiness; use its product context appropriately rather than presenting it as a universal certification.

Put launch authority with the business

Write stop conditions in measurable language. Examples include an unexplained stock-value difference, missing tracking identifiers for active lots, inability to print required shipping documents or an integration queue that cannot recover. Assign who diagnoses each condition and who decides whether the business can operate with a documented workaround. Distinguish a cosmetic defect from an incorrect posting. A launch meeting should examine evidence and remaining risk, not vote on optimism. If the decision is to delay, preserve the tested configuration and update the plan with the new transaction boundary. If proceeding, publish the accepted limitations, workaround owner and expiration date so temporary measures do not become invisible permanent work.

Stabilize before expanding

Use a small set of operational checks after launch: unposted transactions, unexplained inventory movements, work-in-progress balances, failed interfaces and aged support tickets. Compare them to the agreed operating expectations. Run the first close with the same finance owners who accepted migration, and retain the reconciliation bridge. Set exit conditions for intensive support rather than selecting an arbitrary calendar date. Transfer configuration records, deployment instructions and known issues to the support team. Only then prioritize the next phase using observed bottlenecks. The practical deliverables are a scope boundary, decision log, test evidence, timed cutover runbook and support ownership map; a project schedule alone cannot substitute for them.

Common questions

Continue your research

The following profiles provide a starting point for checking vendor-described scope. Inclusion is not a ranking or a statement that every requirement is supported.