An ERP Implementation Checklist Without the Vendor Spin

What most checklists get wrong

Vendor checklists are organised around go-live, because go-live is when the implementation is delivered and invoiced. That is a reasonable milestone for the vendor and the wrong one for you.

Your milestone is three months later: the month-end that closes on time, in the new system, without a spreadsheet propping it up. Everything below is ordered toward that instead.

Before you choose a system

1. Write down the five processes that most need to work. Not a feature list — processes, end to end, in your own words. Quote to cash. Purchase to pay. Month-end close.
2. For each, note what currently breaks. This becomes your acceptance criteria, and it is far more useful than any requirements matrix.
3. Decide what you will not do in year one. The scope you exclude now is the only scope you will successfully exclude later.
4. Name an internal owner with the authority to decide. Not a committee.
5. Demo against your own processes, with your own data, not the vendor's script. Ask to see the five processes above, performed.

Data: the part that slips

Data migration is the most underestimated line in every implementation, and it is underestimated for a structural reason: the work is not moving the data, it is deciding what is true.

Start it before configuration, not after. It runs longer than you expect and it surfaces decisions that configuration depends on.

• Extract each master file — customers, suppliers, items, chart of accounts — and count the duplicates. The number is always higher than anyone expects.
• Decide the rule for each merge before merging. Which spelling, which address, which credit limit wins.
• Standardise units of measure across the item master. Cable in metres, reels and boxes is three items pretending to be one.
• Decide how much transactional history to bring. Open items always; closed history rarely earns its cost. Keep the old system readable instead.
• Agree the opening balance date and freeze changes to it. Migrating against a moving balance is a reconciliation you will run forever.

Load the data at least twice before cutover. The first load finds the format errors; the second finds the meaning errors, which are the ones that matter.

Scope discipline

Almost every overrun traces to the same move: customising the system to preserve an existing process rather than changing the process.

Sometimes that is correct — a genuinely differentiating process is worth keeping. Usually it is not, and the process being preserved is simply the shape of the last system's limitations.

A test that cuts through it: ask what the customisation is worth in money. If the answer is a feeling rather than a figure, adopt the standard process. Customisations are paid for twice — once to build, and again at every upgrade, forever.

Choosing a cutover

Parallel running sounds safest and is the one most often abandoned halfway, because entering everything twice is punishing and the second entry quietly stops. A parallel run that is not actually parallel is worse than no parallel run: it produces false confidence.

For most small businesses big bang over a quiet weekend, with the old system left readable, is the pragmatic answer. Pick the date against your own calendar — never month-end, never your busiest season, and not the week your controller is away.

Training

Training delivered three weeks before go-live is forgotten by go-live. Deliver it in the last week, and deliver it as the person's actual job rather than as a tour of the software.

Train on your migrated data, not the demo set. People learn the system through recognisable records, and testing with real data catches migration errors that no checklist finds.

Write the ten most common tasks down as one-page instructions. Not a manual — a page each, with the actual screens. This is the artefact people use at go-live, and nobody regrets having made it.

Testing that finds things

Most implementation testing is a demonstration rather than a test: someone walks the happy path, it works, the box is ticked. Then the system meets a part-shipment against a part-paid order and nobody has seen that before.

Testing that finds problems has three properties. It uses your migrated data rather than a demo set. It is performed by the people who will do the job, not by the project team. And it deliberately includes the cases that go wrong.

Write test scripts as real scenarios with expected outcomes, not as feature lists:

• A customer orders 100, you ship 60, invoice 60, then ship the rest next month. Does the order close correctly, and does the ledger agree at each step?
• A supplier delivers 10% over, the warehouse accepts it, the invoice matches the delivery not the order. Who approves it, and what does the variance report show?
• A customer pays an invoice twice. Where does the overpayment sit, and can it be applied to the next invoice?
• A credit note is raised against an invoice that was already part-paid.
• An item is returned after the period closed. Which period does the reversal land in?
• A new starter joins on the 18th and leaves on the 29th of the following month.

Every one of those will happen in your first quarter. Finding them in testing costs an afternoon; finding them live costs a reconciliation and somebody's confidence in the system.

The first month is part of the project

The most common structural error is treating go-live as the end. The vendor demobilises, the internal team returns to their day jobs, and the first month-end arrives with nobody assigned to it.

1. Keep the project team in place through the first full close.
2. Run the first month-end as a rehearsed exercise, with the old system available for comparison.
3. Reconcile every control account to its subledger in month one, and investigate every difference however small.
4. Keep a log of workarounds. Each is either a training gap or a configuration gap; both are fixable, and neither is if nobody wrote them down.
5. Declare done only after a close that needed no spreadsheet and no vendor call.