If they’re available then that is fine. I’ve not seen SaaS from the customer side. I just know I need a client right now for functions.
1 Like
You would need to download power tools.
3 Likes
I’m not spokesperson for our company and this is my personal perspective.
I’ve been waiting to chime in partially because I can’t find the right words that I feel will make the most impact but I’m going to give it a shot.
In an already cruel world of software companies trying to nickel and dime customers, this hit me harder than it probably should have. I felt Epicor was one of the unique companies that still had a shred of value for the minority customers over the shareholders.
But that announcement was very hollow with no remorse for the investments that an on-premise customer has made. They spun it like all we needed was their support. It assumed 5 years was enough to get years of local interconnected systems back into parity. It was as if they assumed we just used Epicor in a silo and the migration would be seamless.
I wish I could capture and let the VCs hear my inner dialogue as I start the day and before bed. I won’t lie, it’s has taken an emotional toll on me because of the amount of time, work, and cost involved. Especially in the current/future state of the businesses agricultural market. I guess that is my own problem to sort out.
One point about the announcement that bothers me is that there was no supporting documentation about how this transition would have any chance for a ROI for on-premise customers. We work with Salesforce and it is clear, that they at least attempt to sell you something that will make you money even if their calculations don’t align with your business.
As many have pointed out, this move is the exact opposite. It feels completely one sided. Maybe Epicor should send bombshell announcements to Salesforce marketing to help spin it as a win-win strategy instead of alienating the customer.
14 Likes
Indeed. A LOT of AI can be done on prem, especially when vector column types come to SQL Server.
After some thought, I don’t think this decision is about AI at all. It’s about maintaining versions for two years. Let’s face it. We on-prem people ARE slow to upgrade. And we’ve talked about this in other threads, the longer time between upgrades is actually harder for everyone. With more frequent releases and sensible use of feature flags, I think on-prem would be more likely to upgrade vs the big change upgrades. This is how cloud companies work. SalesForce does three upgrades a year but M365 is update daily and browsers upgrade as needed. I think AI is a distraction and not the real reason for the move. It’s not just revenue, it costs a lot to maintain multiple versions.
7 Likes
They already end active support two years after release. It’s not costing them anything to maintain older versions because they don’t.
5 Likes
This would drop it down to one. 
And yes, supported versions are not getting back patches today, but they still have to field the cases. Just make it official.
5 Likes
Alright… I think we just crossed 500 comments in this thread. That officially makes this a legendary EpiUsers post. 
I wanted to hit pause for a second… not to shut this down (actually the opposite)… but to say thank you. The volume of comments, suggestions, and hard-earned real-world perspective in here is exactly the kind of feedback that helps shape the roadmap in a way that’s grounded in reality, not slide decks. (EpiUsers says this thread is 88 minutes of reading).
I’ll also be honest: the way this thread unfolded didn’t really surprise us. We have seen enough big announcements land over the years to recognize the pattern. It usually goes something like:
Trigger → Outrage → List of impacts → Receipts/Trust Collapse → Containment → Funny Memes → Polarization → Mobilize/Solution → Long Tail
And honestly… yeah. This thread has checked most of those boxes (but maybe not quite in that exact order). Surprisingly we got to the solutioning phase at the end of the second day… this moved very fast. More “First time posters” and “its been a while since” posters on here than I have seen. With over 3500 views by 111 users, we see how important this topic is.
A couple of important notes:
- I’m not trying to “close” this thread.
Keep the perspectives coming. The most helpful posts aren’t always the loudest ones… they’re the ones that explain why something matters, what it breaks, and what a workable path forward would look like. - Let’s keep it civil.
One thing I didn’t expect was folks starting to take shots at each other. I get it… this is a charged topic and it’s easy to go from “I disagree” to “you’re wrong.” But when it turns into arrows, what we end up with is the worst possible outcome: the people with the best points decide it’s not worth posting at all. And silence is not what we need right now.
We’re reading this daily hourly. We’re pulling out the recurring themes. @JenTrifty and I (And others) have been forwarding hard hitting comments and suggestions onto the leadership team. We’re working through what we can answer now vs what takes more time to publish cleanly and accurately. And we’ll keep sharing what we can as we go.
Thanks again for the energy, the honesty, and yes… even the memes.
Now… back to (constructive) commenting!
22 Likes
Thanks for for the willingness to take feedback and listen Tim! It really helps.
One thing I would like to point out that I think is really different with ERP (especially small to mid market) VS every other SAAS product out there, is it’s servicing a physical manufacturing businesses. Physical manufacturing is hardware. Not software. It can’t move and change as fast as something like spreadsheets and email and marketing and CRM. It’s making systems that have to try and get data from machines a that are 10, 15, 30 years old. For software that’s ancient. For a stamping press, that’s halfway through it’s workable lifespan. So these companies trying to do this work are trying to make stable plans for decades. If they had to constantly redesign their shop floor every time a fad like “responsive design” “low code” “AI” or whatever high tech thing is coming out they would never have time to actually build anything. It’s a physical business, not a software business. Companies that run kinetic ERP want to be able to get it to where they can use it and where it can be stable so that they can focus on what they do, not have to constantly be updating every 5 minutes to keep up with whatever new shiny feature their SAAS maker thinks is a good idea. You can’t copy paste to scale up manufacturing like you can in software.
I know that new and fancy sells new customers, but bulletproof and steadfast retains customers. If a customer can’t think of the last time they had an real issue with you’re software they are going to have a really hard time being convinced by any slick salesman to switch to anything else for some new fancy feature.
This pushback that is happening because of the the announcement to being a cloud only provider isn’t because cloud in inherently good or bad, it’s because it forces the customer to put 100% trust and faith in the company that now is holding the beating heart of what it takes to run their company in its hands and if they screw it up, they have absolutely no recourse to save themselves. They can’t stop an upgrade with a breaking change, they can’t stop paying Epicor while the move to a software that does work for them when Epicor makes a change is unworkable for their company, or prices them out of profitability. They are giving ALL of the power to Epicor. At this point in time Epicor has not yet proven themselves to be a reliable enough partner to garner that much trust. Both in quality of software, and in the direction and leadership of the company. What we are seeing is a company that is pivoting around ideas like a 5-10 year old startup being handed around to various VCs, not a company with a 30+ year old rich history. We don’t know who’s driving the boat, and we have no idea where we’re going to be in the next 2-5 years. If we were all in the tech world, that might be ok. But we’re not, we’re in manufacturing, we need to be more stable than that.
I could go on, but I think you get the point. I just wanted to try and put into words what I think is really driving the underlying angst behind the reactions that we are seeing and feeling, and trying to navigate. Hopefully this helps someone somewhere understand better.
61 Likes
You’re spot on @Banderson. This echos my thoughts far better than I could have said it.
10 Likes
Well said Jose, we feel exactly the same way and have invested in the Epicor Framework to meet our business needs. I am very disheartened by the news too. I always sold Epicor to my peers as the one you can run and customize how your business needs. My whole thought process is in uproar at the moment. Not sure I can sell this model to the business either!
3 Likes
Here’s Gemini’s summary to this prompt:
Please summarize this thread. What is important to Epicor and what is important to the users?
This forum thread discusses a major shift in Epicor Kinetic strategy: the decision to end on-premises development by 2028 and move exclusively to a cloud-based model.
The conversation reveals a significant disconnect between the vendor’s strategic goals and the operational realities of its customer base.
Summary of Perspectives
What is Important to Epicor?
Based on the discussion, Epicor’s move is driven by business sustainability and technical streamlining:
- Reduced Maintenance Costs: Maintaining multiple legacy versions and installation artifacts for on-premises users is expensive.1 Moving to a single cloud version simplifies support.
- Innovation Velocity: Epicor aims to deploy features (like AI and automation) more rapidly. They argue that cloud delivery allows for frequent, smaller updates rather than massive, risky on-premise upgrades.
- Market Alignment: Following the trend of other SaaS giants (like Salesforce or M365), Epicor is pivoting toward a “subscription-first” model to satisfy stakeholders and stay competitive in the tech landscape.
What is Important to the Users?
The user community, particularly those in manufacturing and regulated industries, expressed several critical concerns:
- Regulatory Compliance: Many customers (subject to ITAR, CMMC, or DFARS) require “sovereign” control over their data. They worry that a standard cloud offering won’t meet strict legal and audit requirements.
- Operational Stability: Manufacturers view their ERP as the “beating heart” of their company. They value “bulletproof and steadfast” systems over “new and shiny” features, fearing that forced cloud updates could break local integrations with decades-old machinery.
- Cost and Control: Users are concerned about the shift from concurrent to named-user licensing, which could significantly increase costs. They also feel they are losing the “recourse” to stop an upgrade if it isn’t ready for their specific environment.
- Long-term Trust: There is a feeling of “trust collapse.” Customers who invested heavily in the Epicor Framework feel alienated by a decision they view as prioritizing venture capital interests over long-term customer partnerships.
Key Takeaway
While Epicor employees in the thread are actively listening and forwarding feedback to leadership, the core conflict remains: Epicor is prioritizing agility and modern SaaS standards, while users are prioritizing stability, compliance, and autonomy.
14 Likes
That’s a neat summary!
Given all the different (valid) concerns and issues raised, I do wonder the following:
-
How many people here, and organizations, would have a similar level of concern if Epicor was able to release annual Linux based containers, with most but not all new Kinetic functionality, that were effectively immutable (i.e. read-only except maybe a limited number of configuration settings) which organizations could host within very specific hardware configurations on-premises?
Or in other words, how much of the concern is about the control of the versions, the data, maintenance/uptime, cost/offramp flexibility, etc. vs concern of not being able to continue using previous customizations and extensions that may need re-architecting for a Linux container-based configuration anyway? -
How about if the only supported “On Premises” option was to deploy effectively immutable Kinetic ERP Containers (AKS or other) within an organizationally owned Microsoft Azure environment?
It seems that for many, the compliance, stability, control, and flexibility are the main drivers which maybe a Microsoft Azure (or similar) container option could alleviate while for others, continued support for extensions and customizations that may need re-architecting is possibly a bigger concern.
2 Likes
I would have no complaints if Epicor said I had to run it on Linux on-prem in containers or in Azure on AKS (in our Azure environment). That would continue to give us the flexibility needed and the control we want. There would be some work involved to rework the integrations that currently depend on Windows. But, if it meant we could keep our on-prem or our own Azure AKS (or similar) we’d do it.
6 Likes
Thanks. We have done multiple queries similar to this and have gotten similar results. But since this is ongoing, each time we have more and more data to summarize and the answer shifts a little. After the first day, there were not as many suggested ideas as there are now.
Keep the ideas flowing.
5 Likes
In actual fact there have been some Epicor Ideas that have still set as gauging interest. Development environment container availability logged over 12 months ago with only 12 votes. Hanging off that was this idea from @Mark_Wonsil Make the software more friendly for DevOps Practices for Customers , the Cloud Team, and Professional Services which has 310 votes (Yikes!) and was raised back in 2020. There was another idea asking for the Docker Installation Pattern raised 2021 with 12 votes and got shut down… My feeling here is that if these ideas were not ignored then we would not be even having this conversation. Yes I am disappointed, after working with Epicor products all the way back since 1998… I hope that something can be turned around on this decision.
10 Likes
Hi Tim,
Appreciate the response, and Epicor continuing to monitor the thread.
I think most of us understand that Epicor is unlikely to change course on this, even after years of assurances that on-prem remains a supported route. That said, the timing feels somewhat tone-deaf. This is the same year that Classic is finally being removed from the product, and many customers are already absorbing the workload that comes with that change. Regardless of how long Classic retirement or cloud migration has been signposted, that still represents two major shifts to manage.
We are deploying a significant number of line-of-business applications via containers, and I also do software development covering native Windows builds, Linux/Windows containerised versions, and internally-developed Kinetic LLM-based AI programs. I’m very aware of the additional engineering effort required to make software work reliably and predictably in containers compared to a purely native deployment.
It’s unclear whether Kinetic Cloud is fundamentally container-based or virtualised. If it is container-based, one possible middle ground might be the release of an LTS-style container build every couple of years, allowing customers to run it within their own on-prem container environments.
Ultimately, a stable ERP system is far more important to many of us than one that receives frequent feature updates. From a manufacturing perspective, most of our AI improvements will come from our machines, the systems that control them, and the hardware we wrap around them. We are part of the CO-AIMMS programme alongside Epicor, and this work is inherently on-prem and shop-floor based.
Prior to this announcement, I would have unhesitatingly ensured that all of this machine and process data flowed into our Kinetic SQL database. At this point, it is genuinely unclear whether Kinetic will ever see any of our machine data at all.
I hope this makes sense as to why we choose on prem and, as a manufacturing group, how we see AI developing across our companies.
Thanks,
7 Likes
Just had it confirmed - it is currently based on concurrent users.
1 Like
Keep the ideas flowing for what though. Epicor has not (almost a week later) actually explained WHY they are taking away on premise deployment options. Sure there is rampant speculation in this thread, but no actual confirmation of what is driving the decision. The foundation of negotiation is understanding the other party’s objection. What is Epicor’s objection to on premise?
12 Likes
That’s how dialog works? Epicor has given us a 2 year timeline. Which mean that these ideas and conversations have a real possibility to influence the future roadmap.
No, I don’t think Epicor is going to revert their overall strategy and plans. But there is a very real possibility that constructive dialogue will lead to an outcome that is palletable to both sides
13 Likes
Okay, Randy, sorry I suggested Google. Perhaps what I should have said was use your business intelligence and interview prospective Epicor partners. Thanks for the policing.
2 Likes