Long software selections are not thorough; they are usually unfocused. A structured process can reach a defensible decision in weeks, and it produces a better outcome because it is grounded in how your business actually works rather than in a feature matrix supplied by vendors.
Start With What Makes You Different, Not a Feature List
Every mid-market ERP handles invoicing. Every CRM stores contacts. Comparing on the common ninety percent tells you nothing and consumes most of the calendar. The useful question is narrower: what does your business do that a standard system will not handle out of the box?
Perhaps it is unusual pricing, a service model with warranty entitlements, a regulatory report nobody else produces, or scheduling constrained by certifications. That short list — usually three to five items — is what actually separates the candidates. Everything else is table stakes.
Score Against Scenarios, Not Demos
A vendor demo shows the software at its best on a script the vendor chose. Invert it: write three or four real scenarios from your own operations, complete with the awkward details, and ask each vendor to walk through them in their system.
You learn what a demo cannot tell you — how many steps it takes, whether it needs configuration or customization, whether the vendor understands the problem, and whether the answer is “yes, natively” or “yes, with a partner add-on you have not been quoted for.” That last distinction is worth the whole exercise.
Price the Whole Thing
Licence cost is the visible part. The rest routinely exceeds it:
- Implementation and configuration — often a multiple of first-year licensing.
- Data migration from whatever you run today.
- Integration with the systems you are keeping.
- Training, and the productivity dip while people learn.
- Add-on modules that turn out to be required for your short list of differentiators.
- Ongoing support and version upgrades.
Compare over three to five years. A cheaper licence with an expensive implementation and mandatory add-ons is not the cheaper system.
Check the Things Vendors Do Not Volunteer
- Getting your data out. Ask specifically how a full export works and in what format. Vendors who answer this cleanly are telling you something about themselves.
- Integration reality. A documented, supported API — not “we can build an integration.” Ask what it costs and who maintains it after go-live.
- Who implements it. Often a partner, not the vendor. Evaluate that partner as carefully as the software; the same product succeeds or fails on the implementation team.
- References that match you. Similar size, similar sector, live for at least a year. Ask what went wrong and what they would do differently — the useful part of any reference call.
Decide, Then Commit
Beyond a point, more evaluation produces more anxiety rather than more information. If two systems both handle your differentiators and the total costs are comparable, the remaining difference is smaller than the cost of delay. Pick one, and spend the saved time on implementation — which is where the outcome is actually determined.
Related service: ERP and CRM selection consulting
Suite or Two Systems: Settle the Shape Before the Shortlist
ERP and CRM overlap at the customer master, the price list, and the point where a quote becomes an order. Before comparing products you have to decide whether one vendor owns both sides of that boundary or two systems meet across an integration you maintain. The answer changes which vendors are even candidates.
The test is where your differentiators sit relative to that boundary and how often the boundary gets crossed in normal work. If everything unusual about your business lives on one side, two systems joined by a nightly one-way sync is a defensible shape. If your differentiators straddle it, configured pricing that has to see live inventory, service contracts that drive both warranty entitlement and billing, then the integration is where the project risk concentrates and a suite starts to earn its constraints.
Ask three mechanical questions before you commit to a shape. Which system is authoritative for the customer record, the item, and the price, so that when the two disagree there is a rule rather than an argument. Is the sync one way or two way, and at what latency, because two-way sync on a record both sides can edit needs conflict handling that someone has to design. And how are records matched across the systems: a stable external ID written to a dedicated field on both sides, or fuzzy matching on names and email addresses, which degrades quietly for years. A suite removes the matching problem and couples your upgrade schedule, your renewal, and your negotiating position to one vendor. Two systems keep each half replaceable and hand you a middle layer that someone has to run, monitor, and fix every time a field changes.
The Constraints That Eliminate Candidates Before Anyone Scores Anything
Constraints are binary, so they cut a long list faster than any scoring exercise and cost almost nothing to apply. Run these before you invest a single hour in scenarios.
- Deployment and tenancy. In multi-tenant SaaS you take the vendor's upgrades on the vendor's cadence, with a sandbox window to test and no option to skip a release indefinitely. Single-tenant hosting and on-premise let you defer, which is how organizations end up several versions behind on something nobody will support. If a regulator, a customer contract, or an isolated plant network forces on-premise, most of the SaaS market is out and you want to know that in the first week rather than the tenth.
- Data residency and subprocessors. Where records are stored, where they are processed, whether backups leave the region, and whether support staff can view production data. Ask for the subprocessor list as a document, not for reassurance in a meeting.
- Identity. SAML 2.0 or OIDC single sign-on, and SCIM provisioning if you want joiners and leavers driven by your directory instead of by an administrator remembering. Without SCIM, deactivating a departed user is a manual step, and manual steps become audit findings.
- Integration mechanism, in specifics. Whether the API actually covers the module your differentiator lives in, since coverage is often deep in finance and thin in field service, configurators, or project accounting. Whether changes are pushed as webhooks or have to be polled. What the rate and batch limits are per minute and per day. And whether the sandbox carries the same limits as production, because an integration that passes testing against a generous sandbox and then throttles in production is a go-live incident.
Ask Where Each Differentiator Lands: Configuration, Extension, or Code
Two vendors can both say yes to the same requirement and mean completely different things. What separates them is which of three buckets the work falls into, because the bucket sets what that requirement costs you every year afterward, not just at go-live.
Configuration is settings, custom fields, forms, workflow rules, and report definitions held as metadata that the vendor's upgrade process is responsible for carrying forward. It is the cheapest bucket to own and usually the one an internal administrator can change without opening a ticket. Extension is code written against the vendor's supported extension model, running in its sandbox or as an external service against published events and APIs. It survives upgrades, but on the vendor's deprecation schedule, which means someone on your side has to read release notes and act on them before a deadline you did not set. Customization is change to base objects or core code that the vendor does not treat as part of its contract, or a partner add-on that reaches into internals. Every upgrade then becomes a regression test of your own work, and the predictable result is that upgrades get postponed until postponing them becomes its own project.
Ask each vendor to classify each item on your differentiator list in writing, and ask what happens to that item at the next major release. One vendor's yes can mean a checkbox; another's can mean a developer, a deployment process, and a permanent maintenance obligation. Then ask who is permitted to change it later. If the answer is only the partner, you have bought a standing support relationship along with the software, and that belongs in the cost comparison.
When the Obvious Choice Is the Wrong One
Four situations reliably break the candidate that otherwise scores well.
- The system everyone in your industry runs. Verify who actually builds and supports the industry functionality. When it is a vertical layer published by a third party on top of a general platform, you inherit that publisher's release cadence, support model, and survival, and the base vendor's roadmap can shift underneath it. Ask whether the layer is certified by the base vendor, how quickly it follows base releases, and what your position is if the publisher is acquired or stops publishing.
- The entry edition that gates what you need. Vendors tier by feature and by limit, and the items held above the entry tier tend to be exactly the ones you discovered you needed: additional custom objects and fields, extra sandbox environments, field-level security and granular permissions, multi-entity or multi-currency consolidation, approval workflows, higher API ceilings, SSO and SCIM. Price the edition that contains your differentiators and your integration, and apply the per-user step up to every user, not only to the handful who touch the gated feature.
- The system your team already knows. Familiarity lowers training cost, which is real but bounded and spent once. It does not move a differentiator from customization to configuration, and it does not change an API's coverage. Let it break a tie; do not let it be the argument.
- Good fit, one implementer. If exactly one firm within reach has built your differentiator in that product, the fit is real and so is the exposure: no second quote, no benchmark for change-order rates, and no recovery path if the relationship fails mid-project. Ask the vendor to name an alternative and price the same scope with them. A second-choice product with three capable implementers is sometimes the better project.
Test It Before You Sign, Not After
A vendor walkthrough tells you whether the system can do the work. A hands-on trial tells you whether you can. Scope one narrowly, to a single differentiator plus the one integration that matters, and set these conditions.
- Your data, not the demo set. An extract of real customers, items, price lists, and open orders, including the records you are embarrassed by: the duplicates, the missing tax IDs, the account with fourteen ship-to addresses. Demo data is clean, and clean data hides most of what migration will surface.
- Your hands on the keyboard. Have the person who will actually administer the system do the setup with the vendor advising rather than driving. The question that decides it is whether your own administrator could have done that setup unaided.
- The whole path, including the ugly one. Not the happy case: the return, the credit memo, the partial shipment, the change order that lands after the invoice, the correction that lands after month-end close.
- The export, while you are in there. With real data loaded, run a full export and open the file. This is the cheapest moment you will ever have to find out what you would actually be handed.
- A price on the pilot. Scope it in a short statement of work with a named deliverable and pay for it, rather than accepting it as a free sales activity. Paid work gets a named consultant and a schedule; free work gets whoever is between projects.
Frequently Asked Questions
How many systems should reach the scenario stage?
Three is usually the right number, and the cut down to three should be made with constraints rather than scores. Filter the long list on the binary items first: deployment model, data residency, identity requirements, whether the API covers the module holding your differentiator, whether a capable implementer exists within reach. Then filter on the differentiator list. Then stop. Each extra candidate costs roughly what the first one did, because scenario preparation is shared but walkthroughs, follow-up questions, and reference calls are not. Two is workable when constraints genuinely eliminate the rest, though it leaves you without a second price to compare. Past four, the process no longer fits in the participants' calendars, and a selection that does not fit in calendars is how a six-month evaluation happens.
What if no candidate handles one of our differentiators natively?
First decide whether that differentiator is a requirement or a habit. Some are genuinely imposed from outside: a regulator's report format, a customer's EDI specification, a certification rule that governs who may be dispatched to a job. Those have to be met somewhere. Others are residue from what your current system could not do, and rebuilding them faithfully in the new one carries an old constraint forward at your expense. For the ones that are real, you have three options: an extension against the vendor's supported model, a satellite application that owns that process and exchanges data with the core system, or an accepted manual step. Decide on volume and consequence. A manual step performed twice a month by one trained person is cheaper than an integration. The same step performed forty times a day, or one where a mistake reaches a customer invoice, is not. Record which option you chose for each item; the ones nobody wrote down reappear as change orders during implementation.
How much data actually has to migrate, and do we clean it before or after selection?
Less has to move than people assume, and the split matters because migration effort scales with the number of record types you map, not the number of rows. Open items generally move: customer and vendor master, item master and price lists, open AR and AP, open sales and purchase orders, inventory balances, active contracts and serials still under warranty. Closed history generally does not. Keeping the old system readable for a defined period, or extracting closed transactions to a reporting store, is usually cheaper than forcing years of historical documents into a schema that will not take them cleanly. On sequence: cleaning belongs before migration but not before selection. Deduplication, address normalization, and retiring dead records improve any target system and are worth doing in your current one while the evaluation runs. Field mapping is the part you cannot start early, because you do not yet know the target data model.
What should we ask a reference beyond how the project went?
Ask about the period after go-live, which is where the ongoing cost actually shows up. How many months passed before the new system was the real system of record rather than a parallel copy people double-checked. What they still run in spreadsheets, and why that never got fixed. How the first major upgrade went and what broke. How change orders were priced against the original statement of work, and roughly how many there were. Then ask about people rather than the firm: whether the consultants who ran their project are the ones named on your proposal, whether the account team changed partway through, and who picks up the phone when something fails during month-end close.
Which contract terms matter at signature?
The ones that govern year three, not year one. Renewal uplift needs a cap in writing, or the discount you negotiated simply becomes the base that an annual percentage is applied to indefinitely. Price protection on growth: what an added user, legal entity, or module costs at the same terms, so that expansion is not a fresh negotiation from list price. Environment entitlement: how many sandboxes you get, whether they refresh from production, and whether they carry production's API limits. Termination and retrieval: how long the vendor retains your data after the contract ends, how long you have to pull it, and whether the export commitment sits in the order form rather than in a sales answer. Limits belong in writing too, since API ceilings, storage allowances, and overage rates that live only in documentation can be revised without you. Finally, assignment and continuity: what happens to your implementation partner's obligations if that firm is acquired, and who owns the integration code they wrote for you. If it is not in the order form or the statement of work, it is a plan, not a term.
Our two finalists tie on differentiators and total cost. Is there anything left to look at?
Nothing that justifies another week of evaluation. If the pilot did not already answer these, the closing point above stands: pick one and spend the time on implementation. But the pilot usually did answer them, and each of these uses evidence you already have rather than adding calendar time. Which candidate has less that is hard to unwind: fewer record types in the migration, less extension work already scoped, a one-way integration instead of a two-way one. Which one your own administrator got further with unaided. Which implementation team you would rather have in the room during a month-end close, since you will be working with them long after the sales team is gone. And which vendor gave you a straight answer when the honest answer was unflattering, because that behavior tends to repeat after signature. Then decide.