Enterprise Architecture

ERP Contract Costs Year 2: Why the Real Expense Starts After Go-Live

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 29, 2026

There is a pattern that surfaces repeatedly in ERP advisory conversations. It rarely comes from organizations that are just starting their evaluation. It comes from organizations that went live twelve to eighteen months ago. Now they are looking at their renewal invoice or a new statement of work, and are trying to understand why the numbers look so different from what was budgeted.

The answer, more often than not, is not fraud or bad faith. It is something more structural. The way modern ERP contracts are designed means that Year 1 is often the most favorable year financially. The costs that matter most, the ones that compound, escalate, and expand. They tend to concentrate in Year 2 and beyond. Hence, understanding ERP contract costs year 2 is something most organizations do too late.

ERP contract costs year 2 surprises are now one of the most consistent themes in post-go-live advisory conversations. Yet almost no organization budgets for them at contract signing, because the Year 1 numbers look manageable. The vendor relationship feels strong after a successful go-live, and the categories driving the escalation often do not appear prominently in the original pricing proposal.

This blog breaks down the three primary drivers of post-go-live ERP cost escalation. Why do they tend to crystallize in Year 2 specifically? And also, what organizations can do to anticipate them before the invoice arrives.

The Ultimate ERP Playbook for Electronics Manufacturing - Tanner Rogers - Watch On-Demand

Why Year 1 Feels Affordable

Year 1 of an ERP contract is structured, in most cases, to minimize sticker shock. Initial license or subscription pricing is heavily negotiated, implementation costs are scoped tightly to secure the deal, and consumption charges are low because the system is not yet running at full operational volume. Discounts secured during procurement such as end-of-quarter concessions, bundled module pricing, waived onboarding fees usually apply in Year 1 and rarely carry forward at the same level.

By the time Year 2 begins, the system is live, the organizational dependency on it is real, and the negotiating leverage that existed before contract signing has largely disappeared. That is the environment in which ERP contract costs year 2 take effect.

The Three Drivers of ERP Contract Costs Year 2

AI Add-On Pricing: The Module That Wasn’t in the Original Scope

Most major ERP vendors have embedded AI-powered features such as intelligent automation, predictive analytics, anomaly detection, natural language interfaces, and generative document creation. Many are positioned as value-adds during the sales process, demonstrated during pre-sale demos as part of the core platform experience. What frequently becomes clear after go-live is that many of these AI capabilities are not included in the base subscription. They are licensed separately, often through an add-on module structure with its own pricing tier.

How this plays out in Year 2:

During ERP implementation, AI features are either turned off or in trial mode, so they do not affect Year 1 costs.
After go-live, end users begin requesting capabilities they saw in the demo which included AI-assisted forecasting, automated three-way match, intelligent expense categorization but only to discover these require additional licensing.
The vendor provides a quote. The quote was not in the original budget. Because the system is live and the business case is now visible, internal pressure to proceed is high but the leverage window closed at original contract signing.

Many vendors have also structured AI capabilities under consumption-based pricing models, meaning costs scale with usage volume rather than a predictable flat rate. This connects directly to the second driver.

The Fix: Before finalizing the original ERP contract, request a complete list of features demonstrated during the sales process and confirm explicitly which are included in the base subscription and which require separate licensing. Negotiate pricing for anticipated add-ons during the initial contract phase. This is the only point at which meaningful price protection is achievable.ve. They will matter far more than the features that work seamlessly.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Consumption-Based Pricing: The Cost That Grows With Your Success

Consumption pricing charges organizations based on actual resource utilization. Like, transaction volumes processed, API calls made, data storage consumed, compute capacity used, and increasingly, AI inference credits generated. In practice, it creates budget unpredictability that almost always manifests most acutely in Year 2.

During ERP implementation and the first months of go-live, transaction volumes are artificially low. Consumption charges in Year 1 reflect this reduced volume and they set a baseline expectation anchored in the budget for Year 2. By Year 2, the system is running at full operational capacity and the consumption charges reflect actual operations, representing a meaningful increase over Year 1 figures.

Common consumption categories that escalate in Year 2:

Consumption Category	Why It Escalates Post-Go-Live
Transaction processing	Full operational volume replaces partial rollout volumes
API call volumes	Integrations run at scale; third-party system connections multiply
Data storage	Transactional history accumulates; archive policies not yet established
AI inference credits	Features enabled post-go-live; usage grows as adoption increases
Report generation	Scheduled reports and ad-hoc queries increase as user confidence grows

By the time charges arrive in Year 2, the conversation about what was or was not contractually protected has already passed its point of influence

The Fix: During ERP contract negotiation, establish explicit annual spending caps covering total consumption costs regardless of usage category. Negotiate included consumption allocations that reflect projected Year 2 and Year 3 volumes, not Year 1 ramp-up volumes. Require vendor-provided real-time usage dashboards with threshold alerts so escalation is visible before the invoice arrives, not after.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Post-Go-Live Change Orders: The Budget Line Nobody Created

Change orders are perhaps the most predictable source of Year 2 ERP cost escalation. Yet they remain, consistently, the budget line that organizations fail to create. A separate and significant change order dynamic plays out after go-live that tends to be underestimated because it does not look like implementation scope creep. It looks like business-as-usual enhancement requests.

What post-go-live change orders actually look like in Year 2:

A business process configured during ERP implementation requires modification once real transaction volumes expose edge cases the original configuration did not anticipate.
A report flagged as a post-go-live enhancement is now actively needed by the finance team for a regulatory requirement.
An integration requires rework because a third-party system was updated and the connection broke.
A new business unit requires configuration and data migration not included in the original scope.

Each generates a change order priced at whatever rate the implementation partner charges for post-go-live work, which in most cases was never negotiated. Organizations arrive at Year 2 with a queue of enhancement requests and an implementation partner no longer operating under competitive pressure.

The Fix: During ERP implementation contract negotiation, establish pre-agreed rate cards for post-go-live support and enhancement work. These rates should be locked for a defined period (typically 24 to 36 months after go-live). And should cover the resource categories most likely to be needed: functional consultants, developers, project managers, and integration specialists. Create a dedicated post-go-live enhancement budget line in the overall ERP budget before go-live, not in response to the first invoice. more likely to support the implementation that follows.

Why Clients Almost Never Budget for This

In advisory conversations, the pattern is consistent: organizations build detailed implementation budgets that account for software l icensing, implementation services, data migration, training, and change management. They do not, in most cases, build a Year 2 budget that accounts for the categories described above.

There are structural reasons for this.

First, the budget cycle for ERP implementations tends to be organized around go-live as the financial finish line. Capital expenditure approvals, funding requests, and cost justifications are built around the implementation project. The ongoing operational cost structure including post-go-live escalation, receives comparatively less planning attention because it sits in a future budget cycle.
Second, vendors do not make Year 2 cost visibility easy. AI add-on pricing is often not surfaced clearly in initial proposals. Consumption pricing is quoted at ramp-up volumes that understate Year 2 actuals. Post-go-live support rates are not always included in implementation proposals because implementation partners prefer to quote those separately, closer to when the work begins and leverage has shifted.
Third, there is a natural optimism bias around go-live that compresses concern about future costs. After a successful implementation, the instinct is to celebrate the achievement rather than immediately analyze the forward cost trajectory.

The result is that ERP contract costs year 2 arrive as a surprise not because they were hidden, but because nobody created the model to anticipate them.

Conclusion

Year 1 of an ERP contract is designed to look affordable. Year 2 is where the commercial structure of modern ERP agreements begins to reflect the full ERP contract costs year 2 reality of running a live system at operational scale.

The three drivers: AI add-on pricing, consumption escalation, and post-go-live change orders are not surprises if they are anticipated. They become surprises because most organizations do not have a process for modeling ERP contract costs year 2 before the contract is signed, and because the categories involved are structured in ways that are easy to underestimate during procurement.

The best time to address all three is during the original contract phase. That is when competitive pressure gives buyers leverage over add-on pricing, when consumption cap language can be negotiated into the agreement, and when post-go-live rate cards can be locked. Once the system is live, that leverage is largely gone.

If your organization is currently in ERP contract negotiations or approaching renewal, ElevatIQ’s independent ERP advisory practice works with teams to model total cost of ownership across the full contract lifecycle, including the Year 2 cost structure that most procurement processes leave unmodeled. The advisory engagement is structured with no vendor affiliations and no implementation revenue, so the analysis reflects your commercial interests, not a vendor’s renewal incentives. Post-go-live is not the finish line. For ERP contract costs, it is often the starting line.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

ERP Contract Costs Year 2: Why the Real Expense Starts After Go-Live Read More »

ERP Vendor Shortlisting Mistakes: How Can ERP Buyers Fix Them?

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 27, 2026

Reaching the ERP vendor shortlist feels like crossing a major finish line. Your team has sat through discovery calls, reviewed capability decks, and narrowed a crowded field down to two or three serious contenders. There is a natural sense of relief at this stage and that relief, more often than not, is exactly where the trouble starts.

In practice, the phase between vendor shortlisting and final ERP contract signing is where some of the most consequential ERP vendor shortlisting mistakes quietly take root. The decisions made or skipped during this window frequently determine whether an implementation succeeds or struggles, regardless of which system ends up getting selected.

These are not exotic edge cases unique to poorly run projects. They are the same patterns, showing up across different industries and company sizes, often made by experienced teams who simply did not know what they did not know at this specific stage of the process. The good news is that each of them is recognizable in advance and fixable, if you know what to look for.

This blog walks through the most common ERP vendor shortlisting mistakes we observe, why they tend to happen at this particular stage, and what the corrective path looks like for each one. The goal is straightforward: if your organization is currently navigating the shortlist phase, or approaching it, understanding these ERP vendor shortlisting mistakes should help you structure it more deliberately.

Why the Post-Shortlist Phase Is Riskier Than It Looks

Most ERP selection frameworks focus heavily on the front end of the process. Such as, requirements gathering, longlist development, scoring frameworks, and demo planning. That attention is well placed. But the shortlist phase tends to receive comparatively less structured guidance, and that gap creates consistent exposure.

There are a few reasons for this:

Momentum shifts toward procurement. Once vendors are shortlisted, internal focus often pivots to contract negotiation and timeline planning, activities that feel productive but can crowd out continued evaluation rigor.
Vendor influence intensifies. Shortlisted vendors know they are in a competitive final stage. Commercial pressure, relationship-building, and deal-timeline urgency all increase. This is normal, but it can subtly compress the space for independent ERP assessment.
Organizational fatigue is real. By the time a shortlist is reached, many teams have been in evaluation mode for weeks or months. Decision fatigue can lower the quality of scrutiny at exactly the moment it needs to remain high.

Understanding these dynamics does not eliminate the risk, but it helps explain why capable organizations consistently make the same ERP vendor shortlisting mistakes at this stage. ERP vendor shortlisting mistakes at this stage.

The 8 Most Common ERP Vendor Shortlisting Mistakes

Treating the Shortlist as the Finish Line

The most common of all ERP vendor shortlisting mistakes is also the most understandable one. Once a long list of vendors is condensed to a shortlist, many organizations mentally shift into execution mode. Particularly, negotiating contracts, aligning timelines, and briefing stakeholders before the real evaluation work is actually done. Shortlisting narrows the field based on broad fit. It does not confirm deep fit. The gap between those two things matters significantly when the system goes live and real transactions start running through it.

What this looks like in practice: Teams skip structured scenario-based demos in favor of general presentations. Reference checks happen informally, if at all. Scoring criteria that were defined earlier in the process are not rigorously applied to shortlisted vendors because the decision already feels made.

The Fix: Treat the shortlist as the beginning of the detailed ERP evaluation phase, not the end of it. Define a structured shortlist-to-selection process with its own scope such as scripted scenario demos, weighted scoring against your actual requirements, and reference checks designed around your industry and transaction complexity.

Letting Vendors Control the Demo Script

Demo presentations are where ERP vendors are at their most polished. Most vendors are genuinely skilled at showing their system at its best, and there is nothing inherently wrong with that it is a reasonable part of any sales process. The problem arises when organizations passively accept the vendor’s standard demo script and treat the output as a reliable picture of how the system would actually behave in their environment. Standard demos are built to highlight strengths. They rarely surface the scenarios most likely to be complex or problematic for your specific business.

Common demo blind spots that go undetected:

Business Scenario	Why It Gets Skipped in Standard Demos
Multi-entity consolidation	Requires specific configuration not set up in demo environments
Complex inventory workflows	Generic demos show simple warehousing, not layered fulfillment logic
Landed cost calculations	Rarely demoed; usually covered with vague confirmation of capability
Regulated reporting requirements	Industry-specific outputs are seldom pre-built in demo tenants
Integration with existing legacy systems	Vendor focuses on native functionality, not integration edge cases

The Fix: Require scripted demos built around your actual business scenarios. Before the demo, prepare a set of specific use cases drawn from your current process pain points and your most complex transaction types. Ask vendors to walk through those scenarios live not from a pre-loaded environment, but using configurations representative of your business model. Document the business process gaps you observe. They will matter far more than the features that work seamlessly.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Evaluating the Vendor Without Evaluating the Implementation Partner

ERP systems are not implemented by the software vendor alone. In most mid-market and enterprise implementations, a separate implementation partner, a systems integrator or consulting firm does the majority of the configuration, data migration, integration development, and go-live support work. The quality of that implementation partner frequently has as much influence on project outcomes as the software itself.

It is surprisingly common for organizations to reach final contract negotiations with a shortlisted ERP vendor without having clearly identified which ERP implementation partner will be involved, or having evaluated that partner’s capabilities for their specific industry and project scope. Implementation partner selection often gets treated as a downstream decision, something to sort out after the software contract is signed. By that point, leverage is limited and the risk is already embedded in the project structure.

The Fix: Evaluate implementation partners in parallel with the software evaluation, not after it.

Ask each shortlisted vendor to identify their recommended partners for your region and industry vertical.
Request separate capability demonstrations from those partners not just the software vendor presenting their ecosystem.
Check references on the specific partner’s delivery track record, not just the software’s general customer base.
Treat implementation partner fit as a meaningful factor in your final vendor decision, because operationally, it is.

Negotiating Price While Overlooking Contract Terms

Among the costlier ERP vendor shortlisting mistakes, negotiating price while overlooking ERP contract terms is one that tends to surface only after the contract is signed. End-of-quarter pricing conversations and license discount negotiations can absorb a disproportionate share of attention during the post-shortlist phase. Securing a favorable per-user rate feels like a tangible win and it often is but it can come at the cost of careful attention to the contract terms that govern the entire relationship going forward.

The commercial terms embedded in ERP contracts frequently contain provisions that create significant financial exposure over time:

Indirect access definitions that expand licensing obligations as third-party integrations grow
Auto-renewal clauses with compressed notification windows that eliminate renegotiation leverage
Support tier structures that separate base entitlements from critical incident response capabilities
Acceptance criteria language that is vague enough to create disputes when system performance falls short after go-live
Price escalation provisions embedded in multi-year subscription terms

None of these are inherently bad-faith provisions. They are standard commercial structures that vendors have refined over many contract cycles. But buyers who are focused primarily on headline pricing often accept these terms without fully understanding the downstream implications.

The Fix: Treat ERP contract review as a parallel workstream to price negotiation not a formality that follows it. Pay particular attention to the difference between response time SLA commitments and resolution time commitments. Review how indirect access is defined, especially if your architecture will include third-party integrations or API-connected systems. Ensure acceptance criteria are specific enough to be enforceable if system performance falls short post-go-live.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Losing Internal Stakeholder Alignment After the Shortlist

ERP evaluations typically build strong internal momentum in the early phases such as discovery workshops, stakeholder interviews, cross-functional requirement sessions. By the time a shortlist is reached, that engagement tends to taper off. Leadership may have shifted focus to other priorities. End users who participated in the requirements phase may not have been informed of how their input influenced the shortlist. Functional department heads who were active contributors early on often feel progressively disconnected as the process becomes increasingly IT- and procurement-led.

This erosion of alignment creates a specific and predictable problem: by the time the final vendor is selected and implementation planning begins, organizational buy-in for the project has quietly deteriorated. The resulting change management challenge is substantially harder to address than it would have been if stakeholder engagement had been maintained throughout.

Signs that alignment is eroding post-shortlist:

Department heads stop attending evaluation-related meetings
Questions about the selection rationale resurface after the decision is announced
Key functional users express skepticism about whether their requirements were heard
Implementation kickoff meetings reveal assumptions that differ significantly across teams

The Fix: Keep cross-functional stakeholders actively informed and involved throughout the shortlist-to-selection phase. Share demo observations with department representatives. Be transparent about evaluation criteria and scoring. When the final decision is made, communicate the rationale clearly not just to executive leadership, but to the functional teams who will actually use the system. The teams who understand why a decision was made are meaningfully more likely to support the implementation that follows.

Skipping a Defined Success Framework Before Final Selection

One of the quieter gaps in post-shortlist evaluation is the absence of a formally defined success framework. A clear articulation of what a successful ERP implementation actually looks like, in measurable terms, before the contract is signed.

Without this, there is no shared baseline against which implementation progress can be assessed. Vendors and implementation partners may define milestones in ways that satisfy contractual obligations without necessarily delivering business outcomes. Go-live becomes the de facto definition of success, even when the system’s actual performance against real business requirements has not been validated.

Success criteria defined after contract signing are significantly harder to make enforceable. Criteria defined before signing and referenced in the contract itself, provide the foundation for genuine accountability throughout the project.

What a success framework should include:

Dimension	Example Criteria
System performance	Transaction processing time thresholds under peak load
Data migration accuracy	Acceptable error rates for master data and open transactions
Integration functionality	Verified data flow between ERP and key connected systems
User acceptance	Functional sign-off from department leads before go-live approval
Reporting capability	Confirmed generation of required regulatory and operational reports

The Fix: Before finalizing ERP vendor selection, document a set of specific, measurable success criteria tied to your actual business processes. Ensure these criteria are referenced in the contract’s milestone and acceptance provisions not left as informal expectations that become impossible to enforce when performance gaps emerge post-implementation.

Underestimating Data Migration Complexity at This Stage

Post-shortlist discussions tend to focus heavily on software capabilities and commercial terms. Data migration, the process of extracting, cleaning, transforming, and loading data from legacy systems into the new ERP often receives minimal attention until implementation planning begins in earnest.

This is a costly deferral. Data quality issues that exist in legacy systems do not disappear when a new ERP is implemented. They surface during migration, often in ways that create significant delays and cost overruns. Organizations that have not begun to assess the state of their data at the shortlist stage frequently encounter data remediation as an unplanned project within the project, one that compresses timelines and inflates budgets that were established without accounting for it.

The Fix: During the shortlist phase, initiate a preliminary data readiness assessment. This does not require a complete data audit, but should involve a structured review of key data domains:

Customer and vendor master records
Item and product masters
Open purchase orders and sales orders
Historical transactional data required for reporting continuity
Chart of accounts and financial period structures

Understanding the scale of data remediation required will affect implementation timeline estimates, partner resource requirements, and in some cases, the final vendor decision itself. Particularly when system-to-system migration complexity varies across shortlisted options.

Accepting the Vendor’s Proposed Implementation Timeline Without Scrutiny

Vendor-proposed ERP implementation timelines are constructed during the sales process, and that context matters. A shorter, more confident timeline is a commercial asset. It signals capability, reduces perceived disruption, and makes the overall investment look more manageable. The problem is not bad faith. It is that these timelines are almost always built on best-case assumptions: clean data, available internal resources, straightforward integrations, and a configuration scope that reflects high-level requirements rather than real-world complexity.

Organizations that accept these timelines without independent scrutiny sign contracts anchored to go-live dates that are structurally difficult to meet. When dates begin to slip, the pressure to recover schedule creates predictable downstream damage. The scope gets compressed, user acceptance testing gets shortened, training gets rushed, and data migration quality checks get deprioritized. The go-live happens on time, but the system is not ready for it.

What drives timeline slippage most often:

Data migration complexity is underestimated because no readiness assessment has been completed at contract signing
Internal resource availability is assumed at levels that conflict with ongoing operational responsibilities
Integration development timelines assume first-pass success with no rework cycles
Change management and training are scheduled in parallel with configuration rather than sequentially

The Fix: Validate any vendor-proposed timeline against reference checks from organizations of similar size and complexity that implemented the same system. Ask specifically how actual timelines are compared to original proposals. Conduct an internal resource availability assessment before accepting the schedule. Where the timeline cannot be independently validated, negotiate milestone structures with formal review points rather than locking a go-live date before ERP implementation scope is fully understood.

The Conclusion

Most of the ERP vendor shortlisting mistakes described above share a common thread: they happen when the post-shortlist phase is treated primarily as a procurement exercise rather than as a continuation of the evaluation and planning process. The vendor shortlisting decision narrows the field to credible options. It does not on its own, guarantee a successful implementation. The work that happens between shortlist and contract signing often determines whether the organization is set up for a manageable project or a preventable struggle.

Avoiding ERP vendor shortlisting mistakes at this stage requires more than good intentions — it requires a structured process that keeps evaluation rigor, stakeholder alignment, and commercial scrutiny running in parallel, even as the finish line feels close. Independent advisory support tends to be most valuable at precisely this stage. The decisions being made are high-stakes, the vendor relationships are actively influencing the process, and internal teams are often managing competing priorities that make it difficult to maintain the necessary depth of scrutiny. An outside perspective, one with no commercial stake in which vendor gets selected or which implementation partner gets the work, helps organizations ask the questions that are easy to defer until it is too late to ask them effectively.

If your organization is currently navigating the post-shortlist phase, or approaching it, ElevatIQ’s independent ERP advisory practice works with companies to structure this phase in a way that reduces implementation risk before contracts are signed. As a vendor-agnostic firm with no ERP resale relationships or implementation revenue, the guidance is structured entirely around your organization’s outcomes not ours. The post-shortlist phase is short. The consequences of the decisions made during it are not. It is worth getting right.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

ERP Vendor Shortlisting Mistakes: How Can ERP Buyers Fix Them? Read More »

ERP Readiness Assessment: How to Know If Your Organization Is Actually Ready

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 22, 2026

There is a conversation that almost never happens before an ERP project begins. Vendors do not initiate it because it risks killing a deal. Implementation partners do not initiate it because their engagement depends on the project proceeding. Internal champions do not initiate it because they have already staked their credibility on the initiative moving forward.

That conversation is this: Is your organization actually ready for this?

Not ready in the sense of having a signed contract and an allocated budget. Ready in the sense of having the organizational conditions, process maturity, data quality, leadership alignment, and internal capacity. Particularly to make an ERP implementation likely to succeed rather than likely to become another failure statistic.

A genuine ERP readiness assessment: one designed to surface hard answers rather than confirm predetermined conclusions. It is among the highest-return activities an organization can perform before committing to an ERP project. It is also among the rarest.

Why a Genuine ERP Readiness Assessment Is Rarely Done Honestly

The ERP industry has a structural incentive problem when it comes to readiness. Every party with visibility into an organization’s readiness has a financial interest in the project proceeding.

ERP vendors assess “readiness” through discovery processes designed to qualify the opportunity and confirm budget authority. Implementation partners conduct “readiness workshops” that build stakeholder excitement and demonstrate methodology, not rigorous diagnostic tools. Internal project sponsors, who typically carry the initiative through the business case and executive approval process, are rarely positioned to objectively decide. Particularly, if the project should be delayed, or if foundational work needs to happen first.

The result is that organizations routinely begin ERP implementations while carrying unresolved conditions that will compromise the project. The first honest readiness assessment they receive comes from the post-mortem after the project fails. This is precisely the gap that independent assessment fills. An advisor with no stake in whether the project proceeds can conduct an ERP readiness assessment without a conflict of interest.

What an ERP Readiness Assessment Actually Looks For

Unreadiness for ERP does not announce itself clearly. It hides behind enthusiasm, business case projections, and vendor demos that make everything look achievable. These are the specific conditions that, when present, predict implementation difficulty. Particularly, with enough consistency to warrant serious attention before the project starts.

Leadership Alignment That Is Surface-Deep

ERP implementations require sustained, active executive sponsorship, not a signed approval and quarterly attendance at steering committee meetings. They require executives who understand that the initiative will demand difficult decisions about process standardization. They should accept that departments will need to relinquish some autonomy to achieve cross-functional integration. Also, they are prepared to use their authority when organizational resistance requires it.

The signal to look for is not whether executives say they are supportive. Nearly all of them will. The signal is whether they can articulate, in specific operational terms. What they expect to change and what trade-offs they are willing to make to achieve it. Executives who describe ERP benefits in technology terms, without process-level specificity, have often not engaged deeply enough. Particularly, with what implementation will actually require of them and their teams.

What will this ERP implementation change about how we operate? Often, executives across the leadership team have materially different answers to this question. This misalignment usually reveals itself as project conflict during implementation, often at the most expensive possible moment.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Process Documentation That Does Not Exist

ERP implementation requires translating business processes into system configuration. That translation is only as accurate as the organization’s understanding of its own processes and in many organizations, that understanding lives informally in the heads of experienced people rather than in documented, validated process maps.

When current-state processes are not documented, the implementation partner builds a picture of how the organization operates from workshop conversations, which are subject to incomplete recall, departmental perspective bias, and the tendency of people to describe how processes are supposed to work rather than how they actually work. Configuration built on that picture produces a system that works for the idealized version of the process, not the operational reality and the gap surfaces during testing in the form of scenarios the configuration cannot handle.

A practical ERP readiness assessment checks not whether documentation exists in some form, but whether it accurately reflects current operational reality, covers exception scenarios alongside standard paths, and has been validated by the people who actually execute the processes rather than only the managers who oversee them.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Data Quality That Has Never Been Assessed

Master data: the customer records, vendor records, item masters, and chart of accounts. Also, other foundational data that every ERP transaction depends on is one of the most reliable ERP implementation failure predictors. It is one of the conditions most consistently left unassessed before projects begin.

The reason is that data quality assessment requires looking at the actual data, applying defined quality criteria, and reporting the results, a process that surfaces problems organizations would often prefer to defer. Item masters with duplicate records, inconsistent units of measure across locations, missing cost data, and inaccurate lead times are common findings. Customer records with duplicate accounts, inconsistent address formats, and missing credit terms are equally common. These are not trivial issues. They are conditions that, left unresolved, migrate into the new ERP and immediately begin creating the same operational problems the organization implemented the new system to escape.

An ERP readiness assessment that does not include a data profiling exercise against the key master data objects in scope is incomplete. The results of that profiling exercise should inform the project timeline and resource plan, not be discovered as a crisis during data migration.

Internal Capacity That Has Been Underestimated

Every ERP implementation requires significant internal resource commitment from the organization being implemented. Subject matter experts need to participate in requirements workshops, review and validate process designs, participate in conference room pilots, support user acceptance testing, and deliver training to their colleagues. These activities take time, real time, measured in hours per week over months that must come from somewhere.

The somewhere, in most organizations, is the operational workloads of the people who are most knowledgeable about the business processes. The best candidates for implementation participation are almost always the people who are most operationally stretched. The tension between their implementation responsibilities and their operational responsibilities, if not explicitly managed, produces an implementation team that is perpetually behind on project work and an operation that is perpetually understaffed.

An ERP readiness assessment that takes internal capacity seriously asks: have the specific individuals required for implementation participation been identified? Has the time commitment been quantified, not estimated vaguely, but specified in hours per week for each project phase? Have operational backfill plans been developed for the periods when those individuals will be most heavily committed? Organizations that cannot answer these questions with specificity before the project begins are likely to encounter capacity problems that extend the timeline, reduce the quality of business input, and increase the cost of implementation.

A Change Management Capacity That Has Not Been Built

ERP implementations do not fail because the technology does not work. They fail because the organizational change required to operate the technology differently does not happen. That change requires active management: communication, training, stakeholder engagement, resistance management, and leadership reinforcement. None of which is delivered automatically by the ERP implementation itself.

An ERP readiness assessment that addresses change management evaluates whether the organization has identified the following:

Who is accountable for change management?
Whether a budget and resource plan for change management activities exists.
Whether leadership has accepted that change management is a parallel workstream with its own deliverables rather than a set of activities that the implementation team will handle alongside the technical work.

Organizations that treat change management as a line item to be reduced when budget pressure arises, or as a vague responsibility that everyone shares and therefore no one owns, are structurally unprepared for the adoption challenge that every significant ERP implementation creates.

ERP Readiness Assessment: The Indicators That Signal a Real Go-Ahead

An ERP readiness assessment is not designed to find reasons to stop a project. It is designed to create an honest picture of where the organization stands so that the gaps between current state and required readiness can be addressed before, not during, the implementation. These are the conditions that indicate genuine readiness:

Process owners who can make decisions. The people who will be accountable for process design decisions in the new system are identified, available, and have the organizational authority to commit to future-state process designs without requiring approval from multiple layers of hierarchy for every design choice.
A data quality baseline. The organization has assessed the quality of its key master data objects. It understands where the problems are and has a remediation plan with ownership and timeline. Which is integrated into the project plan rather than treated as a separate, deferred activity.
Realistic timeline expectations. Leadership understands that ERP implementations take longer than vendors typically propose, cost more than initial estimates suggest, and require sustained resource commitment from the organization and has built those realities into their planning rather than anchoring to the optimistic scenario in the sales presentation.
A defined problem to solve. Projects anchored to vague benefits like “improved visibility” and “better integration” lack the specificity needed to make configuration decisions, evaluate system performance, or hold the implementation accountable for delivering value.
Organizational willingness to change processes. Leadership has explicitly accepted that the implementation will require process changes, not just technology changes and has communicated that standardization may override departmental preferences where standardization serves the overall organization. Implementations where every department is allowed to preserve its existing processes by customizing the system around them produce technically delivered projects that fail to achieve business transformation.

What an ERP Readiness Assessment Gap Means for Project Timing

Discovering readiness gaps before an ERP project begins is not a reason to abandon the initiative. It is a reason to sequence the work correctly. Process documentation gaps can be addressed through a pre-implementation process documentation and redesign phase. Typically two to three months for a focused effort, and an investment that pays dividends not just in implementation quality but in operational clarity that the organization benefits from regardless of the ERP project.

Data quality gaps can be addressed through a master data cleansing and governance initiative that runs parallel to or slightly ahead of the ERP implementation. Organizations that defer this work to the migration phase, hoping to clean data under implementation pressure consistently produce worse outcomes than those that address it before the project clock is running.

Internal capacity gaps can be addressed through explicit resource planning, backfill hiring, or scope and timeline adjustment that reflects realistic resource availability rather than optimistic assumptions. None of these is a comfortable conversation to have before a project begins. All of them are significantly more comfortable than the same conversation mid-implementation.

The Role of Independent Assessment

Independent ERP advisors bring a diagnostic framework, pattern recognition from repeated implementation cycles, and the absence of a conflict of interest that makes genuine honesty possible. That combination is difficult to replicate internally when the people closest to the readiness question also have a stake in the project proceeding.

ElevatIQ’s organizational readiness practice provides organizations with an objective ERP readiness assessment before they commit to a vendor contract, available through our organizational ERP readiness and ERP selection services. The organizations that get the most from ERP investment are the ones that were ready when implementation began.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

ERP Readiness Assessment: How to Know If Your Organization Is Actually Ready Read More »

ERP Training Strategy: Building Organizational Competency

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 20, 2026

ERP training is one of the most consistently underestimated components of an ERP implementation program. Organizations invest significant effort in selecting systems, defining requirements, and configuring workflows, yet often treat training as a compressed activity toward the end of the project. This creates a structural imbalance: the system may be ready at go-live, but the organization is not.

The consequences rarely appear as immediate system failure. Instead, they emerge gradually through user behavior. Teams revert to spreadsheets when the system introduces friction, data is entered inconsistently across functions, and process discipline begins to erode under operational pressure. Over time, these behaviors compound, affecting reporting accuracy, operational efficiency, and ultimately confidence in the ERP system itself.

An effective ERP training strategy addresses this problem at its root. It is not designed to ensure that users attend sessions or complete modules. It is designed to ensure that users can execute their responsibilities within the system with consistency, understand the implications of their actions, and maintain that capability as processes evolve.

Your ERP Strategy Is About to Break - Sandeep Chopra - Watch On-Demand

What Most ERP Training Gets Wrong

ERP training programs often fail not because of lack of effort, but because they are structured around the wrong objective. Most training is designed to teach system functionality rather than operational execution. Users are introduced to screens, navigation paths, and transaction steps, but are expected to translate that knowledge into real-world processes on their own.

This disconnect becomes visible as soon as users move beyond controlled training scenarios. ERP usage is not transactional in isolation — it is process-driven. Tasks are interdependent, data flows across functions, and decisions made at one step affect outcomes downstream. When training does not reflect this reality, users develop a fragmented understanding of the system.

Two specific gaps tend to emerge.

First, users lack context. They may know how to execute a transaction, but not when it should be performed, what conditions must be satisfied beforehand, or how their inputs affect other teams. This leads to inconsistent execution even when users believe they are following the system correctly.
Second, training rarely prepares users for exceptions. ERP systems are demonstrated under ideal conditions, but real operations involve incomplete data, process deviations, and edge cases that require judgment. Without guidance, users either improvise or revert to manual workarounds, both of which undermine system integrity.

An ERP training strategy that does not address these issues effectively teaches users how the system works, but not how the business operates within it. but not how the business operates within it.

Role-Based Training: Aligning Learning with Work Reality

The most effective ERP training strategies begin by aligning training with how work is actually performed rather than how the system is structured. ERP platforms are organized into modules for technical and configuration purposes, but users operate across processes that span those modules. When training mirrors system structure, users are forced to reconstruct their responsibilities from disconnected pieces of information.

Role-based training addresses this by organizing learning around workflows. It presents tasks in the sequence they occur in real operations and connects them to upstream and downstream activities. This allows users to build a coherent understanding of their role within the broader process rather than memorizing isolated steps.

A well-designed role-based training model ensures that users understand not just execution, but responsibility. This includes clarity on what data they are accountable for, how errors propagate through the system, and how to validate that their work has been completed correctly.

In practice, this requires training to cover four core dimensions:

End-to-end process flow, so users understand how their work connects across functions
Data ownership, ensuring accountability for accuracy and consistency
Exception handling, preparing users for non-standard scenarios
Validation and reporting, enabling users to verify outputs independently

When these elements are included, training shifts from instruction to comprehension. Users are no longer dependent on memorized steps, they understand how to operate within the system as part of a larger process.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Training Timing: Retention and Application

Training timing is often treated as a logistical decision rather than a strategic one. In many ERP implementations, training is delivered early to ensure completion within project timelines. While this approach satisfies scheduling requirements, it creates a gap between learning and application that significantly reduces retention.

By the time users interact with the system in a live environment, much of the training has been forgotten. This results in hesitation, increased error rates, and a higher dependency on support resources during the most critical phase of adoption. An effective ERP training strategy aligns training delivery with actual system usage. Users should be trained close enough to go-live that knowledge remains fresh, but with sufficient time to practice and reinforce what they have learned.

A structured approach typically includes:

Core training delivered within a few weeks of go-live
Hands-on practice using realistic scenarios in a sandbox environment
Focused reinforcement sessions to address gaps before system launch

The most critical element is hands-on practice. Without it, training remains theoretical. Users need to experience real workflows, encounter issues, and resolve them in a controlled environment before they are expected to perform in production.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Super-User Development: Building Internal Capability

Super-users are often included in ERP implementations, but their role is frequently underutilized. When structured properly, they become the internal capability that sustains the system beyond go-live.

Unlike external consultants, super-users operate within the organization’s context. They understand how processes are executed, where friction occurs, and how users interact with the system in practice. This allows them to provide immediate support, reinforce process discipline, and act as a bridge between system design and operational reality. However, these outcomes depend on how super-users are developed. Simply identifying individuals and providing additional training is not sufficient. The role requires intentional structure.

Effective super-user programs prioritize:

ERP selection based on process expertise and credibility within the organization
Deeper training that includes exposure to system logic and design decisions
Dedicated capacity to support users post-go-live
Ongoing engagement to ensure knowledge remains aligned with system changes

Organizations that invest in super-user capability create a sustainable support model that reduces dependency on external resources and improves long-term system stability.

Training Materials: From Documentation to Usable Knowledge

Training materials are often treated as static deliverables created for go-live, but their value depends on how well they support ongoing usage. Traditional approaches rely on comprehensive manuals that attempt to document the entire system. While thorough, these materials are difficult to maintain and rarely used in day-to-day operations.

As processes evolve, these documents quickly become outdated. Users lose trust in them, and knowledge shifts back to informal channels such as peer support or undocumented workarounds. A more effective ERP training strategy treats training materials as living assets. Content should be structured around how users access information during work, not how systems are documented.

This typically involves:

Process-focused guides that reflect real workflows
Role-specific content tailored to user responsibilities
Modular formats that allow updates without rewriting entire documents
Visual or video-based walkthroughs for complex processes

Equally important is ownership. Training materials must have a defined owner responsible for maintaining alignment with the system. Without this, documentation gradually diverges from reality and loses its value.

Measuring Training Effectiveness

Training effectiveness is often measured through completion metrics, but these provide limited insight into whether users are prepared to operate the system. Participation does not equate to competency. An ERP training strategy focused on outcomes requires performance-based evaluation. This involves assessing whether users can execute key workflows accurately and consistently, both before and after go-live.

Indicators of training effectiveness include:

Accuracy of transaction execution in test environments
Patterns in post-go-live support requests
Error rates in critical business processes
Degree of reliance on system versus external workarounds

These metrics provide a more accurate view of where training gaps exist. They allow organizations to intervene early, before issues become embedded in daily operations. Importantly, they should be used to improve training design, not to evaluate individual performance.

Training as a Structural Component of ERP Success

ERP success is often associated with system selection and implementation quality, but these factors do not determine outcomes in isolation. A system that is technically sound but poorly understood will not deliver value. Conversely, a system that is consistently used and well understood can produce reliable results even with limitations. This highlights a broader principle: ERP systems do not fail in isolation, they fail when users are not equipped to operate them effectively.

Training is the mechanism that connects system design to operational execution. It determines whether processes are followed consistently, whether data remains reliable, and whether the system becomes embedded in daily work. For this reason, ERP training strategy should be treated as a structural component of implementation, not as a supporting activity.

Conclusion

ERP training strategy is not simply about preparing users for go-live. It is about building the internal capability required to operate, sustain, and evolve the system over time. Organizations that treat training as a short-term activity often encounter long-term challenges in adoption, data quality, and process consistency, even when the system itself is well designed.

Independent ERP advisors can provide meaningful value in this process by helping organizations design training strategies that align with how work is actually performed, rather than relying on generic delivery models. This includes structuring role-based training, developing super-user networks, and ensuring that training timing and measurement frameworks support long-term adoption.

Organizations navigating ERP implementation can benefit from the vendor-neutral perspective that ElevatIQ brings through its ERP Implementation and Change Management and ERP Optimization advisory services. Building the system is only part of the effort. Thus, ensuring that people can use it effectively, consistently, and confidently is what ultimately determines whether that system delivers lasting value.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

ERP Training Strategy: Building Organizational Competency Read More »

ERP Integration Architecture: Why Most Digital Ecosystems Break Down

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 15, 2026

The ERP system is rarely the only platform an enterprise operates. Most organizations run a layered digital ecosystem including CRM, warehouse management, eCommerce, EDI, business intelligence, and a growing set of specialized applications. All of which need to exchange data with the ERP at different speeds, frequencies, and levels of reliability. The way these connections are designed determines whether the ecosystem behaves as a coordinated system or as a fragile network of dependencies.

ERP integration architecture is not simply about connecting systems. It is about defining how information moves through the organization, how consistent that information remains across systems, and how resilient those connections are under operational stress. Poor integration design does not fail immediately. It degrades gradually, until inconsistencies, delays, and failures begin to affect core business processes.

Why ERP Integration Architecture Decisions Matter Early

Integration is often treated as a downstream activity in ERP programs. The primary focus during planning is typically on core ERP functionality, module selection, and configuration. Integration is deferred, with the assumption that systems can be connected as needed once the ERP is in place. This sequencing introduces structural risk.

When integration is approached reactively, each connection is built to solve an immediate need. A CRM integration is implemented to synchronize customer data. A warehouse system is connected to support inventory updates. A reporting layer is added to extract transactional data. Each integration works in isolation, but no overarching design governs how they interact.

Over time, this leads to three predictable outcomes:

Accumulated technical debt: Each integration uses different patterns, tools, and assumptions.
Inconsistent data states: Systems fall out of sync because there is no defined source of truth.
Increased fragility: A change in one system has unintended consequences across multiple integrations.

These issues are rarely visible at go-live. They emerge as transaction volumes increase, systems evolve, and dependencies multiply. Defining ERP integration architecture early forces organizations to answer foundational questions before implementation begins: what systems will exchange data, what those data flows represent in business terms, and what level of consistency and latency is acceptable. Without these answers, integration becomes an accumulation of tactical solutions rather than a designed system.

Real-Time vs. Batch: A Decision About Business Behavior, Not Technology

One of the most misunderstood decisions in ERP integration architecture is whether to use real-time or batch integration. This is often framed as a technical choice, but it is fundamentally a business decision about how quickly information needs to move to support operations.

Real-Time Integration: Where It Adds Value and Risk

Real-time integration is appropriate when a delay in data creates immediate operational consequences. For example, if an eCommerce platform displays inventory availability that is not current, customers may place orders that cannot be fulfilled. Similarly, credit validation during order entry requires up-to-date financial data.

However, real-time integration introduces coupling between systems. When one system depends on another to respond immediately, any delay, outage, or failure propagates across the workflow. This creates a chain of dependency where system reliability becomes interdependent.

In practice, organizations often underestimate the operational requirements of real-time integration:

APIs must handle peak loads, not average volumes
Error handling must account for partial failures
Retry mechanisms must prevent data duplication or inconsistency
Monitoring must detect failures before they impact business operations

Additionally, real-time integration has commercial implications. Many ERP vendors impose API rate limits or charge based on transaction volume. A design that appears technically sound can become financially unsustainable if these factors are not considered.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Batch Integration: The Default That Is Often Overlooked

Batch integration is often treated as a legacy approach, but in many cases, it is the more appropriate design choice. When business decisions do not require immediate data synchronization, batch processing offers stability and efficiency.

Financial postings, reporting data extraction, and master data synchronization are typically well-suited to batch processing. These processes benefit from controlled execution windows, reduced system load, and simpler error handling.

The key mistake organizations make is defaulting to real-time integration without a clear business requirement. Real-time becomes the default because it appears more modern, not because it is necessary. This increases system complexity without delivering proportional value. A well-designed ERP integration architecture uses real-time selectively and defaults to batch wherever latency does not affect decision-making.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Middleware: Control Layer or Additional Complexity?

As integration points increase, organizations face a structural choice: continue building direct system-to-system connections or introduce a middleware layer to manage integrations centrally. Middleware platforms, including iPaaS tools like MuleSoft, Boomi, and Workato, provide capabilities for data transformation, routing, monitoring, and error handling. In theory, they simplify integration management. In practice, their effectiveness depends on how they are implemented.

When Middleware Solves the Right Problem

Middleware becomes valuable when:

Multiple systems need to exchange data in different formats
Integrations require centralized monitoring and control
Business logic needs to be decoupled from individual systems
The integration landscape is expected to grow over time

In these scenarios, middleware acts as an abstraction layer that reduces direct dependencies between systems.

When Middleware Introduces New Risks

However, middleware is not inherently beneficial. When implemented without a clear architectural role, it can introduce additional complexity:

It becomes another system to manage and maintain
Performance bottlenecks may emerge if not properly scaled
Integration logic becomes distributed between systems and middleware
Skills required to manage the platform may not exist internally

One of the most common mistakes is selecting a middleware platform before defining integration requirements. This often leads to architecture being shaped by tool capabilities rather than business needs.

Another overlooked factor is vendor policy. ERP vendors may restrict API access, impose additional costs for integration tools, or limit compatibility with third-party platforms. These constraints must be evaluated during architecture design, not after implementation. Middleware should be selected as a response to architectural needs, not as a default solution.

Integration Governance: The Difference Between Architecture and Entropy

Even well-designed integration architectures degrade without governance. Over time, systems change, new integrations are added, and existing connections are modified. Without defined processes, these changes introduce inconsistencies and hidden dependencies. Integration governance establishes how decisions are made and how integrations are maintained. It answers questions that are often left implicit:

Who owns integration design decisions?
How are integrations documented and versioned?
What testing is required before deployment?
How are changes in one system communicated to dependent systems?

In the absence of governance, integration environments tend to evolve into undocumented systems where knowledge is distributed across individuals rather than captured in design artifacts. A common failure pattern is reliance on specific developers or consultants who understand how integrations work. When those individuals are no longer available, debugging becomes significantly more difficult.

Effective governance does not require complex processes. It requires consistency. Documentation standards, ownership clarity, and change management protocols ensure that the architecture remains coherent over time.

Failure Patterns in ERP Integration Architecture

ERP integration issues rarely present as immediate failures. They manifest gradually as the system landscape becomes more complex. Recognizing common failure patterns helps organizations identify risks early.

Point-to-Point Proliferation: Organizations begin with a few direct integrations. As new requirements emerge, additional connections are added without a centralized design. Over time, the number of integrations grows exponentially, creating a network that is difficult to manage.
Undefined Source of Truth: When multiple systems maintain overlapping data, inconsistencies arise. Without a clear definition of which system owns specific data elements, synchronization becomes unreliable.
Overuse of Real-Time Integration: Systems become tightly coupled, increasing the impact of failures. A delay in one system affects multiple downstream processes.
Lack of Monitoring and Observability: Failures are detected only after they impact business operations. Without centralized monitoring, issues remain hidden until they create visible problems.
Vendor Dependency Constraints: Integration design is limited by vendor policies, such as API restrictions or additional costs, which were not considered during architecture planning.

These patterns do not emerge from poor technical execution. They result from the absence of architectural discipline.

Designing for Scale: Beyond Initial Implementation

Scalability in ERP integration architecture is not limited to handling higher transaction volumes. It includes the ability to adapt to new systems, evolving business models, and changing operational requirements.

An integration architecture that works at go-live may not scale if:

It relies heavily on manual intervention
It lacks standardized patterns for new integrations
It depends on specific tools or skills that are not widely available

Designing for scale requires anticipating future conditions. This includes:

Growth in transaction volumes
Addition of new applications
Changes in business processes
Increased regulatory or reporting requirements

Organizations that treat integration as an architectural discipline rather than a series of projects, are better positioned to manage these changes.

Conclusion

ERP integration architecture is not simply a technical design exercise. It is a structural decision that shapes how reliably information flows across the enterprise, how resilient systems remain under operational stress, and how effectively the digital ecosystem can scale over time. Organizations that approach integration reactively often accumulate complexity that becomes increasingly difficult to manage, while those that define architecture early establish a foundation for consistency, maintainability, and long-term adaptability.

The challenge is not that integration decisions are inherently complex, but that their implications are often not fully visible at the time they are made. Choices around real-time versus batch processing, middleware selection, and governance frameworks carry downstream consequences that may only surface under scale, system change, or failure conditions.

Independent ERP advisors can provide meaningful value at this stage, not by prescribing specific tools or platforms, but by helping organizations evaluate integration architecture decisions in the context of their broader system landscape. This includes identifying where complexity is likely to accumulate, how vendor constraints may affect integration design, and which architectural patterns are appropriate given business requirements rather than implementation preferences.

Organizations navigating ERP transformation can benefit from the vendor-neutral perspective that ElevatIQ brings through its Solution and Enterprise Architecture Design and Enterprise Technology Selection advisory services. Designing how systems connect is as critical as selecting the systems themselves, and ensuring that those connections are intentional, scalable, and aligned with business operations is fundamental to building a digital ecosystem that performs reliably over time.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

ERP Integration Architecture: Why Most Digital Ecosystems Break Down Read More »

Why Companies Change ERP: Most Are Solving the Wrong Problem

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 13, 2026

The decision to replace an ERP system is never made lightly. It carries significant capital commitment, organizational disruption, and implementation risk. Yet a pattern that surfaces consistently across enterprise replacement projects is that the original diagnosis (the reason the organization believed it needed a new system) turns out to be incomplete. Or in some cases, wrong entirely.

Understanding why companies change ERP is important. Understanding why those reasons are often misread is more important. Organizations that go into a replacement cycle without interrogating their own assumptions tend to carry the same underlying problems into the new system, a costly way to learn that the software was not really the issue.

The Gap Between the Stated Reason and the Real Reason Behind Why Companies Change ERP

When project sponsors document the business case for ERP replacement, the language tends to be system-centric: the current platform cannot support growth, lacks reporting capability, does not integrate well with other tools, or is too difficult to maintain. These are legitimate technical observations. They are also frequently symptoms of something else.

The gap between what an organization says is wrong with its ERP and what is actually driving operational difficulty is one of the more consistent findings in enterprise software advisory work. Systems absorb blame efficiently. They are visible, they are expensive, and they are easy to point to when business performance falls short. What is harder to surface and harder to build a business case around, is that the problem may be rooted in how the organization uses the system, how its processes are designed, or how its data is governed.

When the System Is the Symptom, Not the Cause

Consider a distribution company that identifies poor inventory visibility as its primary driver for ERP replacement. Reporting is inconsistent, on-hand quantities are unreliable, and planning decisions are regularly made outside the system using spreadsheets. The conclusion drawn is that the ERP lacks sufficient inventory management capability.

What a structured pre-replacement assessment might reveal instead: item master records have not been maintained consistently across locations, replenishment parameters have not been updated to reflect current lead times, and warehouse staff have developed workarounds that bypass system transactions. The ERP’s inventory module is largely functional, it simply has not been configured or used in a way that could produce reliable output. Replacing the system in this scenario does not resolve the problem. It defers it, at significant cost, until the same patterns reassert themselves in the new environment.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

The Most Common Misdiagnoses When Companies Change ERP

Certain patterns of misdiagnosis appear with enough regularity to be worth examining directly. These are the scenarios where why companies change ERP and what is actually driving the problem diverge most sharply.

Reporting Gaps Attributed to the System

Reporting deficiencies are among the most cited reasons why companies change ERP. The current system, the complaint goes, cannot produce the reports leadership needs. Decisions require manual data extraction, consolidation in spreadsheets, and significant analyst time.

In many cases, this is a data quality and architecture problem, not a reporting capability problem. ERP systems produce output that reflects the quality and completeness of the transactional data entered into them. When master data is inconsistent, when transactions are recorded inconsistently across departments, or when chart of accounts structures have accumulated years of unmanaged additions, no reporting tool, regardless of the platform will produce clean output. Migrating to a new ERP with the same underlying data practices reproduces the same reporting environment within months of go-live.

Integration Complexity Blamed on the Platform

Organizations running multiple systems alongside their ERP commonly attribute integration friction to the ERP’s technical limitations. The platform, they argue, does not connect well with the CRM, the warehouse management system, or the eCommerce layer.

Integration complexity is real, but it is often as much a function of how integrations were originally designed and documented as it is a platform limitation. Point-to-point integrations built without a defined architecture, lacking documentation, and maintained by consultants who are no longer engaged become progressively harder to manage regardless of the ERP involved. Replacing the ERP without addressing the integration architecture transfers the complexity to the new environment.

User Adoption Issues Framed as Usability Problems

When end users avoid the system, rely on workarounds, or actively circumvent its processes, the common interpretation is that the system is difficult to use. Usability is a legitimate dimension of ERP evaluation, and it varies meaningfully across products and user populations.

However, low adoption is more often a consequence of inadequate training, insufficient change management investment, or process design that makes the system harder to use than the manual alternative. When the system requires more steps to complete a transaction than the spreadsheet it replaced, users will use the spreadsheet. That is a process design and implementation decision, not a platform limitation.

Scalability Concerns That Mask Organizational Complexity

Growth-stage organizations frequently identify their ERP as a constraint on scaling. The system, they report, cannot handle increased transaction volumes, additional entities, or more complex reporting requirements.

Scalability is one of the more compelling reasons why companies change ERP, and sometimes it is legitimate. Some of these concerns are legitimate. Not every ERP scales equally, and product selection at an earlier stage of growth may have involved trade-offs that become binding constraints later. But scalability concerns can also mask a different problem: organizational complexity that has outpaced process discipline. When companies grow through acquisition, expand into new geographies, or diversify their business model without updating their operating processes, the ERP reflects that complexity. No replacement system will simplify an organization that has not first simplified itself.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

Why Internal Inefficiency Is Harder to Diagnose Than Why Companies Change ERP

There is an organizational dynamic that makes internal inefficiency genuinely difficult to surface and address in the context of an ERP evaluation. ERP replacement projects generate momentum. Once a leadership team has decided that a new system is the answer, the organizational energy moves toward vendor selection, project planning, and stakeholder alignment. The question of whether the diagnosis is correct rarely receives the same investment. Going back to leadership with a recommendation to fix internal processes rather than replace the system requires a different kind of confidence, and it can be perceived as defending the status quo.

Additionally, the problems that internal inefficiency creates includes poor data quality, inconsistent process execution, departmental workarounds. They all accumulate gradually and rarely have a single visible cause. A system failure is an event. A culture of incomplete data entry is a pattern, and patterns are harder to surface in a standard vendor evaluation process.

Independent assessments conducted before a replacement decision is finalized tend to catch these dynamics. An objective review of current system utilization, configuration gaps, and process execution quality can distinguish between a platform that genuinely no longer fits the organization’s needs and one that has not been given the conditions to succeed.

When Replacement Is the Right Answer

None of this is an argument against replacement. There are genuine circumstances that explain why companies change ERP and arrive at the right conclusion. Where the current system is a legitimate constraint and replacement is the appropriate course of action.

A platform that has reached vendor end-of-support, that lacks the architectural capability to support a material change in business model, or that was selected for a significantly different organizational context may represent a real constraint rather than a misused tool. Similarly, organizations that have outgrown the functional depth of a mid-market system and require enterprise-grade capability in areas like multi-entity financial consolidation, global trade compliance, or complex manufacturing planning may have a genuine case for replacement.

The distinction worth preserving is between a system that cannot meet the organization’s needs and a system that has not been configured, maintained, or used in a way that could meet them. Both produce similar symptoms. They require very different interventions.

A More Useful Framework Before Committing to Replacement

Examining why companies change ERP, honestly and rigorously, before a replacement decision is finalized is one of the highest-value steps an organization can take. The following questions go beyond what the vendor evaluation process typically asks:

Has a current-state utilization review been conducted? What percentage of the existing system’s relevant functionality is actively in use, and what has been licensed but not deployed?
What is the quality of master data in the current environment? Would the same master data practices, carried into a new system, produce different outcomes?
Where do workarounds exist, and why were they created? Are workarounds symptoms of system limitation, or symptoms of implementation and change management gaps?
What would a process redesign, independent of the system? If the processes were redesigned without changing the platform, how much of the reported problem would remain?
Has the organization’s operating model changed materially since implementation? If so, has the system configuration been updated to reflect that change, or has it remained static while the business evolved around it?

These questions do not predetermine the outcome. They ensure that the decision to replace, if that is where the analysis leads is grounded in a genuine understanding of the problem rather than a diagnosis shaped by the most visible symptom.

The Cost of Getting the Diagnosis Wrong

ERP replacement projects are among the most resource-intensive initiatives an organization undertakes. Budget overruns, extended timelines, and productivity disruption during go-live are well-documented risks. When why companies change ERP is built on a misdiagnosis, those costs are incurred without resolving the underlying issue.

The more durable cost is the organizational one. Teams that have been through a difficult replacement cycle, only to find the same reporting problems, the same integration friction, and the same adoption challenges in the new system. Thus, also develop a well-founded skepticism about the next initiative. That skepticism makes every subsequent improvement effort harder to execute. Getting the diagnosis right at the outset is not a theoretical exercise. It is the foundation on which a successful replacement, or a successful optimization of the current environment, is built.

How Independent Advisory Changes the Equation

Organizations navigating this decision benefit from advisory support that is not structured around a specific outcome. Implementation partners and ERP vendors have legitimate interests in a replacement project proceeding, that is how their engagements are structured. Independent ERP advisors operate differently: the value they provide is in the quality of the diagnosis, not in any particular conclusion.

ElevatIQ’s independent advisory practice works with enterprise organizations to assess whether replacement is genuinely the right answer. And when it is, to ensure the selection and implementation process is built on a clear-eyed understanding of the problem being solved. That kind of vendor-neutral perspective is available through ElevatIQ’s enterprise technology selection services. The organizations that get the most value from ERP investment are the ones that ask hard questions before they commit to a direction, not after the contract is signed.describes, is the foundation of a successful long-term ERP relationship.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

Why Companies Change ERP: Most Are Solving the Wrong Problem Read More »

ERP Vendor Support Models: Why Are They Changing and What ERP Buyers Miss?

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 8, 2026

When enterprise organizations evaluate ERP systems, most of the attention lands on functionality, deployment options, and licensing fees. Support models rarely get the same scrutiny, and vendors often structure offerings accordingly. Over the past several years, ERP vendor support models have undergone a quiet but consequential transformation. One that is reshaping what buyers actually receive once the contract is signed and the implementation is complete.

Understanding these shifts is not optional. For organizations committing to multi-year ERP relationships, often in the seven-figure range. The support model embedded in your agreement directly determines what kind of help you get. Also, how fast, and at what additional cost, when things go wrong or when business needs evolve.

How ERP Vendor Support Models Are Shifting Beyond Pricing

The industry-wide migration from perpetual licensing to subscription-based arrangements is well documented. What is less discussed is how this shift has quietly restructured the nature of support itself.

Under the traditional perpetual license model, annual maintenance fees, typically range from 15 to 22 percent of the original license cost. It usually covers a fairly clear set of entitlements. It often includes product updates, bug fixes, access to support portals, and some level of direct vendor assistance. Buyers understood what they were paying for, even if the fees were substantial.

The subscription model collapses these elements into a single recurring fee and presents it as a simplification. In practice, it is often anything but simple.

Bundled Does Not Mean Comprehensive

Cloud-based ERP subscriptions typically include what vendors describe as a “base level” of support. What falls outside that base level is where buyers frequently encounter surprises. Premium support tiers which offer faster response times, dedicated account management, or access to senior engineers, are increasingly sold as separate add-ons, often at meaningful additional annual cost.

A buyer who compares subscription pricing across vendors may not be comparing equivalent support entitlements at all. One vendor’s standard tier may include 24-hour critical incident response, while another’s requires an upgraded ERP contract to access the same.

Consumption-Based Complexity

Several major ERP vendors have also introduced consumption-based licensing layers within their subscription frameworks. Charges tied to document volumes, API call thresholds, data storage consumption, and indirect user access have become standard features of cloud ERP commercial structures. These mechanics can generate cost exposure that was not anticipated at contract signing. Particularly, as transaction volumes grow or as more third-party systems interact with the ERP.

From a support perspective, this matters because consumption overages often create service disruptions or throttling situations. Resolving them may require navigating vendor escalation paths that are only available to customers on higher-tier support arrangements.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

SLA Dilution in ERP Vendor Support Models: The Detail Hiding in Plain Sight

Service level agreements are the contractual backbone of vendor support obligations. Yet in modern ERP agreements, SLA language has evolved in ways that may reduce practical accountability in certain scenarios while maintaining the appearance of strong commitments.

Response Time vs. Resolution Time

One of the most important distinctions buyers overlook is the difference between response time and resolution time. Most ERP vendor SLAs guarantee response times which is the interval between logging a ticket and receiving an acknowledgment. Very few offer enforceable resolution time commitments, meaning the vendor is contractually obligated only to acknowledge the problem, not to fix it within any defined period.

For mission-critical ERP environments, this gap is significant. A system availability issue affecting order processing, financial close, or supply chain operations can remain unresolved for extended periods while remaining technically within SLA compliance.

Tiered Priority Definitions

SLA structures in cloud ERP contracts increasingly rely on vendor-defined priority classifications commonly labeled P1 through P4 or equivalent. The challenge is that what qualifies as a critical incident under the vendor’s internal definitions may not align with what the customer experiences as business-critical. Vendors often retain the right to reclassify incident severity. This can, in some cases, affect response commitments without any breach of contract.

Shared Infrastructure Caveats

In multi-tenant cloud environments, SLA uptime guarantees are often measured at the infrastructure level rather than the application level. A vendor may maintain 99.9 percent platform uptime while specific application modules experience availability issues that fall outside the reported metric. Buyers negotiating ERP agreements should ensure that SLA measurements reflect application-level availability relevant to their operational workflows, not just platform-level metrics.nal complexity increase significantly in subsequent deployments.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

What Buyers Consistently Miss

The commercial dynamics behind ERP vendor support models are not difficult to understand once they are surfaced. The problem is that procurement teams and IT leaders often engage with support terms late in the evaluation process. Usually, after commercial positions have already been established.

The Long-Term Cost Curve

A frequently cited advantage of subscription models is predictable costs. Over a long horizon, however, subscription costs are not fixed, they are subject to annual escalation clauses, often embedded in ERP contract terms that receive limited attention during negotiation. On-premises annual maintenance fees historically drew scrutiny because they were line items on a perpetual license agreement. Cloud subscription escalations are structurally equivalent but are sometimes framed differently.

Organizations evaluating ERP vendor support models should build five-to-seven-year total cost projections that include support tier pricing, anticipated escalation rates, and the cost of any premium support add-ons required to meet operational needs.

Partner-Delivered Support vs. Vendor-Delivered Support

A structural reality of modern ERP ecosystems is that much first-line support is delivered not by the ERP vendor directly, but by implementation partners, resellers, or value-added resellers operating under channel agreements. For buyers, this creates a layered support architecture where incident resolution may depend on partner capacity and expertise rather than vendor resources.

This arrangement is not inherently problematic, but it requires clarity in the contract about who owns which support obligation, what escalation paths exist to the vendor when the partner cannot resolve an issue, and how response time commitments are measured across the partner-vendor boundary. Evaluating ERP vendor support models means mapping this layered accountability before it becomes an operational problem.

AI and Automation in Support: Promise vs. Practice

ERP vendors are increasingly promoting AI-assisted support capabilities – automated ticket triage, self-service knowledge bases, virtual assistants for common queries. These tools have genuine utility for routine support scenarios. They are less suited to the kind of complex, environment-specific issues that enterprise ERP customers typically face when something goes wrong.

Buyers should assess support models not only on what the vendor promises through automation but on what human escalation paths exist, how accessible senior technical resources are, and under what conditions a dedicated support resource can be assigned to a specific issue.

Key Questions to Ask Before Agreeing to ERP Vendor Support Models

Organizations evaluating ERP vendor support models should bring a specific set of questions into contract negotiations rather than accepting standard terms at face value:

What is explicitly covered under the base support tier, and what requires an upgraded contract?
How does the vendor define incident severity levels, and does the buyer have any input into priority classification?
Are resolution time commitments included anywhere in the SLA, or only response time acknowledgments?
How are SLA metrics measured — at the platform level or at the application and process level?
What escalation path exists if the implementation partner cannot resolve a critical issue?
Are there annual escalation clauses in support pricing, and at what rate?
What data portability and exit support provisions exist if the relationship ends?

These questions do not require adversarial negotiating postures. They represent a reasonable baseline for understanding what an organization is actually purchasing when it commits to an ERP vendor relationship.

Evaluating ERP Vendor Support Models as Part of Vendor Selection

Support model assessment should not occur as a final contract review step. It belongs in the vendor evaluation phase, alongside functional fit and commercial benchmarking.

When comparing ERP vendors, buyers benefit from mapping support tier structures side by side rather than comparing headline subscription prices. The effective cost of a support model that requires a premium add-on to meet operational requirements may be meaningfully higher than a competitor’s all-inclusive arrangement, even if the base subscription appears lower.

Reference checks with existing customers should include specific questions about support experience, not just product satisfaction. Customers who have been through major incidents, upgrade cycles, or environment-specific issues offer the most relevant perspective on what vendor support actually looks like in practice.

The Conclusion

ERP vendor support models are a legitimate and complex area of commercial risk. The shift toward subscription-based delivery has introduced genuine benefits, including reduced infrastructure burden, faster update cycles, and cleaner commercial structures, alongside structural changes in how support obligations are defined and enforced.

Independent ERP advisors can provide meaningful value at this stage of the process, not by negotiating on a buyer’s behalf but by helping organizations understand what standard terms look like across the vendor landscape, where the material risks in specific contract structures are concentrated, and what provisions are genuinely negotiable versus standard boilerplate.

Organizations navigating ERP selection and contract review can benefit from the kind of vendor-neutral perspective that ElevatIQ’s independent advisory practice brings to enterprise technology selection. Understanding what you are actually buying, not just what the sales deck describes, is the foundation of a successful long-term ERP relationship.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

FAQs

Are ERP support models negotiable, or are they standardized?

Support tiers and SLA terms vary by vendor and by the size and strategic value of the customer relationship. Larger organizations with significant contract value generally have more leverage to negotiate support terms. That said, standard templates exist for a reason — vendors work from defined commercial structures, and buyers benefit from knowing what is genuinely flexible versus what is policy-level.

What is the difference between a support tier and a maintenance fee?

In on-premises ERP agreements, annual maintenance fees typically cover product updates, bug fixes, and access to support resources. In cloud subscription models, support is often bundled into the subscription but stratified into tiers with different response commitments and resource access levels. The functional distinction matters less than understanding exactly what each structure covers in your specific agreement.

How often do ERP vendors change their support terms?

Vendors reserve the right to update support policies, and cloud-era agreements often include provisions that allow modification of support terms with defined notice periods. Organizations should monitor vendor communications about support policy changes and understand what contractual recourse exists if terms are modified materially.

ERP Vendor Support Models: Why Are They Changing and What ERP Buyers Miss? Read More »

ERP Go-Live Failure: Lessons For ERP Buyers From Tennant’s $30M ERP Failure

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 6, 2026

In the first week of November 2025, Tennant Company (NYSE: TNC) cut over to a new company-wide SAP cloud-based ERP system in North America. It is a Minnesota-based global manufacturer of industrial cleaning equipment, with approximately $1.3 billion in annual revenue. Within days, the business could no longer reliably process or ship customer orders.

The financial damage disclosed on February 24, 2026, was immediate and concrete. They were as follows:

Approximately $30 million in lost net sales in Q4 2025
A $22 million reduction in Q4 adjusted EBITDA
Over $20 million in unplanned remediation costs for 2026, against an original remediation budget of roughly $5 million
Gross profit margin collapsing from 41.3% in Q4 2024 to 34.6% in Q4 2025
Tennant’s stock falling 23.4% in a single trading session, from $82.30 to $63.02. Thus, erasing approximately $343 million in market capitalization
The EMEA go-live, previously scheduled for the following quarter, paused indefinitely

The combined revenue and EBITDA impact in a single quarter was approximately $52 million. The total ERP program investment since 2023 reached approximately $98 million. Multiple securities law firms launched investigations into whether Tennant had accurately represented the project’s progress and risk to investors before the North American disclosure.

An ERP go-live failure of this scale from a company that appeared to follow standard ERP implementation practices, phased its rollout, and acknowledged project risk publicly deserves close examination. Tennant had flagged the project publicly for years. It has acknowledged the risks openly and followed what appeared to be industry best practice in phasing the rollout geographically. The company assessed the Asia-Pacific deployment in September 2025 as successful. Then, it followed with a North American go-live described as extensively prepared. And it still failed.

The Setup: A Legitimate Transformation with a Sound Rationale

Tennant’s ERP consolidation was not an opportunistic initiative. In the Q4 2023 earnings call, CEO Dave Huml articulated the rationale directly. The company was running eight separate ERP systems globally on aging infrastructure. He described that consolidating them onto a single SAP cloud-based platform was essential to the company’s three-year growth strategy. The company estimated the program would cost approximately $75 million in total capital and operating expenditure through 2025, with around $37 million expected in 2024 alone.

The case for consolidation was well-reasoned. Eight fragmented ERP instances make data visibility, operational efficiency, compliance, and cybersecurity governance significantly more difficult to maintain. Bringing the entire enterprise onto a unified platform addresses all of those problems simultaneously.

Throughout 2024 and into 2025, Tennant provided investors with regular progress updates. The company characterized the project as “progressing as we’ve anticipated” and “on time and on budget.” By Q3 2025, it had completed the Asia-Pacific go-live and described it as successful. It had North America underway and scheduled EMEA for the following quarter. Then the Q4 2025 results hit. The ERP go-live failure in North America significantly offset the efficiency gains the consolidation program was designed to deliver over time.

What Actually Went Wrong

In CEO Dave Huml’s own words from the Q4 2025 earnings call:

“Despite a successful go-live in the APAC region in September and extensive preparation in North America, the cut-over of the ERP system in the first week of November introduced severe system functionality issues that limited our ability to enter orders, ship products, and service our customers.”

Three operational functions failed simultaneously at go-live: order entry, product shipment, and customer service. For a manufacturer whose revenue model depends on processing equipment orders and delivering them reliably, this is a failure in the core of the business, not in a peripheral administrative function.

The scale of the disruption indicates this was not a brief cutover hiccup that self-corrected within days. Stabilization challenges extended well beyond the initial go-live window, requiring significant additional investment. The 4x overrun on the original remediation budget is the clearest evidence of that. The company has paused the EMEA deployment indefinitely while North America continues its recovery.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Why the Asia-Pacific Success Did Not Predict the North American Failure

One of the most instructive aspects of the Tennant case is the regional asymmetry. The Asia-Pacific rollout was assessed as successful in September 2025. Eight weeks later, the North American go-live failed.

Organizations commonly observe this pattern in phased ERP programs: earlier phases succeed, while the largest and most complex region experiences ERP go-live failure. Several structural factors explain it:

Transaction volume and complexity. North America is typically the largest revenue region for a global manufacturer. It concentrates the highest order volumes, the densest customer base, and the most complex fulfillment workflows. A system that processes APAC-scale transaction loads without incident may surface entirely different failure modes when exposed to North American peak volumes.
Integration depth. The number of systems, processes, and dependencies connected to the ERP grows with operational scale. North American operations typically carry more integration complexity, more third-party logistics connections, more distributor relationships, more legacy system touchpoints, than earlier-phase deployments.
Process variability. Even within a single ERP program, process configurations differ meaningfully across regions. Workflows validated in APAC may not accurately represent the configuration paths used in North America, meaning that testing results from the earlier go-live carry limited predictive value for the later one.
Cutover execution at scale. The mechanics of cutover including data migration, parallel running, fallback procedures, become materially more complex at North American scale than at APAC scale. Issues that are manageable at a smaller scale can cascade at a larger scale.

As noted in its analysis: phased rollouts do not eliminate risk, they redistribute it. Success in one region does not guarantee stability at scale, particularly when process and geography variability and operational complexity increase significantly in subsequent deployments.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

The Investor Communication Dimension: A New Category of ERP Risk

The Tennant case introduces a risk dimension that most ERP implementation guides do not address: investor communication liability.

Following the February 24 disclosure, securities law firms including Bleichmar Fonti & Auld LLP and Hagens Berman launched investigations into whether Tennant’s prior statements about the ERP rollout accurately represented the project’s progress and risk. The central allegation is that the company characterized the project as on track and the Asia-Pacific go-live as successful in its investor communications, while North America was experiencing or heading toward problems that those communications did not reflect.

These are investigations, not proven findings. They do not establish wrongdoing. But their existence and the speed with which they were launched highlight an important structural point: publicly listed organizations now recognize ERP implementations as material business events subject to the same disclosure expectations as financial restatements and operational incidents.

The gap between internal awareness of ERP go-live failure risk and external communication of that risk is no longer purely a reputational concern. It has become a legal one. For enterprise leaders, including those at privately held companies, where the audience is lenders, private equity sponsors, or boards rather than public investors, the broader principle applies: governance structures must ensure that decision-makers receive timely, honest program health reporting rather than filtered status updates calibrated to maintain organizational momentum.

Five Lessons Enterprise Buyers Must Apply

The Tennant ERP go-live failure is not an isolated anomaly. It reflects failure patterns that appear consistently in large-scale ERP programs. Each of the following lessons is directly traceable to what the Tennant case reveals.

1. Readiness Validation Must Be Regional, Not Cumulative

The North American go-live was preceded by extensive preparation, per the CEO’s own account. The Asia-Pacific success was cited as evidence that the program was proceeding well. Neither was sufficient.

Go-live ERP readiness assessments must be conducted fresh against the specific conditions of each deployment. Its transaction volumes, integration dependencies, cutover complexity, and operational criticality, not inherited from prior phases. The fact that APAC completed without an ERP go-live failure does not reduce the rigor required for North America. In many cases, it should increase it, precisely because North America carries materially higher operational stakes.

2. Order-to-Cash Is the Last Process That Should Fail at Go-Live

The inability to enter orders, ship products, and service customers is a failure in the revenue-generating core of the business. ERP go-live failure in these processes converts immediately and visibly into lost sales, customer relationship damage, and market reaction.

Any ERP program that allows order-to-cash to fail at go-live may indicate gaps in integration testing or cutover validation and an ERP go-live failure in order fulfillment is among the most damaging outcomes possible for a manufacturer. Testing the order-to-cash workflow, including every system that touches a customer order from entry through shipment confirmation under realistic peak-volume conditions should be the final gate before any go-live authorization is granted.

3. Remediation Budget Is a Risk Management Tool, Not a Footnote

Tennant’s remediation costs for 2026 exceeded $20 million against a planned $5 million. A 4x overrun on the remediation line alone, on top of a total program that had already grown from an estimated $75 million to approximately $98 million. This reflects a pattern often observed in failed ERP programs: remediation is budgeted as a small post-go-live support line rather than as a genuine contingency against stabilization failure.

A realistic ERP remediation budget accounts for extended hypercare, emergency consulting, parallel running costs, potential module re-implementation, and the customer-facing costs of fulfillment disruption. Treating remediation as a minor budget item is not conservatism, it is deferred risk.

4. Internal Escalation Paths Must Exist Before They Are Needed

The Tennant CEO’s statement that North America was extensively prepared before go-live, combined with the severity of the failure, raises a question that is relevant to every complex ERP program: at what point was the executive leadership team receiving signals that the North American go-live carried elevated risk, and what were the escalation and decision-making structures that processed those signals?

Clear internal escalation paths and transparent external communication plans should be in place well before go-live. A program governance structure that surfaces problems only at the point of public disclosure has failed its primary purpose.

5. The Strength of the Business Case Does Not Protect Against Execution Failure

Tennant’s consolidation rationale, eliminating eight fragmented ERP instances, building unified digital infrastructure, enabling growth, was sound and publicly stated. The investment was authorized and progressed over multiple years with board involvement. None of that protects the organization from the consequences of an ERP go-live failure in the most operationally critical region.

The business case justifies the investment decision. Execution discipline determines the outcome. They are separate matters, and conflating the two, using the clarity of the rationale as evidence that the execution risk is under control, is one of the most common governance errors in large technology programs.

What This Means for Organizations Currently Mid-Program

For enterprise buyers already in an ERP program, approaching a regional go-live or preparing a North American or full-scale deployment after earlier phases – the Tennant case raises questions that deserve honest answers before the go-live window closes:

Has a fresh, independent readiness assessment been completed specifically for this deployment, not carried over from the prior phase?
Has the order-to-cash workflow been stress-tested under peak-volume conditions with all integration dependencies active?
Does the remediation budget reflect a realistic worst-case stabilization scenario, not just planned hypercare?
Are internal program health reports providing honest risk visibility to executive leadership, or are they filtered through project team optimism?
Is the board or audit committee receiving implementation risk updates on a cadence appropriate to the business materiality of the go-live?

None of these questions require an ERP go-live failure to answer. They are commonly considered elements of rigorous program governance, the kind that separates ERP implementations that stabilize quickly from those that generate $52 million in combined revenue and EBITDA impact in a single quarter.

Conclusion

Tennant Company’s ERP go-live failure is a costly, current, and exceptionally well-documented case study in what happens when the largest and most operationally complex deployment in a phased ERP program is not validated to a standard commensurate with its complexity and business criticality. The $30 million in lost sales, the 23.4% single-day stock drop, the paused EMEA rollout, the ongoing securities investigations, and the multi-year distraction from strategic priorities are the measurable cost of that gap.

The company had a sound rationale. It followed a phased approach. It acknowledged the risk publicly. The available evidence suggests the issue was less about strategy and more about execution validation at the point where failure could no longer be contained. For enterprise buyers at any stage of their own ERP journey, this case reinforces what independent ERP advisors emphasize consistently: the business case for transformation is rarely the problem. The problem is almost always in the governance, testing discipline, and escalation structures that determine whether the go-live delivers on that case or undermines it.

ElevatIQ’s enterprise technology selection and implementation advisory services are specifically designed to provide the independent oversight that internal teams – under deadline pressure and organizational momentum, can find difficult to sustain. As independent ERP advisors, ElevatIQ works with organizations to ensure that go-live readiness is assessed against the actual conditions of each deployment, not against the success of the phase that came before it.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

FAQs

Which ERP system was Tennant implementing?

Tennant’s Q4 2023 earnings call confirmed the company was consolidating its eight existing ERP systems onto a SAP cloud-based solution as part of a program originally estimated at approximately $75 million through 2025.

What exactly failed during Tennant’s North American go-live?

Per CEO Dave Huml’s statement in the Q4 2025 earnings call, the cutover in the first week of November 2025 introduced severe system functionality issues that limited Tennant’s ability to enter orders, ship products, and service customers. All three represent core revenue-generating operational functions.

How much has the Tennant ERP program cost in total?

The program was originally estimated at approximately $75 million in total capital and operating expenditure. By 2026, total investment since 2023 had reached approximately $98 million, with 2026 remediation costs expected to exceed $20 million against an original plan of roughly $5 million.

ERP Go-Live Failure: Lessons For ERP Buyers From Tennant’s $30M ERP Failure Read More »

Disaster Recovery in ERP Contracts: Securing Business Continuity Before You Sign

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / April 1, 2026

When ERP systems go down, the financial consequences accumulate fast. Order processing halts. Financial close cycles stall. Production schedules break. Customer commitments are missed. For organizations running mission-critical operations on a single ERP platform, unplanned downtime is not an inconvenience. It is a direct operational and financial crisis.

Yet when most buyers negotiate ERP contracts, disaster recovery provisions receive far less scrutiny than pricing, licensing terms, or implementation scope. The result is that disaster recovery in ERP contracts is silent or vague. Especially, on exactly the commitments that matter most when something goes wrong.

Disaster recovery in ERP contracts deserves dedicated negotiation effort. This blog covers what buyers need to address – RTO and RPO commitments, backup requirements, cloud provider responsibilities, and the testing rights that determine whether any of it actually works in practice.

Why Disaster Recovery in ERP Contracts Gets Overlooked

The gap in many ERP contracts is not always accidental. Vendors may benefit from vague language. Standard SaaS agreements typically guarantee infrastructure uptime, the availability of the platform but stop well short of committing to specific data recovery timelines or functional restoration standards after a failure event.

Buyers, focused on features, price, and go-live timelines during contract negotiations, often accept this framing. The assumption, especially for cloud ERP deployments, is that the vendor is handling disaster recovery as part of the service. That assumption is often incorrect, and addressing disaster recovery in ERP contracts before signing is far less costly than discovering the gap after an outage.

The distinction matters most in the cloud context, where the shared responsibility model explicitly divides accountability between vendor and customer. Understanding exactly where that line falls and negotiating contract language that locks it down is a foundational step in any ERP procurement.

RTO and RPO: The Two Numbers That Define Your Risk Exposure

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two core metrics that any discussion of disaster recovery in ERP contracts must address. They are not technical details for the IT team to handle separately, they are business risk decisions that belong in the contract itself.

Recovery Time Objective (RTO) defines the maximum amount of time the ERP system can be offline before the outage becomes operationally unacceptable. It answers the question: how quickly must the system be restored? An RTO of four hours means the vendor is committing to have the system operational within four hours of a declared disaster event.
Recovery Point Objective (RPO) defines the maximum amount of data loss, measured in time, that the organization can tolerate. It answers the question: how current must the data be when we recover? An RPO of one hour means the system will be restored with no more than one hour of transactional data lost.

Both metrics look in different directions from the point of failure. RPO looks backward – how recent was the last recoverable backup? RTO looks forward – how long until systems are back online?

Setting Appropriate Targets for Mission-Critical ERP

Not all ERP modules carry the same criticality, and RTO/RPO targets should reflect that. A financial close system processing period-end entries carries different risk than a secondary reporting module. Buyers should conduct a Business Impact Analysis (BIA) before contract negotiations to understand the operational and financial cost of downtime per hour across core ERP functions. This analysis anchors RTO/RPO discussions in business reality rather than arbitrary benchmarks.

As a general orientation, enterprise-class ERP providers running managed hosting environments may support RPO targets as tight as 30 minutes and RTO windows in the two- to four-hour range for high-priority workloads. However, achieving tighter targets requires both the right infrastructure architecture and explicit contractual commitments, not assumptions. Buyers should press vendors on what specific RTO and RPO figures they can commit to contractually, not just what they claim is technically possible.

What Contract Language Should Capture

Vague language like “best efforts to restore within a reasonable timeframe” is not enforceable and provides no recourse. Disaster recovery in ERP contracts must specify:

Named RTO and RPO figures, expressed in hours or minutes, not qualitative terms
The definition of a “disaster event” that triggers these commitments including whether ransomware, accidental deletion, and partial system failures are covered alongside infrastructure outages
Whether the committed RTO and RPO apply to the full ERP system or only to specific components
Financial remedies – service credits or penalties, that apply if the vendor misses committed recovery targets
Escalation procedures and communication timelines during a declared disaster event

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Understanding Cloud Provider Responsibilities: The Shared Responsibility Gap

One of the most consequential misunderstandings in disaster recovery in ERP contracts is the assumption that moving to cloud ERP transfers disaster recovery responsibility to the vendor. It does not, at least not entirely.

Every major cloud provider including those underpinning ERP platforms like SAP S/4HANA Cloud, Oracle Fusion ERP, and Microsoft Dynamics 365 operates under a shared responsibility model. The specifics vary by deployment type, but the general principle is consistent:

The cloud provider is responsible for the availability and resilience of the infrastructure – the physical data centers, the network, the compute and storage layers, and the platform uptime.
The customer retains responsibility for how data is configured, replicated, governed, and recovered at the application and data level.

Oracle has stated this plainly in its cloud documentation: while OCI is responsible for resilience of the cloud, the customer is responsible for resilience in the cloud. Microsoft’s Azure shared responsibility documentation makes the same distinction. Customers who design and implement DR strategies including cross-region replication, failover configurations, and recovery runbooks – are better protected than those who rely on platform-level availability SLAs alone.

For buyers, this means disaster recovery in ERP contracts must address two distinct layers:

Infrastructure-level commitments (vendor responsibility)

Data center redundancy and geographic failover capability
Platform uptime SLA (typically 99.9% or higher, but note this governs availability, not recovery from failure)
Incident notification timelines and communication protocols during outages

Application and data-level commitments (negotiated boundary)

Backup frequency and retention period for the customer’s ERP data
Geographic location of backup copies (same-region vs. geo-redundant)
Who is responsible for executing recovery steps – the vendor’s managed services team, or the customer’s IT organization
Whether the vendor provides a managed DR service as part of the standard subscription or as a separately priced add-on

Many SaaS ERP contracts may not explicitly address the second set of items, leaving buyers to assume coverage they do not have. Explicit contract language assigning responsibility for each layer is essential.

Backup Requirements: Frequency, Retention, and Access

Backup provisions are the operational foundation of any DR commitment. Disaster recovery in ERP contracts should define:

Backup frequency: How often is a full backup of the ERP environment taken? For most enterprise ERP deployments, daily full backups with continuous log archiving between snapshots is commonly considered a baseline approach. Buyers with tighter RPO requirements should ask whether intraday or near-continuous replication is available and contractually committed.
Retention period: How long are backup copies retained? Standard commercial terms often default to 30 days. Organizations with compliance, audit, or regulatory obligations – financial services, healthcare, government contractors, frequently need longer retention periods, sometimes 90 days or more. This needs to be in the contract, not handled as a configuration default that can change.
Geographic redundancy: Are backup copies stored in a separate geographic region from the primary system? Single-region backups are vulnerable to the same regional event that caused the primary outage. Geo-redundant storage ensures that a natural disaster, data center failure, or regional infrastructure incident does not take out both the primary system and its backups simultaneously.
Buyer access to backups: Can the buyer independently access backup data, or must all recovery operations go through the vendor? This matters both for operational control and for scenarios where the vendor relationship has terminated or the vendor has gone out of business. Contracts should guarantee buyer access to backup data regardless of contract status.

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

DR Testing Rights: The Provision Most Contracts Omit

Of all the elements of disaster recovery in ERP contracts, DR testing rights are the most commonly absent and their absence can turn a written commitment into an unverified assumption.

A vendor can document robust RTO and RPO targets in a contract. Without regular, verified testing, neither the buyer nor the vendor actually knows whether those targets are achievable. Hardware configurations change. Data volumes grow. Integration dependencies evolve. A DR plan that worked eighteen months ago may not perform the same way today.

DR testing rights that buyers should negotiate into any ERP contract

Annual failover testing: The right to require the vendor to execute a full DR failover test at least once per year, demonstrating that systems can be restored to the contracted RTO and RPO targets under realistic conditions.
Tabletop exercise participation: The right to participate in or independently conduct tabletop exercises that walk through disaster scenarios, validate escalation procedures, and confirm that both vendor and customer teams understand their respective roles.
Access to test results: The right to receive written documentation of DR test outcomes, including whether RTO and RPO targets were met, what issues were identified, and what remediation steps were taken.
Unannounced testing rights: For the most risk-sensitive organizations, the right to request a DR test on reasonable notice – say, 30 days, without having to wait for an annually scheduled exercise.
Remediation obligations: If a DR test reveals that the vendor cannot meet committed RTO or RPO targets, the contract should specify a remediation timeline and an escalation path if issues are not resolved.

The absence of testing rights means the buyer has a paper commitment that has never been verified. For mission-critical ERP systems where downtime costs thousands of dollars per hour, that may not be an acceptable position for many organizations.

On-Premises vs. Cloud ERP: How DR Responsibilities Differ

Disaster recovery in ERP contracts looks different depending on the deployment model, and buyers should approach negotiation accordingly.

Cloud SaaS ERP: The vendor manages infrastructure, platform, and often application-layer backups as part of the service. The risk for buyers is assuming that this coverage is complete without verifying what is and is not included. The shared responsibility gap described above is most pronounced here. Key negotiation focus: defining the exact scope of vendor-managed DR, locked-down RTO/RPO commitments, and testing rights.
Cloud IaaS/PaaS (customer-managed ERP on cloud infrastructure): The buyer is responsible for a broader range of DR decisions such as replication configuration, failover architecture, and recovery runbook design, while the cloud provider manages the underlying infrastructure. Key negotiation focus: infrastructure availability SLAs, support for DR architecture implementation, and contractual clarity on where provider responsibility ends.
On-premises ERP: The buyer owns the full DR stack, but the ERP vendor’s contract still plays a role, specifically around support during recovery events, access to disaster recovery licenses for standby systems, and the vendor’s own obligations if software bugs contributed to a data loss event. Key negotiation focus: DR-specific license terms, support response commitments during outages, and vendor liability for data loss attributable to defective software.

Connecting DR Commitments to Broader Business Continuity Planning

Disaster recovery in ERP contracts does not exist in isolation. ERP is typically one of several interconnected systems such as EDI integrations, financial reporting tools, third-party logistics platforms, CRM, that together enable business operations. A contractual DR commitment that covers the ERP platform but not its integration dependencies leaves the organization partially protected at best.

Buyers should ensure that DR contract provisions account for:

Integration recovery sequencing: In what order must interconnected systems be restored for the ERP to function usefully after a failover?
Dependency mapping: Which third-party systems or APIs does the ERP rely on, and what are those providers’ DR commitments?
Data reconciliation procedures: After recovery, how are data discrepancies between the ERP and connected systems identified and resolved?

These cross-system considerations are frequently outside the scope of standard vendor contract templates, which is exactly why they need to be raised explicitly during negotiation.

Conclusion

Disaster recovery in ERP contracts is not a technical afterthought – it is a direct expression of how much operational risk an organization is willing to accept without contractual protection. ERP systems are among the most mission-critical platforms in any enterprise. The cost of unplanned downtime measured in lost transactions, missed reporting deadlines, and broken customer commitments, is too high to leave DR provisions to standard vendor language.

Buyers who invest the effort to negotiate specific RTO and RPO targets, clear backup requirements, defined cloud provider responsibilities, and enforceable testing rights are far better positioned than those who accept default contract terms and discover the gaps only when something goes wrong. Getting disaster recovery in ERP contracts right is not inherently complex but it does require knowing what to ask for.

Working with independent ERP advisors who have evaluated DR provisions across dozens of vendor agreements gives organizations the benchmarking intelligence to know what is achievable, what is negotiable, and what red flags to watch for in standard vendor templates. ElevatIQ’s enterprise technology selection and IT procurement advisory services include contract review support specifically designed to surface gaps in disaster recovery, SLA, and business continuity provisions helping organizations secure the protections they need from independent ERP advisors who negotiate vendor agreements every day.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

FAQs

What are RTO and RPO, and why are they critical in ERP contracts?

RTO (Recovery Time Objective) defines how quickly the ERP system must be restored after a disruption, while RPO (Recovery Point Objective) defines how much data loss is acceptable. These are not just technical metrics—they directly determine business risk. Without clearly defined and contractually committed RTO and RPO targets, organizations have no guarantee on recovery timelines or data integrity after an outage.

Does moving to cloud ERP mean the vendor fully handles disaster recovery?

No. Cloud ERP operates under a shared responsibility model. While vendors manage infrastructure availability, customers are often still responsible for aspects like data configuration, replication, and recovery processes. Many contracts do not clearly define these boundaries, which can leave critical gaps unless explicitly addressed during negotiation.

Why are disaster recovery testing rights important in ERP contracts?

Testing rights ensure that disaster recovery plans actually work in practice, not just on paper. Without regular failover testing, tabletop exercises, and access to test results, there is no way to verify whether the vendor can meet committed RTO and RPO targets. For mission-critical ERP systems, untested recovery plans can create significant operational and financial risk during real outages.

Disaster Recovery in ERP Contracts: Securing Business Continuity Before You Sign Read More »

“Will AI Replace ERP”: What the Goldman Sachs Report Means for ERP Buyers

Leave a Comment / Blog, Enterprise Architecture, ERP / By Shrestha Dash / March 30, 2026

Will AI replace ERP? It is the question rattling Wall Street, IT leaders, and enterprise software buyers in 2026. It deserves a more precise answer than the market has been giving it. Enterprise software stocks recorded one of their worst-performing quarters relative to the S&P 500 in recent history. The iShares Expanded Tech-Software Sector ETF (IGV) reportedly declined significantly in Q1 2026. It’s the steepest quarterly drop since the financial crisis of 2008. Salesforce, Adobe, and Workday also saw significant share price declines over the same period.

A key contributing factor was investor concern that AI agents could perform the same workflows. Which was previously handled by dedicated enterprise software platforms – making traditional SaaS subscriptions redundant.

In March 2026, Goldman Sachs published a formal research report titled “Will AI Eat Software? It is one of the most closely watched pieces of enterprise technology analysis in years. For CIOs, CFOs, and procurement teams asking will AI replace ERP, the conclusions in that report carry direct practical implications. This blog breaks down what the research actually found. Why ERP sits in a structurally different position from other software categories. Also, what it means for organizations currently evaluating or implementing ERP systems.

The Scope: What Triggered the 2026 Enterprise Software Selloff

The immediate catalyst was the launch of Anthropic’s enterprise AI agent plugins in early February 2026. Which extended AI automation into functions previously controlled by point software solutions — legal research, CRM workflows, data analytics, and customer support. Investors read this as a signal that AI could systematically hollow out the core revenue streams of traditional SaaS vendors.

The selloff that followed was swift and largely indiscriminate. Shortly after, major enterprise software stocks dropped sharply regardless of whether their business models were genuinely exposed to AI substitution. Short-selling activity across software stocks increased compared to recent years.

The core fear is straightforward: if an AI agent can handle the same workflow that previously required a dedicated software subscription, why would an enterprise continue paying per-seat SaaS fees? It is a legitimate question. But as Goldman Sachs’ research makes clear, it requires a much more precise answer than “yes” or “all software is at risk.”

What Goldman Sachs Actually Found

Goldman Sachs analyst Gabriela Borges assessed seven common bearish arguments investors were making about enterprise software, assigning each a risk score from 1 (low risk) to 5 (high risk). The framework is directly relevant to the question of will AI replace ERP because ERP appears at the center of the most important finding.

“Rip and Replace” ERP: Goldman Rates It Risk Score 1 (Lowest)

The most alarming version of the AI disruption thesis holds that new AI entrants will rebuild the systems-of-record layer from scratch, making foundational platforms like ERP, CRM, and HR software obsolete. Will AI replace ERP by making it structurally irrelevant? Goldman Sachs analysis rated this scenario as low risk of all seven arguments examined.

The reasoning is straightforward: generative AI is an analysis and generation engine, not a transaction engine. Enterprise-grade AI depends on large volumes of high-quality, structured, and traceable data and ERP systems serve as the primary containers and governance infrastructure that produce and maintain that data. Replacing the ERP to build AI on top of it would mean dismantling the very foundation AI agents need to function reliably in an enterprise context.

Value Shifting to the Orchestration Layer: Risk Score 4 (Elevated)

This is where Goldman sees the more realistic near-term risk. The report suggests ERP systems will not disappear but could become what Goldman calls a “compliance data substrate,” with commercial value increasingly captured by the orchestration layer sitting on top of them. AI agents can read, write, and reconcile across multiple systems of record, and over time, users may no longer need to directly access the original ERP interface. This weakens the moat ERP vendors have historically held through interface control, process dependency, and user habit.

This is the scenario enterprise buyers should be watching. The question is not will AI replace ERP, it is whether ERP vendors will maintain their value position as AI orchestration layers grow on top of them.

Horizontal Platforms Eroding Vertical Software: Risk Score 2 (Low to Moderate)

Goldman assessed the risk that horizontal AI tools allow buyers to build their own industry workflows, cutting into specialized vertical software pricing power. This was rated low to moderate risk. Vertical ERP platforms benefit from proprietary industry data, deep workflow integration, compliance barriers in regulated industries, and customer switching timelines measured in years, not months.

The overarching Goldman conclusion, as analyst Matthew Martino articulated: the recent repricing of software stocks reflects a rapid shift in investor sentiment rather than a sudden deterioration in fundamentals. The selloff appears to have been applied broadly rather than selectively, punishing ERP platforms alongside far more vulnerable narrow SaaS tools that lack their data depth and transaction criticality.

ERP Selection Requirements Template

This resource provides the template that you need to capture the requirements of different functional areas, processes, and teams.

Download Now

Why Will AI Replace ERP Is the Wrong Question

Will AI replace ERP? The Goldman Sachs research says no but unpacking why reveals what enterprise buyers actually need to prepare for.

The key technical distinction is between deterministic and probabilistic systems.

Deterministic systems execute precise, repeatable transactions with zero tolerance for error. Financial ledgers, inventory movements, procurement approvals, payroll processing, and compliance reporting all fall into this category. An ERP system processing a multi-entity consolidation or a three-way purchase order match cannot afford to be correct most of the time. It must be correct every time, with a full audit trail.
Probabilistic systems including AI language models, produce outputs based on learned patterns. They excel at tasks where speed and approximation are acceptable: content generation, research summarization, customer support triage, and data analysis. A 95% accuracy rate is a strong result for AI-generated content. It is a catastrophic result for a financial ledger.

The architecture emerging across enterprise technology in 2026 reflects this reality. AI agents are increasingly functioning as the reasoning and interface layer. Thus, interpreting user intent, surfacing recommendations, and orchestrating cross-system workflows. ERP systems remain the execution layer where transactions are committed, financial controls are enforced, and regulatory compliance is maintained.

So rather than framing it as will AI replace ERP, the more accurate question is: how will AI sit on top of ERP and what does that mean for buyers evaluating systems today?

ERP System Scorecard Matrix

This resource provides a framework for quantifying the ERP selection process and how to make heterogeneous solutions comparable.

Download Now

What This Means for Organizations Evaluating ERP Right Now

The debate playing out in financial markets has direct practical implications for enterprise buyers. There are three dimensions worth addressing.

ERP Vendors Are Embedding AI Fast

The notion that AI will replace ERP assumes that ERP vendors will stand still while new entrants build AI capabilities around them. That is not what is happening. SAP has launched Joule, its generative AI assistant, which draws on process and business data across S/4HANA to surface recommendations and automate workflows. Oracle has embedded AI throughout its Fusion ERP suite running on Oracle Cloud Infrastructure. Microsoft Dynamics 365 has integrated Copilot across its ERP and CRM modules. Workday acquired AI platform Sana specifically to extend its reach as an intelligent front door to enterprise workflows.

Legacy ERP vendors may actually have a structural advantage here. Their deeper backend architectures and richer longitudinal datasets make AI agent integration more straightforward than rebuilding AI-native applications from scratch. The AI-native ERP category is still young, and long-term reliability, governance, and compliance capabilities remain open questions for most new entrants.

The Real Risk Is Vendor Lock-In, Not ERP Replacement

While the research makes clear that “will AI replace ERP” answers to “no,” the more immediate risk for buyers is a different one: selecting ERP vendors or signing contracts that limit your ability to leverage AI as it matures.

Goldman Sachs’ own evaluation framework emphasizes system-of-record ownership and data integration moat, both of which favor established ERP platforms. But the report also stresses execution: vendors that actively integrate new AI capabilities are better positioned than those that bolt AI onto legacy interfaces cosmetically. For buyers, this translates into a concrete evaluation criterion: what is this vendor’s AI roadmap, how is it priced, and does it build on open standards or create new layers of proprietary lock-in?

ElevatIQ’s 2026 Digital Transformation Report flagged this tension directly: AI disruption is forcing traditional enterprise software vendors to redirect R&D investment, with on-premise products receiving minimal attention and some offerings approaching end-of-life. Organizations evaluating ERP need to assess whether their shortlisted systems position them to leverage AI capabilities over the next five years or whether they will find themselves locked into architectures with limited optionality.

AI Changes What You Should Evaluate, Not Whether You Need ERP

One of the most practical takeaways from the Goldman Sachs report is that AI does not eliminate the need for rigorous ERP selection, it raises the stakes. The nature of what to evaluate shifts, with new criteria sitting alongside traditional functional and integration assessments:

Does the vendor provide AI capabilities embedded in core workflows, or only as add-on modules at extra cost?
How does the vendor’s AI interact with your organization’s proprietary data and who governs that interaction?
How is the licensing model structured as agentic AI adds value independent of user headcount and will the vendor try to reprice based on agent consumption?
How does the ERP’s AI roadmap position your organization relative to the orchestration layers likely to sit above the ERP in future architecture?

These are not planning questions for three years from now. They belong in vendor RFPs and contract negotiations being written today.

The Buyer’s Takeaway

The organizations most exposed to the AI disruption narrative are not those running ERP. They are those that deferred ERP investment in favor of fragmented point solutions that now face genuine substitution risk from AI agents and those that signed rigid multi-year ERP contracts without provisions for AI flexibility.

Will AI replace ERP? The analysis suggests the answer is no. ERP’s role as the deterministic backbone of enterprise financial and operational data makes it structurally necessary for any AI-augmented enterprise architecture. But ERP buying decisions made today without factoring in vendor AI maturity, licensing flexibility, and architectural optionality carry real risk of aging poorly in a fast-moving environment.

Conclusion

The Goldman Sachs “Will AI Eat Software?” report is not a verdict on ERP obsolescence. It is a carefully structured analysis of where AI disruption risk is concentrated and where it is not. Will AI replace ERP? Based on the research and underlying technology considerations, the answer appears to be no. The ERP systems are the data foundation AI depends on, not a workflow layer AI can replicate. The risk for enterprise buyers lies not in ERP being replaced, but in selecting vendors or contract structures that limit their ability to benefit from the AI-augmented architecture now taking shape.

Working with independent ERP advisors, who have no commercial relationships with the vendors and system integrators they evaluate, gives organizations the objectivity to distinguish genuine AI capability from marketing claims.

ElevatIQ’s enterprise technology selection services are built on exactly that vendor-agnostic model. As independent ERP advisors, ElevatIQ helps organizations cut through the AI disruption noise, evaluate vendor roadmaps honestly, and make ERP decisions that hold up well beyond the current market cycle.

All commentary represents an independent editorial perspective based on publicly reported information.

ERP Selection: The Ultimate Guide

This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.

Download Now

FAQs

Will AI replace ERP systems in the near future?

No, current analysis suggests AI is unlikely to replace ERP systems. ERP serves as the deterministic backbone of enterprise operations—handling transactions, financial controls, and compliance with near-perfect accuracy. AI, on the other hand, is probabilistic and better suited for analysis, recommendations, and orchestration. Rather than replacing ERP, AI is expected to sit on top of it as an intelligent layer.

If AI won’t replace ERP, what is the real risk for organizations?

The real risk is not ERP becoming obsolete, but making ERP decisions that limit future AI adoption. Organizations that choose vendors with weak AI roadmaps, rigid licensing models, or closed architectures may struggle to leverage AI effectively as it evolves. Vendor lock-in and lack of flexibility are more immediate concerns than ERP replacement.

How should organizations evaluate ERP systems in an AI-driven environment?

ERP evaluation should now include AI-specific criteria alongside traditional factors. Buyers should assess how deeply AI is embedded in workflows, how it interacts with enterprise data, whether pricing models account for AI usage, and whether the vendor’s architecture supports future integration with AI orchestration layers. These considerations are critical for ensuring the long-term relevance of ERP investments.

“Will AI Replace ERP”: What the Goldman Sachs Report Means for ERP Buyers Read More »

	LinkedIn Sam Gupta
	LinkedIn ElevatIQ
	LinkedIn WBSRocks

Featured Case Study

Featured Resource

Featured Video

Featured Resource

Upcoming Webinar

Featured Webinar

Featured Case Study

Featured Resource

Featured Video

Featured Resource

Upcoming Webinar

Featured Webinar

Enterprise Architecture

Why Year 1 Feels Affordable

The Three Drivers of ERP Contract Costs Year 2

AI Add-On Pricing: The Module That Wasn’t in the Original Scope

ERP Selection Requirements Template

Consumption-Based Pricing: The Cost That Grows With Your Success

ERP System Scorecard Matrix

Post-Go-Live Change Orders: The Budget Line Nobody Created

Why Clients Almost Never Budget for This

Conclusion

ERP Selection: The Ultimate Guide

Why the Post-Shortlist Phase Is Riskier Than It Looks

The 8 Most Common ERP Vendor Shortlisting Mistakes

Treating the Shortlist as the Finish Line

Letting Vendors Control the Demo Script

ERP Selection Requirements Template

Evaluating the Vendor Without Evaluating the Implementation Partner

Negotiating Price While Overlooking Contract Terms

ERP System Scorecard Matrix

Losing Internal Stakeholder Alignment After the Shortlist

Skipping a Defined Success Framework Before Final Selection

Underestimating Data Migration Complexity at This Stage

Accepting the Vendor’s Proposed Implementation Timeline Without Scrutiny

The Conclusion

ERP Selection: The Ultimate Guide

Why a Genuine ERP Readiness Assessment Is Rarely Done Honestly

What an ERP Readiness Assessment Actually Looks For

Leadership Alignment That Is Surface-Deep

ERP Selection Requirements Template

Process Documentation That Does Not Exist

ERP System Scorecard Matrix

Data Quality That Has Never Been Assessed

Internal Capacity That Has Been Underestimated

A Change Management Capacity That Has Not Been Built

ERP Readiness Assessment: The Indicators That Signal a Real Go-Ahead

What an ERP Readiness Assessment Gap Means for Project Timing

The Role of Independent Assessment

ERP Selection: The Ultimate Guide

What Most ERP Training Gets Wrong

Role-Based Training: Aligning Learning with Work Reality

ERP Selection Requirements Template

Training Timing: Retention and Application

ERP System Scorecard Matrix

Super-User Development: Building Internal Capability

Training Materials: From Documentation to Usable Knowledge

Measuring Training Effectiveness

Training as a Structural Component of ERP Success

Conclusion

ERP Selection: The Ultimate Guide

Why ERP Integration Architecture Decisions Matter Early

Real-Time vs. Batch: A Decision About Business Behavior, Not Technology

Real-Time Integration: Where It Adds Value and Risk

ERP Selection Requirements Template

Batch Integration: The Default That Is Often Overlooked

ERP System Scorecard Matrix

Middleware: Control Layer or Additional Complexity?

When Middleware Solves the Right Problem

When Middleware Introduces New Risks

Integration Governance: The Difference Between Architecture and Entropy

Failure Patterns in ERP Integration Architecture

Designing for Scale: Beyond Initial Implementation

Conclusion

ERP Selection: The Ultimate Guide

The Gap Between the Stated Reason and the Real Reason Behind Why Companies Change ERP

When the System Is the Symptom, Not the Cause

ERP Selection Requirements Template

The Most Common Misdiagnoses When Companies Change ERP

Reporting Gaps Attributed to the System