The ERP selection checklist, before you sign anything.

01 / Requirements by department

One list per department, not one list from one person.

A requirements list built by finance alone misses what the warehouse depends on, and vice versa. Get each department that will actually use the system to answer its own section — then compare every vendor against all six, not just the one that wrote the RFP.

02 / Data ownership & export

Who owns the data once it's in the system.

This is the section vendors answer least specifically, which makes it the most worth pinning down before you sign — not after you need the answer.

1. ☐

   Who legally owns the data once it's in the system — us, or the vendor?

2. ☐

   Can we export a full, structured copy of our data at any time, not only at contract termination?

3. ☐

   What format does an export come in — a documented schema and a CSV or SQL dump, or a proprietary file only the vendor's own tools can read?

4. ☐

   Is there a public, documented API we can query directly, or does every integration have to route through the vendor?

5. ☐

   Does the vendor claim any rights to use our data — for benchmarking, model training, or aggregate reporting — and can we opt out in writing?

6. ☐

   If we ask for a full data export today, how long does the vendor say it takes — and is that written into the contract, or just a verbal answer?

03 / Hosting & SLA

Ask for a number, not a phrase.

"High availability" isn't a commitment; a published uptime percentage with a stated remedy is. Parsimony's own hosting facts — a 99.95% uptime SLA, US/EU/APAC regions, and daily encrypted backups — are published on /erpnext-hosting precisely so a business can compare them against the answers below from any other vendor.

1. ☐

   What is the published uptime SLA, as a number, not a phrase like “high availability”?

2. ☐

   What happens — credits, escalation, a named contact — if the SLA is missed?

3. ☐

   Where are the servers physically located, and does that match where our data is required to stay?

4. ☐

   Who takes backups, how often, and how long does a restore actually take once tested?

5. ☐

   Is our data on infrastructure shared with other customers, or a dedicated instance?

6. ☐

   Who patches and upgrades the system, and do we get advance notice before a version change?

7. ☐

   Is there a status page we can check independently of the vendor's own claims?

04 / Integrations

Ecommerce, shipping, payments, and EDI.

This is where a lot of ERP evaluations quietly fail: the demo covers accounting and inventory well, and nobody asks about the channels the business actually sells and ships through until after the contract is signed.

1. ☐

   Which ecommerce platforms does it connect to natively — Shopify, Amazon, WooCommerce, BigCommerce — and which need a third-party connector?

2. ☐

   Is order and inventory sync bidirectional, or does one system have to be treated as the source of truth by hand?

3. ☐

   Which shipping carriers and rate tools does it integrate with — UPS, FedEx, USPS, a multi-carrier tool — and is label printing native or bolted on?

4. ☐

   Which payment processors does it support out of the box — Stripe, PayPal, a merchant gateway — and does it reconcile deposits automatically against invoices?

5. ☐

   Does it support EDI documents — an 850 purchase order, an 856 advance ship notice, an 810 invoice — if a retail or wholesale customer requires them, and is that native or a paid add-on?

6. ☐

   If our integration isn't on the vendor's standard list, is there a documented API we — or a partner — can build against?

7. ☐

   Who owns an integration once it's built: the vendor, a partner, or does it become our responsibility after go-live?

8. ☐

   Are integrations tested against new releases before they ship, or do we find out what broke after an update?

05 / Implementation partner

Vet the partner, not only the software.

A poor implementation on great software fails the same way a good implementation on mediocre software succeeds differently — the partner running the project matters as much as the platform underneath it.

1. ☐

   How many implementations like ours — similar size, industry, module count — has this partner actually run?

2. ☐

   Who does the hands-on configuration: the person on the sales call, or a team we haven't met yet?

3. ☐

   What does the partner need from us, and by when, for the timeline they quoted to hold?

4. ☐

   Is training included, and does it cover the team that will use the system daily, not just an administrator?

5. ☐

   What happens if the go-live date slips — is there a defined change-order process, or does scope just expand quietly?

6. ☐

   Can we talk to a reference customer who went live in the last year, not just a logo on a website?

7. ☐

   Who supports us after go-live — the same team, or a different one under a different contract?

06 / Total cost

License, hosting, implementation, and per-user fees.

A quote with one number on it is rarely the number you'll actually pay in year one. Break it into the four pieces below before you compare vendors, because a lower license fee with an expensive implementation can cost more than the reverse.

1. ☐

   What is the license or subscription cost, and is it per user, per module, or a flat platform fee?

2. ☐

   Is hosting priced separately from the software, or bundled into one number?

3. ☐

   What does implementation cost, and is that a fixed quote or a time-and-materials estimate that can grow?

4. ☐

   Are there per-user fees that scale as we add employees, and is there a minimum seat count?

5. ☐

   What is not included in the quote — a specific module, an integration, training, data migration — that shows up as a separate line item later?

6. ☐

   Are there fees for API access, additional environments (a sandbox or test instance), or extra storage?

7. ☐

   What does a typical price increase look like at renewal, and is it capped in the contract?

8. ☐

   If we ask for a three-year total cost of ownership — license, hosting, implementation, and support — can the vendor produce one number, or only a first-year quote?

07 / Migration

What actually moves, and who's accountable if it doesn't.

Read the QuickBooks to ERPNext migration explainer for what one real migration path looks like end to end. These are the questions to ask any vendor about any migration, not just that one.

1. ☐

   What data actually moves — chart of accounts, item master, open transactions, historical records — and what gets left behind?

2. ☐

   Who does the data mapping: does the vendor map our old fields to the new system, or is that on us?

3. ☐

   Is there a parallel run or a trial close before cutover, so the two systems are validated side by side?

4. ☐

   What is the realistic go-live timeline, and does it match the answers already given under implementation partner, above?

5. ☐

   What happens to historical data that doesn't cleanly map — is it migrated as-is, archived, or dropped?

6. ☐

   Who is accountable if the migration surfaces bad data in the old system, like a mismatched inventory count or a duplicate customer record?

7. ☐

   Is there a rollback plan if cutover has to be delayed after data is already loaded?

08 / Security & backups

Evidence, not a policy statement.

Almost every vendor has a security page. Fewer can show that the backup and restore process was actually tested, or name who can access your data beyond their own marketing copy.

1. ☐

   How is data encrypted, both in transit and at rest?

2. ☐

   What backup frequency and retention period does the vendor guarantee in writing?

3. ☐

   Has the restore process actually been tested, and can the vendor show evidence, not just a policy statement?

4. ☐

   What access controls exist for admin-level and financial permissions, and can multi-factor authentication be required?

5. ☐

   Is there a documented incident-response process, and would we be notified directly if our data were affected?

6. ☐

   Who at the vendor — or which subprocessors — can access our data, and is that list disclosed?

7. ☐

   Does the vendor run independent security audits or penetration tests, and can a summary be shared even if the full report can't?

09 / Exit terms

The fair test of a contract is how it reads on the day you leave.

Exit terms rarely come up during a sales process, which is exactly why they belong on this checklist and not left for the year the contract is up for renewal.

1. ☐

   What is the contract's minimum term, and what notice period is required to leave?

2. ☐

   Can we get a full data export in a usable format at any time, without a support ticket or a fee?

3. ☐

   Is there an early-termination fee, and how is it calculated?

4. ☐

   What happens to our data on the vendor's servers after we leave — how long is it retained, and can deletion be required?

5. ☐

   Does the vendor offer any transition support — a final export call, documentation of our configuration — or does the relationship end at the last invoice?

6. ☐

   If a partner implemented the system, does the exit path depend on that partner staying in business, or is the underlying platform ours regardless?

10 / Score every vendor

A scoring template, so the decision isn't the best demo.

Copy this rubric once per vendor. Score each of the nine categories above from 1 (didn't answer, or answered badly) to 5 (answered fully, in writing, with specifics). Multiply weight by score, divide by 5, and total the weighted column — the vendor with the highest total gets the recommendation.

The weights above are a starting point, not a rule — a manufacturer might weight integrations and requirements-by- department higher; a business with light IT staff might weight hosting and SLA higher. What matters is picking the weights before you see any vendor's answers, and holding every finalist to the same rubric so the comparison stays honest.

11 / Questions

Common questions about ERP selection

01

What should be on an ERP requirements checklist for a small business?

One list per department that actually touches the system — finance, order management, inventory, operations, HR, and IT — each answering the same question: what does this team need the system to do on day one, not eventually? A requirements list built by one person in one department misses the workflows the other departments depend on.

02

How long should ERP vendor evaluation take?

Long enough to get written answers to every question on this checklist from every finalist, and short enough that the business doesn't stall waiting. There's no fixed calendar — a single-entity business comparing two or three vendors can usually finish evaluation in a few weeks; a multi-entity or manufacturing rollout with a longer requirements list takes longer.

03

What's the difference between an ERP RFP and this checklist?

A formal RFP is a procurement document you send to vendors and they respond to in writing, often for a competitive bid process. This checklist is the shorter list of questions behind that RFP — the things worth asking even if you never write a formal proposal, because a vendor call that dodges the data-export or exit questions tells you as much as one that answers them.

04

Should every department get a vote on ERP requirements?

Every department that will use the system should get a say in its own requirements section — finance doesn't need veto power over the warehouse team's barcode workflow, and vice versa. What breaks implementations is a system chosen by one department's criteria and then imposed on the others after the contract is signed.

05

What happens if a vendor won't answer the data-export or exit questions directly?

Treat it as an answer. A vendor confident in an open format and a clean exit path will say so plainly, usually with a specific export format or API. A vague answer, or one that routes you to a sales call instead of a document, is worth weighing against the rest of the vendor's scorecard before you sign anything.

Read next: What is an ERP system? · QuickBooks to ERPNext migration · Cloud ERP · ERPNext hosting