ERP Readiness Checklist: Evidence Before You Commit

An ERP readiness checklist asks whether your organization can make decisions, prepare reliable data, and give the project enough time and ownership to implement a system responsibly. It is different from an ERP requirements list, which describes what the software must do.

You can have a well-matched product and still have an unprepared project. Before committing to an implementation timetable, collect evidence in five areas: sponsorship, requirements, data, internal capacity, and process change. Use the gaps to shape the work plan. Counting check marks is not a prediction of success.

How to use this ERP readiness checklist

For each area below, record the evidence you have, the unanswered question, the person responsible, and the next action. A document title without an owner or a decision is weak evidence.

Use three working labels: evidenced, incomplete, and unknown. “Unknown” matters because it tells the team where discovery is needed. It should not be silently treated as “ready.”

Key takeaway

ERP readiness and ERP fit answer different questions. Fit asks whether the product covers your business needs. Readiness asks whether your team can define, deliver, and adopt the change.

Microsoft's implementation strategy guidance connects implementation decisions to business processes, ownership, and activities such as testing, migration, and training. The checklist below turns those planning concerns into concrete evidence requests for a mid-market team.

1. Sponsorship: who can make a binding project decision?

Ask for a named executive sponsor, a decision process, and a way to resolve disagreements across departments.

A useful test is a disputed requirement. Suppose operations wants an additional workflow that increases delivery effort while finance wants to protect the go-live date. Who can decide, what information do they need, and where is the decision recorded?

• ▪Evidence: a sponsor who has accepted the role, a steering meeting cadence, and an escalation path.
• ▪Common gap: everyone supports the project, but nobody owns decisions that change scope or timing.
• ▪Next action: give one real unresolved decision to the proposed process and see whether it produces a clear outcome.

Sponsorship is more than approving a budget. It includes making tradeoffs and protecting the time of the people the implementation depends on.

2. Requirements: can the team describe an acceptable result?

Write requirements as business outcomes with observable evidence. “Better reporting” is difficult to test. “The controller can reconcile the consolidated balance sheet to entity balances and investigate differences” gives the demonstration and testing teams something concrete to examine.

Identify what belongs in the first release and what can wait. Include a short list of requirements that could change the product choice, rather than giving every preference the same priority.

• ▪Evidence: process owners, a prioritized scope, sample inputs, and expected outputs.
• ▪Common gap: a long feature spreadsheet filled with “yes,” with no agreement about the business process.
• ▪Next action: walk a critical transaction from its source to the final operational or financial report.

In its ERP evaluation guidance, SAP cautions that generic feature checklists can hide meaningful differences and recommends tailoring evaluation to the business. Our practical extension is to attach an example and an owner to each important requirement.

3. Data: can you explain what will move and reconcile it?

List the records that must move: master data, opening balances, open transactions, and any history the business needs in the new system. Then identify the source and the person who can judge whether each category is correct.

Different records need different checks. For a vendor file, you might examine duplicates and required fields. For opening balances, you need an agreed reconciliation. For open sales orders, you need to establish how partially fulfilled or partially billed records will be represented.

• ▪Evidence: a migration inventory, sample extracts, field mappings, reconciliation criteria, and named data owners.
• ▪Common gap: a successful export is treated as proof that migration is ready.
• ▪Next action: run a small representative sample through the intended process, including exceptions, and reconcile the result.

Key takeaway

Exporting data proves that a source can produce a file. Migration readiness also requires decisions about mapping, cleanup, ownership, and how the result will be reconciled.

Do not schedule the last meaningful reconciliation for the final cutover weekend. An early sample can reveal a scope or interpretation problem while there is still time to change the plan.

4. Capacity and budget: is the internal work accounted for?

A proposal may describe the implementation partner's hours while saying little about the customer's work. Your team still needs to answer design questions, clean data, test, learn new workflows, and support colleagues.

Ask each process owner to identify the work they will perform and the existing responsibilities that compete for that time. Consider month-end, year-end, inventory counts, audits, and seasonal peaks when planning availability.

• ▪Evidence: an internal work plan, named backups, funding assumptions, and a list of costs outside the software subscription.
• ▪Common gap: the project is staffed with people who have no time allocated away from their normal jobs.
• ▪Next action: review the proposed calendar with the actual team and resolve the largest conflicts.

There is no universal safe ratio of partner hours to internal hours. The useful question is whether the necessary work has an owner and a plausible place in the calendar.

5. Process change: can people perform the new work?

Training attendance is not the same as being able to complete the job. Identify the roles that change and the tasks each role needs to perform.

For a purchasing workflow, for example, have the requester create a transaction, the approver review an exception, and finance inspect the resulting record. Include the situation where the normal approver is unavailable.

• ▪Evidence: role-based practice scenarios, business acceptance criteria, support ownership, and a process for unresolved issues.
• ▪Common gap: testing checks configuration but does not involve the people who will run the process.
• ▪Next action: have users perform representative work and record the point at which they need help.

Microsoft's test-planning guidance recommends defining test outcomes and responsibilities and involving the business in approval. Your readiness work should identify who will provide that approval and what evidence they need.

Turn the checklist into a decision memo

Keep the first memo short enough for the sponsor to use. State the business outcome, the proposed first release, the evidence collected, and the gaps that could change cost, scope, or timing.

For each gap, specify an owner, a next action, and the point at which the decision must be revisited. Some gaps can be resolved during discovery. Others may justify a narrower first release or a later implementation start.

Key takeaway

A useful readiness output is an owned work list: what remains unknown, who will resolve it, and which project decision depends on the answer.

If the software shortlist is still uncertain, use the fit assessment. If the product direction is clearer and preparation is the question, use the readiness questionnaire. The published methodology explains the scoring and its limits.

ERP readiness questions

When should we assess ERP readiness?

Start while you are defining the project, before an implementation timetable becomes a firm commitment. Revisit material gaps when scope, staffing, data assumptions, or the intended go-live date changes.

Does a high readiness score guarantee success?

No. A score summarizes the inputs and assumptions of a model. It cannot guarantee the quality of execution, data, partner delivery, or future decisions.

Do we need perfect data before starting?

You need enough evidence to understand the work and its risks. Some cleanup can happen during implementation. The concern is committing to timing without knowing who will resolve the material issues or how the migrated result will be checked.