The Manufacturing ERP Implementation Checklist

ERP implementations do not usually fail because the software was wrong. They fail because the customer’s side of the project was never really staffed, the data arrived dirty, the scope grew without anyone pricing the growth, and go-live was declared on a calendar date instead of an acceptance test. All of that is preventable, and most of it is preventable before the kickoff meeting. This checklist walks through a manufacturing ERP implementation phase by phase, using the five-phase structure Cortrova runs deployments on - discovery and planning, data migration, configuration and AI calibration, training, and validated go-live - because the phases generalize to any vendor, even when the timeline does not. Cortrova targets a typical 4-8 weeks by running the phases in parallel where dependencies allow; a traditional sequential project covers the same ground over a longer arc. Either way, the work below is yours to do, and no vendor can do it for you.

Before kickoff: the work that decides the project

The highest-leverage weeks of an implementation happen before it officially starts. Walk into kickoff with these done:

• Name an internal project owner with real authority. One person, not a committee, with the standing to make decisions between steering meetings and the calendar space to actually run the project. An implementation whose owner does it “alongside the day job” has already scheduled its own delay.
• Assign a data owner per domain. Every master data domain needs a named owner accountable for its accuracy at migration time: items and BOMs (usually engineering), routings and work centers (production), suppliers and open POs (purchasing), customers and open orders (sales), on-hand balances (inventory), and the chart of accounts (finance). “The team” owns nothing; names own things.
• Document your top workflows as they actually run. Not the procedure binder version - the real version, exceptions included. Ten to fifteen workflows is usually enough: order entry to promise date, work order release to completion, receiving inspection, nonconformance handling, month-end close.
• Decide what you are NOT bringing. More on migration scope below, but the principle starts now: an implementation is the one chance to shed a decade of accumulated data debt, and the decision to shed it must be made deliberately, before someone migrates it by default.
• Freeze other major changes. A plant that is simultaneously moving buildings, changing its part numbering scheme, and implementing an ERP is running three projects with one staff. Sequence them.

If you are still selecting a vendor, the manufacturing ERP buyer’s guide covers how to evaluate implementation risk before you sign; this article assumes the contract is done and the clock is running.

Phase 1: Discovery and planning

This phase turns the sales-cycle understanding into an executable plan. Verify the following leave the phase in writing:

• A scope document listing every module going live, every integration being built, and every workflow being configured, signed by both sides. Anything not on this list is a change, and changes get priced and scheduled, not absorbed.
• An integration inventory. List every system the ERP must exchange data with - payroll, CAD/PLM, shipping carriers, customer portals, any equipment or MES layer staying in place - and for each one: the direction of data flow, the trigger (real-time or batch), the owner on your side, and the test that proves it works. Interfaces discovered in week six are the classic source of the month-long slip.
• A decision log with named decision-makers and a committed turnaround time for open questions. Most schedule slip is not work taking long; it is questions waiting for answers.
• The go-live date, chosen against your production calendar. Never cut over during your seasonal peak, your fiscal year-end close, or a major customer audit.

Phase 2: Data migration

Data is where implementations go to die quietly. The system goes live on schedule and nobody trusts it, because the balances were wrong on day one. The checklist:

• Scope the migration explicitly. Master data (items, BOMs, routings, suppliers, customers) migrates. Open transactions (open POs, open sales orders, open work orders, current on-hand) migrate. Closed history is the deliberate decision: migrating years of transaction history multiplies cleanup effort for records nobody will query, while keeping the legacy system readable in an archive usually covers the audit need. Decide per domain, in writing.
• Clean before you move, not after. Duplicate part numbers, BOMs that no longer match the floor, suppliers that went out of business, routings with steps nobody performs - migrating them launders bad data into a new system with a credibility it has not earned. The data owners named before kickoff run this cleanup in the legacy system or in the extract, on a schedule with the same status visibility as the vendor’s tasks.
• Count before you trust. On-hand balances deserve a physical inventory or a tight cycle-count program before cutover, because the new system inherits whatever accuracy you give it. A platform can support strong inventory accuracy practices going forward, but it cannot retroactively fix the opening balance.
• Run at least one full rehearsal migration. Extract, transform, load, and validate the complete dataset into a test environment, then have the data owners - not the vendor - sign off on record counts, spot checks, and a trial transaction against migrated data. The rehearsal is also your only honest estimate of how long cutover weekend will take.

Phase 3: Configuration and AI calibration

Configuration maps your documented workflows onto the system: order types, routing templates, approval chains, quality plans, and document structures in the documents module or its equivalent. Two disciplines keep this phase honest:

• Configure to the documented workflow, then challenge the workflow. The system should fit how you work, but implementation is also the moment to stop doing things a 1998 system forced on you. Every “we’ve always done it that way” gets one question: would we design it this way today?
• Resist customization; prefer configuration. Custom code is scope you pay for now and upgrade risk you pay for forever. If a requirement genuinely cannot be met by configuration, log it as a formal change with its lifetime cost attached.

On an AI-native platform this phase includes calibration: pointing embedded agents at your migrated data, setting their permission boundaries and approval gates, and validating their outputs against your team’s judgment before granting any autonomy. Governance settings - who approves what, which actions require a human, what gets logged - are configuration, not defaults to accept. Treat the agent permission review with the same seriousness as the user role review, and verify both against how the platform’s implementation approach says they should be set.

Phase 4: Training

Training fails when it is a webinar in week one that everyone has forgotten by cutover. The checklist:

• Train by role, on your data, close to go-live. A scheduler needs three hours deep in the scheduling module with your real routings; the same person needs ten minutes on modules they will never open. Generic curriculum on sample data produces people who can pass a quiz and cannot process Monday’s orders.
• Build super-users, deliberately. Pick one respected person per department, involve them from the configuration phase, and make them the first line of support after go-live. Floor adoption follows the shift lead, not the memo.
• Train the exceptions, not just the happy path. Receiving a partial shipment, reworking a rejected lot, correcting a mis-issued material: the first week of live operation is made of exceptions, and that is exactly what the training must rehearse.
• Verify competence, not attendance. The exit test for training is each role completing its real transactions unassisted in the test environment. Sign-in sheets prove nothing.

Phase 5: Validated go-live

The single most protective idea in this article: go-live is an acceptance test, not a date. Define, in writing and in advance, the criteria the system must pass before cutover is declared:

• Migrated data validated and signed off by each data owner.
• Every integration on the inventory tested end to end with production credentials.
• Each role’s core transactions completed unassisted in the test environment.
• A cutover runbook with a timed sequence, named owners per step, and an explicit rollback plan if validation fails mid-cutover.
• Extra support coverage committed for the first weeks, with the vendor’s escalation path in writing.

Then hold the line: if the criteria are not met, the date moves. A slipped week is recoverable; a floor that learns in week one that the system cannot be trusted is not, because they will rebuild the spreadsheets and never come back.

The failure modes, named

Nearly every troubled implementation traces to a handful of causes: no internal owner with real authority, dirty data migrated on the theory it would be fixed later, scope that grew without being repriced, training done early and generically, integrations discovered late, and a go-live declared by the calendar rather than by acceptance criteria. Every item on this checklist exists because one of those killed a project somewhere. The cost side of these failure modes - change orders, the parallel-systems period, the price of a long project - is covered in our companion piece on manufacturing ERP cost structures.

A well-run implementation is not heroic. It is named owners, clean data, written scope, role-based training, and a cutover you validated before you declared it. Do the unglamorous work in the checklist and the go-live becomes what it should be: quiet.