9 ERP Consulting struggles Mid-sized companies face in 2026

ERP projects at mid-sized companies often face challenges that have less to do with the software and more to do with the consulting relationship around it. Here are the nine most common challenges, what they look like in practice, and the steps that help you avoid them.

ERP projects at mid-sized companies often hit unexpected challenges, and the reasons rarely come down to the software itself. According to Gartner, between 55% and 75% of ERP projects fail to meet their original objectives, whether that means budget overruns, missed timelines, or unmet business goals. Panorama Consulting's research is similar, showing that more than 70% of ERP implementations fall short of their original business case.

These numbers tend to stay consistent year over year. What often makes the difference between success and difficulty isn't the platform chosen, but the consulting relationship that shapes the project from start to finish.

For mid-sized companies, the stakes feel higher. Enterprise organizations have the IT depth, governance structures, and budget reserves to recover from a difficult implementation. Smaller businesses typically keep scope narrow enough to avoid major setbacks. Mid-market companies sit in the middle, with enterprise-level complexity and small-business resources. That gap is where the consulting relationship matters most.

Below are the nine ERP consulting challenges that come up most often for mid-sized companies, with practical steps that can help you avoid each one.

1. Vendor bias in consulting recommendations

One of the most common challenges in ERP consulting involves consultants who hold reseller agreements, partnership tiers, or referral arrangements with specific software vendors. The recommendation that comes out of discovery may look like neutral advice, but it can be shaped by financial incentives that were in place before the engagement began.

This isn't always intentional. A consultant who has built their practice around one platform may genuinely believe that platform is the right answer for most clients, because it's the platform they know best. Either way, the recommendation can end up reflecting the consultant's economics rather than the buyer's operational needs.

How to address it: Ask early about the firm's vendor relationships. What reseller agreements does the firm hold? What partnership tiers? What referral fees does the firm earn when a recommended platform is implemented? A vendor-neutral consultant earns fees from you, not from the software vendor, and should be able to describe their revenue model clearly.

2. Enterprise methodology applied to a mid-market budget

Some consultancies use the same methodology with a 40-person manufacturer that they use with a Fortune 500 division. The deliverables may be smaller and the team leaner, but the underlying playbook tends to stay the same: long discovery phases, extensive documentation, multiple workshops per phase, and governance committees that may not fit a smaller organization.

For mid-sized companies, this approach can absorb a significant amount of the team's available time. A growing SMB typically has 10 to 15 people who can participate in workshops, and most of them have day-to-day responsibilities that can't be paused for weeks at a time.

How to address it: Ask the consultant to describe their process specifically for companies of your size. How many workshops are planned? How many hours per stakeholder? What gets documented, and what stays informal? The answer should be tailored to the kind of company they're working with, not pulled from a generic framework.

3. Vague objectives at project kickoff

"Modernize our ERP." "Improve efficiency." "Move off the legacy system." These are useful starting points, but they aren't measurable project objectives. Without specific targets defined before scoping, later decisions can become difficult to evaluate, because there's no concrete benchmark to refer back to.

This often happens when a project is initiated by a CFO or business owner who hasn't been close to operations day-to-day. The intent is clear, but the specifics get filled in later, sometimes during implementation when changes become costly.

Without measurable targets, the consultant is left to interpret what success looks like, and the buyer is left without a clear way to evaluate whether the project is on track.

How to address it: Before accepting a statement of work, document three to five concrete outcomes the new ERP must deliver. Examples might include closing the books in five business days instead of fifteen, consolidating intercompany reporting without manual reconciliation, or reducing work-order data re-entry by one full FTE. Specific outcomes translate into testable scope, while vague ones tend to translate into change orders.

4. Contract structures that create incentive mismatches

Fixed-bid contracts are popular with mid-sized buyers because they cap risk. The logic makes sense: lock in the cost, hold the consultant to it, and plan with confidence. In practice, fixed-bid contracts for ERP implementation can create incentive mismatches that affect the project's progress.

The dynamic is well-documented in the industry. The consultant may be incentivized to do the minimum that meets the contract, because every additional hour goes unpaid. The buyer may be incentivized to extract every possible deliverable, because the cost is fixed. Both sides typically understand the dynamic, and while the resulting behaviour is usually subtle, the project tends to absorb the friction either way.

How to address it: For parts of the project where scope is genuinely knowable, such as selection workshops, requirements documentation, and vendor evaluations, fixed fees can work well. For implementation, where unknowns play a larger role, a hybrid model often serves both sides better. Options include time-and-materials with a not-to-exceed ceiling, or phased fixed fees tied to defined deliverables. Asking the consultant which model they recommend, and why, can provide useful insight into their experience with mid-market projects.

5. Data migration scoped before the data is examined

Data migration is one of the most consistently underestimated parts of a mid-market ERP project. Industry research finds that 83% of ERP users report data issues during implementation, including corruption, incompleteness, or loss that causes operational disruptions. Panorama Consulting's data shows that roughly half of organizations significantly underestimate migration costs during planning.

The reason is structural. Migration is often scoped before the consultant has looked at the actual source data. By the time the legacy database is opened and the full history of part numbers, customers, and open transactions is in view, the budget is often already fixed.

How to address it: Ask for a short data audit before the migration line is priced. Two days of a consultant reviewing your actual master data, transactional history, and document attachments can surface most of the surprises that would otherwise come up mid-project. If the audit needs to be a separate engagement, it tends to be one of the most cost-effective steps in the entire project.

6. Integration mapping skipped during scoping

ERP rarely operates in isolation. It typically connects to a CRM, a shipping platform, a payment processor, a payroll system, an e-commerce front end, an EDI gateway, and sometimes a custom shop-floor application. Each connection has its own data shape, authentication model, and potential failure points. Industry research suggests that each missed upfront integration can add $5,000 to $50,000 in mid-project costs, and they rarely come up one at a time.

The pattern is consistent. Integration scoping is often done by walking the organizational chart, asking which departments need to share information. However, integrations follow the data, and the data follows workflows that may not be obvious from an org chart.

How to address it: Before the implementation contract is signed, produce an integration inventory. List every system the ERP will read from, every system it will write to, the trigger conditions, and the data volumes. A consultant who treats this as part of scoping, rather than a separate billable engagement, is approaching the project the way most mid-market companies benefit from.

7. Change management treated primarily as training

Change management is often included as a budget line item and a set of training sessions late in the project. Real change management, however, tends to start before configuration and continue past go-live, and it can be one of the highest-leverage investments in the project. Research by ProSci indicates that programs with strong organizational change management are six times more likely to achieve their goals. Gartner research finds that 55 to 75% of ERP projects that fall short of their objectives had insufficient training investment.

Change management is often underinvested because it's harder to scope than software configuration, harder to demonstrate, and harder to point to as a tangible deliverable. As a result, it tends to be one of the first areas trimmed when budgets tighten.

For mid-sized companies, the impact tends to be amplified. Without dedicated internal change champions or HR partners running adoption programs, the new system often lands on teams who weren't part of the design conversations. Frustration builds, workarounds emerge, and the value of the new platform gets eroded by inconsistent usage. By the time leadership notices, the team has often built informal processes around the gaps, and unwinding them takes longer than the original adoption would have.

How to address it: Ask the consultant who on their team owns adoption, how they approach change management, and what the hypercare model looks like for the first 30 to 45 days after go-live. A clear answer here tends to correlate with smoother adoption and fewer post-launch issues.

8. Customization without process review

Industry data suggests that around 93% of companies customize their ERP beyond the standard configuration. For mid-sized companies, customization is often where project budgets quietly expand. Each customization adds development hours, regression testing, future upgrade complexity, and a long-term dependency on whoever built it.

The deeper challenge is that customization often replicates a process that was already inefficient. A legacy system may have been patched around an awkward workflow years ago. When the new ERP gets customized to replicate the same patch, the underlying inefficiency moves into the new system instead of being resolved.

This tends to affect mid-sized companies more than either end of the market. Enterprises typically have architecture review boards that constrain customization. Small businesses often don't customize at all. Mid-market companies sit in between, with enough complexity to invite customization and not always enough governance to constrain it.

How to address it: Every proposed customization benefits from a process question first. Why does the workflow look this way today? What would it cost to change the workflow instead of changing the software? A consultant who explores the process question before quoting the customization is taking the approach that tends to serve mid-sized companies best.

9. Limited support during the post-go-live period

Go-live is sometimes treated as the finish line, but it's typically the start of value realization. The first 30 to 45 days after go-live is known as the hypercare period, when edge cases surface, users encounter issues they didn't see in training, and small misconfigurations can be caught before they become structural. Hypercare is one of the higher-value windows in the entire project, and limited support during this period can lead to issues that become more expensive over time.

A common pattern is for the lead consultant to move to the next account shortly after go-live, leaving the client team with a support contact who may not be familiar with the build. Issues that could be resolved in an hour during hypercare sometimes take weeks to address several months later.

How to address it: Before signing the contract, ask what the engagement looks like between week one and week twelve after go-live. Who from the project team stays on the account? At what allocation? With what response time? Consultants with experience in mid-market projects typically have this defined in writing.

How Cyberlobe approaches these challenges

The nine challenges above share a common pattern. Each is easier to prevent than to repair, and each is easier to identify when the consultant has no financial reason to overlook it.

Cyberlobe is a vendor-neutral ERP and CRM consultancy serving Canadian SMBs in the $3M to $30M range. We hold no reseller agreements, earn no vendor commissions, and operate no partnership tiers tied to platform revenue. Our ERP consulting work is built around buyer criteria: your operations, your data, your integration footprint, and your team's capacity for change.

If you're evaluating an ERP consultant, or you're already mid-project and want a second perspective on the consulting relationship, book a 20-minute discovery call. We'll listen to where the project sits, ask the questions a vendor-neutral consultant would ask, and share an honest view of whether we're the right fit.