Honestly Chad, I don’t think I’m special in that regard. I network a little at insights and just ask nicely. The Epicor product managers are usually helpful. @Banderson knows I’m not shy.
I’m not arguing about @bderuvo experience, I’m very glad he is fully satisfied with his cloud experience. But I’m not going to turn around and dismiss my users and call them a bunch of whiners.
Everyone has their own experience and perspective, and I don’t think anyone needs to be told to read a post on the internet with the knowledge that it might not reflect the entire picture. When someone in a position of authority says “Dont believe everything you read here, some folks just need a platform for whining.” I find it to be and upsetting dismissal of a broad group of people and permission for Epicor to ignore any feedback they don’t like as ‘whining’.
Offering a counter experience is enough.
My experience is the same. But I have been lucky and have only worked with 2 CAMs over 11+ years even though I have jumped companies. I have heard other people say that their CAMs are not that helpful or responsive, but lucky for me, that has not been my experience.
Especially when top leadership at Epicor is “hearting” said sentiments. Its not listening to customers when only certain customer voices are considered worth listening to.
Appreciate you both @bderuvo and @Evan_Purdy. 
I’m not sure whether to take insult by that remark, or not 
But yes, I would say our Cloud deployment is relatively kept within the bounds of Epicor’s provided tool set. I would also say this is primarily because I’m not an IT person by education and yet I’m saddled with being our system Admin and customizer. So, the breath of our customizations (outside of some paid consultant work during and briefly after our go-live) are limited to areas where I feel comfortable playing & deploying. Keep in mind our Epicor instances are only ~3 years old. A lot more customization and integration will certainly occur as our system admin gains more experience and actually learns what the Hell he’s doing (again, that’s me).
I haven’t chimed in on this thread, though I’ve been following it closely. We had a very strong desire to stay on-prem when we were exploring new ERP systems. One of the reasons we chose Epicor was because they offered both. The final decision to go cloud-first was primarily due to my company’s lack of support staff. Before/during/and after implementation, the goal was always to hire a true system admin (not some ex-engineer with an MBA who enjoys using Excel and is a vibe-coding hack, like myself)… but, as most things go, three years later I’m still the one sitting in the chair. But, the fact that Epicor offered on-prem, we always felt (once resources were put in place… and swallowing the required ransom payment to do so) we could pull our implementation back in-house (without the need to completely change ERP platforms) if we felt so inclined.
I feel we dodged a bullet by going cloud from the start. Had we gone on-prem initially, we may have explored and developed a lot more integrations with other platforms which we DO currently have on-prem. That would’ve made a forced migration a lot more difficult and I feel for my friends here that are now being shoe-horned into a structure that doesn’t fit their needs… or at least not without a good deal of time and investment to restructure. Even things as simple as external BAQs are going to have to be revisited.
I WILL attest that my cloud experience, for the most part, has been relatively smooth. A couple bumps here and there. I think I’ve only experienced a couple instances where our system was actually down. Dealing with support is certainly a chore. Cloud-folk were forced to do so just to do data regens, DB refreshes, etc. The new portal has started to allow us to handle that inhouse now, though, I still hesitate anytime I hit those respective buttons for our Live environment. Updates have had their issues and it is one of the reasons I always try to participate in the Controlled Releases. Its not just to get first glance of new features, but to have more time to test the new version and learn about potential bugs so I can have them patched (or at least a work around ready to deploy) when the update hits.
I don’t want to keep rambling on as I really don’t have a dog in this particular fight. I hear, understand, and empathize with those who were caught off-guard with this announcement. Words like “betrayal” are understandable. It definitely was a huge decision to shift Cap-Ex to Op-Ex when choosing cloud, and it shouldn’t be something that is forced on an organization. It is a choice that can deeply impact the financial stability of a company. The unknown cost yearly increases in cloud are also a deeply concerning topic. I’m 100% in the boat of “stop increasing my yearly rate… I don’t give two shits about AI… and I shouldn’t see my annual subscription costs increase because Epicor wants to keep up with the Jones’s”.
But hey, if our cloud costs weren’t increasing as they are, we may have had the funds to hire an actual admin and I wouldn’t be here. So… thank you???
One additional thing to answer @timshuwy since this is a forced move, who pays for the Customization Uplifts of Customers that may have External Assemblies, Advanced logic?
Its not our choice, since its forced, can you add Rebates / Discounts to your answers list, like the first year of Cloud may be free. Its a genuine concern in a year where our economy is at an uncertainty and world war 3 is around the corner – employers are rationing pennies, customers are buying less, tarrifs etc…
I hope the answer isnt just reach out to a consulting company and pay 350$ / hour, or hire more on-prem people, we cant even train them fast enough to be of use.
Some of us can do it themselves, but also – we have commitments already made for REAL WORLD projects, not to deal with an uplift right now.
Our partner thus far has been great – very objective and not pushing us in either direction, or trying to spin our issues as a push for cloud. He called me Tuesday before our demo and shared the announcement to make sure that it wasn’t a deal breaker for us.
A cloud-only model aligns well with our team’s preference and their buy-in is a top priority for me.
Cost is still an important factor in determining the solution that we choose. To walk back some of what I said, with on-prem support ending and if the delta between on-prem and cloud is truly inflated, we will most likely look at other vendors.
Personal opinion since moving to cloud it has opened more channels for us, yes at times it can throttle and become slow but there is usually a reason behind it, the only major issues we had was the november upgrade that broke a lot of parts of the system for a lot of customers which on our system is now all fixed, again we have only been on it a year but the positives outway the negatives currently.
Thanks for the feedback Connor!
Honestly, focusing on performance of the cloud is almost a distraction. Even if cloud had the same or better performance it would leave all the other valid reasons for wanting choice that people have raised. Performance was only ever one aspect that was raised. Right now there are people cloud hosting themselves, people having third party cloud providers host them, people on different cloud offerings provided by Epicor, and people hosting themselves on prem.
Clearly companies want choice. If Epicor SaaS was the best option for everyone without question, you wouldn’t see companies making all these various choices.
We recognize that moving from on-prem to the cloud can introduce real cost and timing concerns, particularly for customers with existing customizations, and that feedback is both understood and valid. While each customer’s situation is unique, Epicor does have programs and incentives available that can help make the transition more manageable, and we encourage customers to speak with their CAM to discuss what options may apply to their specific scenario. In parallel, we’re investing in tooling through the Ascend program to help reduce the effort and long-term cost of customization in the cloud, and we’ll share more details as that direction continues to take shape.
Responses from cloud users:
“yes at times it can throttle”
“the only major issues we had was the november upgrade that broke a lot of parts of the system for a lot of customers”
“Most of my issues on cloud haven’t been due to customizations, rather things completely outside my control”
“Cloud team / scripts failing to complete upgrades properly”
“printing going down”
“performance issues”
“updates being pushed through even when there are active PRB’s”
“some cloud migration issues with SSRS”
“a temp db issue where someone else’s baq effected several of us”
“an azure outage effecting our sso”
“epicor was slow for a couple of days”
I’ll stop here because this is enough to make my point.
Hi Roberto, thanks for:
- paying for Epicor for the last 15 years by direct debit
- being a reference site for 12+ years
- working closely with Epicor to close sales
(please someone form Epicor jump in here and publish the revenue gained from my participation on projects - let’s be transparent) - working closely with Epicor consultants on other projects
- working closely with VARs
I’d like to take this opportunity to TELL YOU that despite you never having an issue with outages, performance, upgrades you’ll be forced to the cloud where there are issues in every single area of ERP deployment and costs will likely double.
This is the crux of it - what is being forced on us is nothing short of disgusting.
I go back to what I suggested earlier, hurt the greedy venture capitalists the only place they care.
Stop paying maintenance fees for the now dead on-premise Epicor.
YUUUUP. My leadership team was already talking about it.
We are in the middle of hiring a consulting firm to get help with getting to Kinetic from E10 and when I tell my leadership this news… I know they’re going to want to shop around because they’ve all used SAP in the past and loved it. I started out in SAP so not really any skin off my back.
I suggest everyone reach out and get a quote for what their current licensing would be for Kinetic Cloud.
Wow, this is so disapointing. We are in the middle of an implementation and will now have to decide whether we abandon Epicor for something else. The cloud isn’t an option for 2 reasons:
- We only have 5Mbps internet that goes down frequently.
- We need to be CMMC compliant. Currently Canadian companies can’t sign up for GCC or GCC High, so we wouldn’t be able to migrate to the cloud. Also, our Canadian contracts require our data to be stored in Canada, and there is no GCC service in Canada.
We have a similar issue at one plant. Sure we could maybe get Starlink, but just for a moment let’s say you dont want Starlink, due to Elons politics, or perhaps it doesnt work where you are.
The reason you purchased Epicor was due to its LAN capability. I know PWA apps can run offline and sync when online, but most of the Epicor logic runs on the Server Side.
Its a valid concern, good case point for on-prem docker.
I could see us doing this again too. We were on 9.05 from 2009 to 2022.
Unlikely to be resolvable within the next 5 (or 7 years)? The vast majority of the sites I knew of with limited and unreliable internet 5 years ago now have multiple good options today.
If there are major technical/licensing/business reasons that would make it challenging for Epicor to commit to Kinetic 2029/2030/+ for on-premises installations, it would at least be good to have Kinetic 2028.1 officially supported in a capacity that would meet the various organizations compliance requirements.
Although, one of the major challenges I imagine Epicor is facing, or would face, along with many other organizations, is that even major frameworks and tools such as the .Net Core now only have 3-year official support cycles for LTS releases. And no one really knows when they might change which makes planning far ahead VERY difficult. .NET and .NET Core official support policy | .NET
Sure, there is still plenty of organizations lagging behind and not concerned about using unsupported/unpatched software stacks, often with known security issues, and there will continue to be for a long time, but I expect that even if Epicor wanted to provide extended official active support for Kinetic versions on older software stacks, it could lead to some serious questions and potential issues from auditors and major risks if there are any issues with out of support dependent frameworks and tools. I think anyone who has been around the space long enough knows how disruptive a single Microsoft or other security update can be…
Unfortunately, the whole Software/IT industry across the whole stack seems to be focused on a rapid innovation and evolution, short support cycles, cloud solutions, and subscription models, which is obviously a major issue and challenge for many. Particularly for core solutions such as ERP.
Hopefully there will be a way for Kinetic customers to get and deploy containerized versions of Kinetic 2029+, even if they potentially require a different level and set of administrative skills (i.e. Linux container administration) and potential associated costs (for dependency frameworks if needed - similar to how organizations needed to buy Crystal Reports and Infragistics for various aspects in the past), without significantly limiting/slowing down the development of the Kinetic ERP for the majority too much - as there is almost always significant trade-offs and costs per additional branch and model to be supported.
Otherwise, hopefully, the Epicor teams can work extremely hard to address and mitigate many of the Kinetic Product/Support concerns raised in this thread and elsewhere. I think that the Epicor Cloud stack, performance, and reliability is significantly better than it has been in the past, and there is a lot of misperceptions, but there is definitely room for improvement.
While, for those with major Classic/WinForm customizations and or custom assemblies developed within the old .Net Frameworks, I do think that no matter what Epicor does re On-Premises and Cloud, serious discussions and considerations should be made regarding re-architecting/migrating them into the toolset or into separate stacks integrating via the REST APIs. Even if Kinetic 2029.X+ is still available for On-Premise deployments, I think (guessing) that there is a good chance that it would be Linux container based as moving in that direction just seems like it is, and would be, the obvious path (cost, stability, performance, flexibility, etc.).