Most ERP selection processes are structured backwards. Organizations spend the first four months evaluating product features — dashboards, module depth, mobile interfaces — and the final two weeks reviewing the contract under time pressure from a vendor sales cycle that was engineered to produce exactly that outcome. The result is that the questions that determine actual project success: who bears risk when the implementation runs over, what happens to your customizations when the platform upgrades, whether your integration architecture is sustainable at three times your current transaction volume — get asked too late, answered too vaguely, or never asked at all. This post gives you a structured framework for front-loading the evaluation questions that matter, and a vendor RFI scoring approach that makes responses comparable across platforms like SAP S/4HANA, Microsoft Dynamics 365, and their mid-market alternatives.

Why the standard feature evaluation fails mid-market organizations

The standard ERP selection process, as practiced by most mid-market organizations, prioritizes the wrong inputs. Feature comparison matrices — does the system have landed cost tracking, multi-entity consolidation, shop floor scheduling — are necessary but not sufficient. Features can be demonstrated in a sandbox. What cannot be demonstrated in a sandbox is whether your implementation partner has the bench strength to deliver on time, whether the vendor’s upgrade cadence will invalidate your customizations every eighteen months, or whether the total cost over a seven-year horizon fits your capital plan.

In our experience working with mid-market organizations through ERP selection and implementation, the deals that go wrong follow a recognizable pattern. The selection team builds consensus around the product that performed best in the demo. The contract is reviewed primarily by procurement, with legal focused on liability caps rather than delivery accountability. The implementation begins with optimistic timelines, and by month eight the project is six months behind schedule, the customization scope has tripled, and the internal project sponsor is managing vendor relationships as a full-time job rather than doing their actual work.

The framework that follows is organized around the six dimensions of vendor evaluation that actually predict project outcomes for organizations in the 100-to-2000-employee range.

Dimension 1: Total contract value versus total cost of ownership

Every vendor will present a total contract value figure. That number — annual license or subscription fees multiplied by contract term — is not your cost. It is the floor. The questions you need answered before signing establish what sits above that floor.

In a typical mid-market ERP deployment, the implementation services cost runs between 1.5x and 3x the first-year license cost for cloud platforms, and higher for heavily customized on-premise deployments. Data migration — often underscoped in initial estimates — adds meaningful cost for organizations with more than a decade of transaction history in legacy systems. Training, change management, internal resource time, and productivity loss during cutover are rarely captured in a vendor’s TCO model.

Ask vendors to provide a seven-year TCO model, not a three-year one. Cloud ERP subscription costs compound. Annual price escalators of three to five percent, common in enterprise software agreements, add up materially over the life of a contract. Request that the vendor’s TCO model include: annual license escalation assumptions, estimated cost of each major version upgrade, expected customization rework cost per upgrade cycle, and integration maintenance cost as your system landscape evolves.

Vendors that resist providing a seven-year model — citing uncertainty about future pricing — are telling you something useful. Vendors that provide one with clearly stated assumptions are giving you a basis for negotiation and accountability.

Dimension 2: Implementation partner accountability clauses

The vendor and the implementation partner are typically different entities, and the accountability gap between them is where mid-market ERP projects most commonly fail. The software vendor’s contract governs the license. The implementation partner’s statement of work governs delivery. In most standard agreements, the implementation partner’s liability is capped at fees paid, timelines are targets rather than commitments, and the risk of scope expansion rests almost entirely with the buyer.

Before signing, negotiate the following into your implementation partner agreement:

• Milestone-linked payment structure. No more than 20-25% of implementation fees should be payable before defined, measurable milestones are achieved. Milestones should be tied to functional delivery — system configured and tested against documented requirements — not to calendar dates.
• Named resource commitments. The team presented during sales is not always the team that shows up for delivery. Require that key roles — project manager, solution architect, lead functional consultant — are named in the contract, with a defined process for approving substitutions.
• Go-live readiness criteria. Define in writing what “ready to go live” means before the project starts. Include performance benchmarks, user acceptance testing sign-off requirements, and data validation thresholds. This prevents the partner from declaring the system ready when it isn’t.
• Hypercare support terms. The 30 to 90 days immediately following go-live are when ERP projects encounter their highest volume of operational issues. Negotiate explicit hypercare support terms — response time commitments, resource availability, escalation paths — rather than relying on the partner’s standard post-delivery support model.

Dimension 3: Customization governance

Every ERP platform — SAP S/4HANA, Microsoft Dynamics 365, NetSuite, Acumatica — ships with standard functionality that will not perfectly match how your organization operates. The question is not whether you will customize; it is how much, under what governance, and who owns the consequence of that customization when the platform upgrades.

Organizations that approach customization without a formal governance framework accumulate configuration debt. Each customization that modifies core platform behavior becomes a potential conflict point with every subsequent upgrade. In our experience, organizations that enter an ERP implementation without a customization policy typically spend 30 to 60 percent of their upgrade budget resolving customization conflicts rather than adopting new functionality.

Before signing, establish and document your customization governance policy:

• Categorize customization types. Distinguish between configuration (using the platform’s built-in options to match your process), extension (adding fields, reports, or workflows within the platform’s extension framework), and modification (altering core platform code or data structures). Only configuration and properly scoped extensions should be permitted without executive sign-off.
• Require upgrade impact assessments. For any modification that falls outside the vendor’s standard extension framework, require the implementation partner to document the upgrade impact at the time of delivery — not when the next upgrade is announced.
• Get the vendor’s upgrade commitment in writing. Ask specifically: how frequently does the platform release major upgrades, what is the supported window for older versions, and what tools exist to identify customization conflicts before an upgrade begins? For cloud platforms like Dynamics 365, which update continuously, this question is particularly important.

Dimension 4: Integration architecture

Your ERP will not operate in isolation. It will connect to your CRM, your warehouse management system, your e-commerce platform, your EDI network, your payroll system, and potentially your customers’ and suppliers’ systems. The integration architecture decisions you make during selection determine how maintainable, scalable, and costly that connectivity is over the life of the system.

The three primary integration patterns — API-first native connectors, middleware platforms like MuleSoft or Azure Integration Services, and point-to-point custom integrations — have meaningfully different cost and risk profiles:

Ask each vendor to document their recommended integration architecture for your specific system landscape — not a generic architecture diagram, but one that names the systems you listed in your RFI and explains how data flows between them. Ask specifically whether their recommended integration approach remains supported across major platform versions, and who bears the cost of rework if the vendor’s API changes in a way that breaks existing integrations.

Dimension 5: Reference checks at comparable scale

Vendor-provided references are selected to impress, not to inform. The reference list a vendor provides will skew toward successful deployments, long-tenured customers, and organizations that have a relationship with the vendor’s sales team. This does not mean references are useless — it means you need to structure the reference conversation to extract signal the vendor did not intend to provide.

Require references that match your profile on three dimensions: industry vertical (same or adjacent), company size (within 50% of your headcount and revenue), and implementation complexity (comparable number of entities, geographies, and integration points). A successful SAP S/4HANA deployment at a 12,000-person manufacturing conglomerate tells you almost nothing about what a 350-person specialty distribution company should expect.

When you speak with references, ask these questions specifically:

• What was the original go-live date, and what was the actual go-live date? Ask for the specific months, not a general “we ran a bit over.”
• What was the original implementation budget, and what did you actually spend? Separate license cost from implementation services cost in the answer.
• If you were starting over, what would you change about the selection or implementation process? This open-ended question surfaces regrets that direct questions do not.
• How has the vendor performed post-go-live, specifically on support ticket response and product roadmap transparency?
• Have you been through a major platform upgrade? What did that cost and how long did it take?

Vendor RFI scoring template

A structured RFI process makes vendor responses comparable and defensible. The following scoring dimensions and weights reflect what we believe matters most for mid-market B2B organizations:

Score each vendor from 1 to 5 on each dimension, multiply by the weight, and sum the results. The scoring process is less important than the discipline it imposes: it forces the evaluation team to respond to documented answers rather than demo impressions, and it creates an audit trail for the selection decision that holds up when stakeholders challenge it six months into implementation.

The contract review checklist

Before any ERP contract goes to signature, the following items should be reviewed and addressed — not delegated entirely to legal counsel, who will focus on liability and indemnification rather than delivery accountability:

• Price escalation caps. Negotiate a maximum annual price increase percentage and include it in the contract, regardless of what the vendor says about standard pricing practice.
• Data portability and exit rights. Define in writing what data you can export, in what format, and on what timeline if you terminate the contract. This is particularly important for cloud platforms where your data lives in the vendor’s infrastructure.
• SLA definitions and remedies. Uptime SLAs are standard. Also negotiate SLAs for support ticket response and resolution by severity level, with defined financial remedies for breach.
• Customization ownership. Any customizations, extensions, or configurations built during implementation should be owned by your organization, with access to source code or configuration exports as applicable.
• Audit rights. Include the right to audit vendor compliance with security and data handling commitments — not just for regulatory compliance, but as a negotiating tool that signals you take these commitments seriously.

Frequently asked questions

How long should an ERP selection process take for a mid-market organization?

For organizations in the 150-to-1,000-employee range with moderate complexity, a well-structured selection process takes four to six months from initial RFI to contract signature. Processes that run shorter than three months typically cut corners on reference checks, TCO modeling, and contract negotiation. Processes that run longer than eight months tend to develop stakeholder fatigue, lose internal momentum, and sometimes result in the selection team optimizing for completing the process rather than selecting the right platform. Build the timeline around the evaluation work required, not around vendor sales cycles or internal budget deadlines.

Should we use a third-party ERP selection consultant, and how do we evaluate one?

For organizations that do not have recent, direct ERP selection experience on the team, a third-party consultant provides meaningful value — specifically in RFI design, vendor negotiation, and contract review. The risk is that some selection consultants have referral relationships with implementation partners that create conflicts of interest. When evaluating a selection consultant, ask directly whether they receive any compensation — fees, referrals, or preferred partner arrangements — from any ERP vendor or implementation partner. Require disclosure in writing. The most credible consultants charge a flat fee for the engagement and have no financial relationship with vendors on the short list.

What is the right number of vendors to evaluate seriously?

A rigorous evaluation is difficult to sustain across more than three or four finalists. Most mid-market organizations benefit from a two-stage process: a broader RFI phase that narrows the field from six or eight candidates to three, followed by a detailed RFP and demonstration phase for the finalists. Evaluating more than four vendors in the final stage dilutes the depth of evaluation on any single vendor and increases stakeholder decision fatigue without proportionally increasing the quality of the selection.

How do we evaluate SAP S/4HANA versus Microsoft Dynamics 365 for a mid-market manufacturing company?

Both platforms are viable for mid-market manufacturing, and the honest answer is that the choice between them depends heavily on your existing technology ecosystem, your implementation partner options in your geography, and your organization’s appetite for configuration complexity. SAP S/4HANA tends to offer deeper native manufacturing functionality — production planning, quality management, plant maintenance — but carries higher implementation cost and complexity for organizations without prior SAP experience. Dynamics 365 integrates more naturally with Microsoft-centric organizations and typically has a broader mid-market partner ecosystem in Canada, but manufacturing-specific depth often requires ISV add-ons. Evaluate both on the dimensions in the RFI framework above rather than on platform reputation alone.

What is the single most common mistake organizations make in ERP selection?

Selecting the platform before completing the process design work. The most frequent error we observe is organizations that enter the selection process with an undefined future-state process — they know what they do today, but have not made decisions about what they want to do differently after implementation. ERP selection conducted against undefined requirements produces a system configured to replicate existing inefficiencies on a more expensive platform. Before you evaluate vendors, document your future-state process requirements for the three or four core business processes the ERP needs to support. Those requirements drive the RFI, the demonstration scenarios, and ultimately the contract scope.

ERP Selection Framework: The Questions to Ask Before Signing Any Contract

Most senior operations leaders and CFOs at mid-market companies enter an ERP selection with a clear sense of what they want the system to do, but without a framework for evaluating whether the vendor and implementation partner can actually deliver it. This post provides the structured evaluation methodology — covering total cost of ownership, implementation accountability, customization governance, integration architecture, and reference validation — needed to sign an ERP contract with confidence rather than optimism.