Vendor demonstrations are a critical part of the ERP selection process — but most companies walk into them underprepared. Sales teams are professionals at showcasing their platform’s best features in the best possible light. Without a structured set of questions and a clear demo script, you will leave each session impressed by what the software can do and completely uncertain about whether it fits your specific situation.

This checklist gives you the structure to get real answers. It covers how to set up your demo for maximum value, and provides specific questions across each major evaluation category — implementation, data migration, support, customization, and product roadmap.

How to Structure Your ERP Demo

Give Vendors Your Scenarios in Advance

A generic demo is nearly useless. Send each vendor a set of scripted scenarios before the demonstration — your key business processes that the ERP must handle. Ask them to demonstrate each scenario specifically, using either a sandbox environment or a configuration representative of your business type.

For example: “Show us how a sales order is placed, inventory is allocated, a pick list is generated, the shipment is confirmed, and the invoice is created — from end to end.” This scenario tests order-to-cash in a way that a generic product tour does not.

Require Participation From End Users

Include representatives from finance, operations, and warehouse (or the relevant operational teams) in your demos — not just IT and project sponsors. The people who will use the system every day will notice usability issues, ask practical questions, and spot gaps that technical evaluators miss.

Evaluate the Demo Environment Quality

A well-prepared vendor will bring a demo environment pre-loaded with data representative of your industry. A vendor who demos on a generic sandbox with placeholder data is telling you something about how seriously they take your business. Pay attention to preparation quality.

Take Structured Notes

Assign one person per demo session the job of documenting specific answers (not impressions) for each checklist question. This person does not participate in the conversation — their job is to capture what was said for review and comparison after all demos are complete.

Demo Questions by Category

Implementation Questions

Question	What You Are Really Assessing
What is your implementation methodology, and can you walk us through the project phases?	Whether they have a structured, repeatable process — not just “we figure it out”
What is the typical project timeline for a company of our size and complexity?	Realistic planning baseline; compare to what they promise vs. their references report
Who are the implementation team members, and what are their qualifications?	Whether you get senior consultants or junior staff with minimal oversight
How many of your implementations for companies similar to ours came in on time and within budget?	Historical delivery performance; follow up on the ones that did not
What is your approach to project governance and escalation when issues arise?	Maturity of their PM methodology
What are the most common causes of implementation delays in projects like ours?	Honesty about risk; use this to probe your own readiness
How do you handle scope changes during implementation?	Whether scope creep is managed or turns into unlimited billing

Data Migration Questions

Question	What You Are Really Assessing
What data migration tools do you use, and do you handle migration yourselves or hand it to us?	Who bears the technical migration burden
What data formats do you accept for import?	Practical readiness for your data formats
What is your process for data cleansing and validation before go-live?	Whether they treat migration as a technical task or a business quality exercise
How do you handle historical transaction data — do we bring all history into the new system?	Options for historical data strategy
Can you show us a data migration checklist from a recent project?	Specificity of their methodology; vague answers here are a yellow flag
What happens if data quality issues are discovered after go-live?	How they handle inevitable post-migration data problems

Support Questions

Question	What You Are Really Assessing
What support tiers do you offer, and what is included in each?	Realistic understanding of what you get for your money
What is the response SLA for a P1 (system unavailable) issue?	How seriously they treat your operational continuity
Who handles our support tickets — internal staff or partner staff?	Quality and consistency of support personnel
What is your average time to resolution for P2 issues?	Actual support performance, not just promises
Do you provide a dedicated customer success manager, and what do they do?	Post-go-live relationship management
Can we speak with three customers who have been on your standard support tier for at least two years?	Reference check specifically for support experience
How do you communicate product outages and scheduled maintenance?	Operational communication practices

Customization Questions

Question	What You Are Really Assessing
What is the development platform for customizations, and what skills does it require?	Internal capability vs. partner dependency for changes
How do customizations survive product updates?	Risk of customizations breaking with each release
Can you show us an example of a customization a customer in our industry has built?	Concrete evidence of customization feasibility
What is the process for testing customizations before they go into production?	Quality control for custom development
Are there any areas of the platform that cannot be customized?	Understanding of hard limits
How do we access the customization platform — is it included in the license?	Hidden costs in the customization story

Product Roadmap Questions

Question	What You Are Really Assessing
What is your product release schedule, and how are major features communicated in advance?	Planning ability and update management
Can you share your product roadmap for the next 12 months?	Transparency; willingness to commit to direction
Which of our must-have requirements are currently on your roadmap?	Whether gaps are being addressed
How does customer feedback influence your roadmap?	Whether customers have a voice in development priorities
What is your long-term commitment to the product segment we are buying into?	Risk of product sunsetting or deprioritization
What happened to products you previously offered that are no longer being actively developed?	Track record on product lifecycle management

Pricing and Contract Questions

Question	What You Are Really Assessing
What is included in the base license, and what costs extra?	Full picture of licensing costs
How does pricing scale if our user count increases by 50% over three years?	Long-term cost trajectory
Are implementation services included, or are they billed separately?	Total investment clarity
What is the minimum contract term, and what are the penalties for early termination?	Contract risk and flexibility
How have your prices changed over the last three years, and what should we budget for annual increases?	Pricing stability expectations
What happens to our data if we decide not to renew?	Data portability and off-boarding terms

After the Demo: How to Evaluate What You Heard

A checklist is only useful if you act on the answers. After each demo, do the following before your notes grow cold:

Score each vendor’s responses against your criteria immediately after the session — not at the end of all demos. Your committee members should score independently, then compare and discuss discrepancies.

Note any questions the vendor could not or would not answer. Unanswered questions are data points. A vendor who says “I’ll get back to you on that” should be followed up with within a week — both to get the answer and to assess their responsiveness.

Check references specifically for the experiences highlighted in the demo. If a vendor claimed their implementation timeline is consistently six months, ask their references whether that was their experience.

Compare what was shown in the demo against the contract and documentation. Sales teams sometimes demonstrate features that are on the roadmap but not yet in production, or that require an add-on not included in the proposed price. Due diligence means verifying that what was shown is actually included in what you are buying.

The Questions Your Internal Team Should Answer Before the Demo

Your evaluation will be more effective if you enter each demo having answered these questions among your own team:

What are your three most critical business processes that the ERP must handle — the ones that, if broken, would stop your business?

What is your realistic data migration scope? How many years of transaction history do you need to migrate, and what is the current quality of that data?

Who will be the internal project owner for the implementation — and do they have the authority, time, and skills to drive the project to completion?

What is your actual budget — not the number you plan to share with vendors in negotiation, but the real approved budget including a contingency for the unexpected?

Frequently Asked Questions

How many demos should we run, and over how long a period? Running demonstrations from three to five vendors is practical for most selections. More than five vendors creates evaluation fatigue and dilutes the quality of each session. Allow at least a week between vendor demos so scores are based on fresh recall, and complete all demos within a six-to-eight-week window to maintain momentum.

Is it reasonable to ask for a demo in our own test environment with our own data? A fully configured test environment with your data typically comes after you have signed a letter of intent or entered a paid pilot phase. During the initial selection demo, it is reasonable to ask vendors to use a demo environment configured for your industry with representative data. For vendors you are seriously considering, a short paid proof-of-concept — where the vendor configures a subset of your requirements in a real environment — is a worthwhile investment before a final decision.

What should we do when a vendor promises a feature is “on the roadmap”? Treat roadmap commitments as promising but unverifiable. Do not allow a vendor to earn a high score on a current requirement by promising a future feature — score them on what is available today. If a roadmap feature is critical, negotiate a contractual commitment (including target delivery date and remedies if it is not delivered) before you sign. Verbal roadmap promises during a sales process are not contractually binding.

How do we avoid being sold to rather than informed during a demo? Structure your demo as a working session, not a presentation. Send your scripted scenarios in advance and insist the vendor work through them specifically. Ask your operational end users to attempt tasks themselves in the demo environment when possible. Ask “show me” more than “tell me” — “Can you show us how we would handle a return from a customer where the original order was split across two invoices?” gets you further than “Do you support returns management?”