Most ERP selection processes in retail get the answer right and the question wrong. The process produces a vendor. It does not produce clarity on what the business is actually trying to accomplish with the ERP.
Six months after signing, the implementation team is solving problems nobody scoped, the business is wondering why the migration is behind and over budget, and the vendor is producing change orders that land in the inbox of an executive who was not in the selection room. This is not a vendor problem. It is a selection problem.
I have watched retailers spend nine months on an ERP selection and then fail to articulate, in a single sentence, what decision they were trying to make. The scorecard was meticulous. The demos were thorough. The reference calls were comprehensive. And the business case that came out at the end read as a cost-benefit analysis of features, not of a fit with how the company actually runs.
This guide is the selection framework I use when I advise multi-site retailers on ERP programs. It is built from actually migrating ERPs across a 300+ store estate, leading a full ERP conversion post-acquisition across 190 stores in two countries, and evaluating the same set of vendors more times than I can count. It is not a vendor comparison chart. It will not tell you which ERP to buy. It will tell you how to know if you are asking the right questions before you sign.
Why most retail ERP selections go wrong before the RFP
The failure pattern is almost always the same. The RFP goes out before the organization has agreed on what the ERP is actually for.
Procurement-led scoring that optimizes for the wrong dimensions. Procurement scoring is structured to produce an auditable decision. That is a reasonable goal for procurement. It is a terrible goal for an ERP selection. The scorecard rewards feature depth and vendor responsiveness. It does not reward fit with an operating model because the operating model is rarely defined in the scorecard, and cannot be scored on a 1 to 5 scale even when it is.
RFPs that score features instead of operating principles. Every mature ERP has a long feature list. Most will score roughly comparable on the 80% of features that any retailer needs. The 20% that actually differentiates them is buried in how the system handles promotional pricing, franchise versus corporate inventory, cross-border tax, returns without a receipt, or the combination of commission and markdown calculations at the register. Those scenarios do not make it into the RFP because the retailer is not clear on them internally.
Demo fatigue leading to vendor preference by presentation quality. By the fourth demo, the selection team is tired. The vendor with the best presenter, the cleanest demo environment, and the most compelling narrative scores higher than the vendor whose product actually fits better. This is a human problem. It is also predictable, and it can be corrected by forcing demos into the retailer’s own scenarios rather than the vendor’s sandbox.
Reference calls that tell you nothing. The references are selected by the vendor. The retailers on those calls were also selected by the vendor, usually because they are either in a similar segment or because the vendor knows they will speak well. The useful reference calls are the ones you find yourself: a peer retailer who went live two years ago on the same platform and has a stable enough relationship with their implementation partner to speak candidly about year two. Those calls exist. They are rarely on the vendor’s list.
TCO modeled for year one, not year seven. Year-one licensing is the smallest number in the total cost of ownership for an ERP program. Implementation, integration, customization, managed services, training, and the ongoing cost of carrying technical debt when the system does not quite fit dominate the 5-to-7-year envelope. Most retail selections model year one and quietly skip the years where the real money sits.
I worked with a retailer who scored every vendor on “has omnichannel support” without defining what omnichannel meant for their business. Every vendor scored a 5. The one they selected supported omnichannel in a way that did not match how they actually sold, and the implementation spent eighteen months customizing the platform to approximate the operating model the retailer had not articulated in the RFP. That is not a vendor failure. That is a selection failure with the vendor’s name on it.
The five decisions that actually matter
Most ERP selection scorecards run to 30 or 40 evaluation criteria. Nearly all of them are the same across vendors who have been in the retail market for more than a decade. The decisions that actually determine whether the ERP fits are smaller in number and sharper in substance.
Operating model fit
What does your store model actually look like? What is the relationship between corporate and store operations? Is inventory truly centralized or are stores quasi-independent in practice? Where do pricing decisions get made, and where do promotional decisions get made, and are those the same people? Do franchise stores operate on the same platform spine as corporate stores, or on a parallel one?
An ERP embeds an answer to each of these questions in its data model and workflow. An ERP that assumes a different operating model than yours will require either a reorganization of the business to match the ERP, or a heavily customized implementation to match the business. Neither is cheap. The first carries organizational cost. The second carries technical debt.
The useful diagnostic is to write down, in one page, how a single SKU is priced, promoted, inventoried, and sold across your channels. If you cannot write that page, the ERP cannot fix that gap. It can only encode it.
Data model assumptions
Where does customer data live? What is the relationship between SKU and variant in your product taxonomy? How are promotions structured: item-level, basket-level, customer- level, or some combination? What is the system of record for pricing, and does that differ by channel? How is cost of goods actually tracked: standard cost, landed cost, moving average, or something negotiated contract by contract?
These decisions are usually made implicitly by the ERP’s data model. If they do not match how your business has decided to run, you are either changing the business or customizing the ERP around the mismatch.
I have watched retailers discover, six months into an implementation, that the ERP they selected treats promotions as a property of the order rather than as a standalone entity, and that their entire loyalty program assumed the opposite. The cost of that mismatch was not in the RFP.
Integration surface
The ERP never lives alone. It integrates with POS, ecommerce, warehouse management, product information management, product lifecycle management, CRM, payments, tax, shipping carriers, marketplaces, and the dozen operational tools that keep stores running. The real question is not whether the ERP has an API. Every modern ERP has APIs. The question is whether the ERP’s integration model matches yours.
API-first integration is a principle, not a feature. It is the difference between a system that exposes every meaningful operation as a governed API and a system that exposes APIs for the primary entities and expects you to use screen-scraping or batch files for everything else. That difference does not show up in a feature demo. It shows up eighteen months into integration work, when the platform turns out to be the wrong shape for the operational reality of the business.
The diagnostic: ask the vendor to show you the API for a return processed with a partial refund, a replacement item, and a loyalty adjustment that originated from a transaction in a different channel. If that flow requires screen-level scripting or a batch file export, the integration model is not what you need.
Store deployment model
Store-level deployment is where most multi-site ERP migrations stall. Network profiles vary across stores by store age, real estate footprint, and historical IT decisions. Local data caching, offline operation during connectivity loss, rollout sequencing that respects seasonal peaks, and the associate training load per store are all deployment-model decisions that live outside the feature list.
The pilot-in-flagship-store trap is the most common failure mode. A pilot runs in a well-provisioned flagship with dedicated IT on-site and a cooperative manager. The ERP ships its first integration hour on the best infrastructure the chain owns. Rollout then hits network, bandwidth, associate, and process conditions the pilot never encountered, and the cost of fixing the mismatch mid- rollout dwarfs the cost of planning for it upfront.
Plan the deployment model before signing the contract. If the vendor cannot describe a multi-wave rollout across a representative mix of your estate, the selection is not done.
Total cost of ownership over seven years
The license fee is the smallest number in the TCO model. The real costs are implementation, customization, integration, training, ongoing managed services, and the technical debt that accumulates when the ERP does not quite fit the business.
Model year one through year seven. Year one is dominated by implementation. Year two is dominated by post-go-live stabilization, the integration work that got deferred, and the customizations that turned out to be necessary. Years three through five are where the maintenance and incremental-capability work accumulates. Years six and seven are where you discover whether the platform can support the next strategic shift, or whether you are already in a reselection conversation.
The useful ratio: license as a percent of total program cost is usually 15 to 25%. If a vendor’s pricing is structured such that license is 40% or more of the five- year envelope, either the license is too expensive or the implementation is being materially under-scoped. Both are worth knowing before you sign.
Vendors typically considered for multi-site retail
Six platforms cover almost every serious multi-site retail ERP conversation. The short reads below are my honest take. None of them is a universal right answer. Each has a specific retailer profile it fits well, and a specific set of profiles it does not.
SAP S/4HANA. Strong fit for large, multi-country retailers with complex financial consolidations and existing SAP dependencies elsewhere in the business. The depth is real. The implementation cost is also real, and the fit is usually poor below ~$1B in revenue unless there is a strategic reason (parent company alignment, cross-portfolio shared services). The retail-specific modules have matured, and the CAR/CAR plus adjacent platforms carry a lot of the real retail logic.
Oracle Fusion Cloud and NetSuite. Fusion Cloud targets enterprise retailers with complex financial requirements. NetSuite targets the mid-market and has a genuine retail vertical, though the depth of the retail modules varies significantly by use case. NetSuite is often the right answer for 50 to 300-store retailers where the operating model is clean and the complexity is moderate. Fusion Cloud is rarely the right answer unless the retailer is already on Oracle elsewhere.
Microsoft Dynamics 365 (Finance + Commerce). Credible in mid-market retail, especially where the business already runs on Microsoft infrastructure for productivity, identity, and Azure services. The retail module has matured considerably. The common failure mode is under-scoping the Commerce component, which carries most of the in-store and omnichannel capability and is where the hardest implementation decisions live.
Infor. Strong in specific verticals: fashion, soft goods, and certain supply-chain-heavy retail segments. Less often the right answer outside those verticals. The CloudSuite implementations have stabilized materially over the past few years, but the vendor and partner ecosystem is thinner than the tier-one platforms, which affects implementation partner availability.
Epicor. Focused in specific sub-verticals: distribution, manufacturing-adjacent retail, and certain specialty retail segments. Usually not the right answer for department-store or apparel-first retailers. The platform depth is real in its chosen segments and noticeably thinner outside them.
STORIS. The dominant platform in home furnishings retail. If you are in furniture, mattress, or home goods, STORIS is probably on your shortlist, and for good reason: the vertical depth is deeper than any horizontal platform will match. Outside that vertical, it is rarely the right answer.
The evaluation scorecard
A usable evaluation scorecard has six dimensions. Each is evaluated against the operating model the retailer has already defined, not against the vendor’s generic feature list. If the scorecard produces a ranking that disagrees with the senior judgment in the room, the judgment wins and the scorecard gets revised.
Operating model fit. Evaluate by running five to seven of the retailer’s real operational scenarios through the platform, end to end. Not the vendor’s canned demo scenarios. Yours.
Data model alignment. Evaluate by writing down the 10 to 15 data-model assumptions embedded in your business (system of record for pricing, relationship between SKU and variant, promotion structure, customer identity model) and checking them against the ERP’s native data model, not the customization layer.
Integration architecture. Evaluate by mapping the top 20 integrations the ERP will need to support in years one through three, and asking the vendor to describe the native API surface for each. Count the number of integrations that require custom development outside the standard API surface.
Deployment and adoption complexity. Evaluate by asking for the vendor’s actual multi-wave deployment plan across a representative sample of your store estate, with network, bandwidth, and associate- readiness assumptions documented.
7-year TCO realism. Evaluate by modeling years one through seven with implementation, customization, integration, training, and managed-services costs separately from the license line. Stress-test the vendor’s model against the ratios above.
Implementation partner availability. Evaluate by talking to two partners the vendor recommends and two partners the vendor does not. Partner quality and partner supply matter more than most RFPs acknowledge.
What to ask every vendor demo
Ten questions to use in every vendor demo. They are not exhaustive. They are structured to surface the decisions that a scorecard will not.
Show me how a return is processed when the customer does not have a receipt. Tests edge-case handling and the degree to which the platform trusts store-level judgment.
What happens when the store loses connectivity for four hours during a peak sale? Tests offline capability, data-reconciliation logic, and whether the vendor has actually run this scenario in production with a comparable retailer.
Walk me through how a SKU-level price change propagates from the ERP to POS to the website to shelf-edge pricing. Tests the integration architecture and the degree to which the platform owns pricing as a single source of truth.
Show me how promotions are structured when the same item is on promotion in two different channels at two different prices. Tests the promotion data model and the platform’s assumptions about channel-aware pricing.
Demonstrate a mid-day physical inventory adjustment in one store while the rest of the chain continues to sell the same SKUs. Tests inventory- truth handling and the platform’s behavior under real operational conditions.
Show me the audit trail for a manager override at the register during a closing transaction. Tests the compliance and governance model, which matters materially in audits and investigations.
Demonstrate how a BOPIS order is handled when the item is out of stock in the pickup store but in stock at a neighboring one. Tests the omnichannel fulfillment logic that vendors love to describe in the abstract.
Show me the vendor’s native reporting on store-level margin performance for a category across the last 13 periods. Tests whether the reporting layer works natively, or whether every meaningful report requires extraction to an external warehouse.
Walk me through what happens when a vendor invoice arrives that does not match the PO or the receipt. Tests the accounts-payable exception handling, which is where most ERP frustration actually lives.
Show me a post-go-live support ticket from a comparable retailer, with the resolution timeline. Tests the vendor’s willingness to share real operational data, which is the most reliable signal of what the relationship will feel like in year two.
Common procurement mistakes
Scoring features instead of principles. The scorecard asks “does the platform support omnichannel inventory?” Every serious vendor answers yes. The question that would have actually differentiated them is “how does the platform resolve conflicting inventory signals from POS, WMS, and OMS when they disagree within 15 minutes?” That is a principle. Features flatten into parity; principles produce separation.
Demoing in the vendor’s sandbox instead of your scenarios. A demo in the vendor’s sandbox is a demo of the vendor’s ability to run a clean demo. It is not a demo of fit. Force every serious demo into the retailer’s actual operational scenarios, with real data shapes and real edge cases. Vendors who resist this are telling you something.
Calling references the vendor selected. Vendor-curated references are optimized for the vendor’s story. They are not useless, but they are not diligence. Find your own. The CIO network and operator peer groups produce more candid reads in 30 minutes than a scheduled reference call will in 90.
Optimizing for year-one license cost. Year one is the smallest envelope. Optimizing for it produces a decision that looks good in the IC deck and ages badly in operations. Negotiate the license, but select on the five-year envelope.
Selecting the ERP before selecting the implementation partner. The implementation partner shapes 50 to 70% of the program outcome. Partner quality varies more across the ecosystem than the platforms themselves. Evaluate the platform and the partner together; treat them as a joint decision, because that is what they are.
What good looks like after selection
A clear system of record is defined before kickoff. Which system owns the master record for customer, for product, for pricing, for inventory, and for each of the other core entities. In writing. Agreed by the business owners, not just IT.
The implementation plan respects seasonal operational reality. No go-live dates in the busiest week of the year. No major training cutover during Q4 for retailers whose year happens then. This sounds obvious. It is routinely violated.
Change management is funded separately from the implementation budget. Implementation partners routinely under-scope change management, because they are compensated to ship the software. A separate change- management budget with a separate owner is the single most reliable predictor of adoption.
Executive sponsorship has a specific decision cadence, not just a steering committee. A monthly steering committee that reviews slides is not governance. Governance is a weekly or bi-weekly decision cadence where specific decisions are made by specific people on a specific clock.
Frequently asked questions
How long does a retail ERP selection typically take?
3 to 6 months for a sound process. Shorter than 3 months usually means skipping diligence steps that will resurface during implementation. Longer than 6 months usually indicates organizational indecision, not deeper due diligence. The selection process itself is not where the value is created; the value is created in how well the selection framework lines up with the operating model.
Is it better to hire a selection consultant or run the selection internally?
Depends on internal capability. Internal teams tend to be too close to the current pain to evaluate objectively and often carry implicit preferences toward the vendor they already know. External consultants who represent vendors or take referral fees should be disqualified automatically. The useful outside role is independent senior judgment on the operating model fit and the integration architecture, not RFP logistics.
Is skipping the RFP and going straight to evaluation viable?
Possible for smaller retailers where the vendor field is already narrow (typically under 50 stores, single-country, single-channel). For anyone above 100 stores, multi-country, or with a serious commerce or ESL footprint, the RFP is the only mechanism that forces internal alignment on requirements before vendors start shaping the conversation. Skipping it usually means the internal alignment work did not happen.
What happens if the selection turns out wrong?
The answer is not to switch ERPs. The answer is usually to spend 18 to 24 months making the imperfect ERP work, then revisit. ERP reselection inside 5 years of go-live is a sign of deeper organizational problems than the platform itself. That said, a sharp recognition in year one that the integration architecture is wrong is worth acting on quickly; waiting for year five multiplies the cost.
How much does a retail ERP cost in total?
Licensing is typically 15 to 25% of the 5-year program cost. Implementation and integration is 40 to 55%. Change management and training is 10 to 20%. Ongoing managed services and support is the remainder. Whoever tells you the ERP 'costs $X' is telling you about the license fee, not the program. Budget against the full 5-year envelope, not the year-one deck.
Companion artifact
ERP Selection Checklist
The checklist I use with advisory clients during a retail ERP selection. Single-page summary of the decisions in this guide, structured as a pre-RFP readiness review.
Download the checklistThe vendor you choose matters less than the clarity you have about why you are choosing it. An average platform with a clean operating-model fit will outperform a deeper platform whose data model does not match yours, every single time, across every retail segment I have worked in.
Most selection processes produce a vendor. A good one produces a decision the business can actually own. Those are not the same outcome, and the difference shows up not in the contract, but eighteen months after go-live, in whether the operating model has been strengthened or whether it has been quietly replaced by whatever the ERP assumed it to be.