Your data is a hostage when you go SaaS
8 Likes
We make over 1 million API Requests a day because @jgiese.wci loves to Backflushā¦ I wonder if they will charge us after 10,000 requests 
Thats means over WAN if he have 1 hiccup our Qty Reporting / Ignition will break, damn sounds fragile doing OEE over WAN.
7 Likes
Donāt give them any ideas!
4 Likes
I think these are quite standard requirements for any ERP implementation, I would like to think someone at Epicor has this on their radar / scope.
My opinion, we should not have to pay additional fees to have real time access to our data that is key to our day to day manufacturing processes.
Epicor has facilitated us in having 0 lead time from sales order entry to jobs being manufactured on the shopfloor - but I need access to my data to provide transparency for everyone involved in the āmakeā process.
To suggest paying for this on top of standard fees is either absurd or ignorant.
Or both.
4 Likes
I think these are quite standard requirements for any ERP implementation, I would like to think someone at Epicor has this on their radar / scope.I think these are quite standard requirements for any ERP implementation, I would like to think someone at Epicor has this on their radar / scope.
You would like to think so but i am not sure they have, we will see what happens over the coming days/weeks when we have discussions directly with EPICOR
2 Likes
Vantage 8.03 ftw!
10 Likes
Yeah what about guys like poor Vic here! A veteran of Epicor. In the trenches, men, face down in the mud. A lone soldier. He only just got to 10.2.500!
13 Likes
@bderuvo has been trying to convince him to go to the cloud since the 90s, but he is stubborn and loves concrete.
4 Likes
This was an inevitable decision for Epicor. Make no mistake, this is all revenue driven as it will increase revenue substantially for them and make investors happy. If Iām moving to the cloud, Iāll move to Acumatica - it was built for the cloudā¦ not this bloated legacy lipstick on-a-pig ERP system that still utilizes tildes to separate Sales Reps in one field.
Perhaps a silver lining here, those of us with stable on-prem solutions wonāt have to deal with the ridiculous and endless upgrades to keep up with support. We can now drop maintenance. I havenāt leaned on Epicor support in a decade. Why am I paying annual maint? For them to jam more quarterly hotfixes, patches and upgrades down my throat and give me more headaches and projects? Iām good dude, I have enough to do already.
I was one of the last to abandon Vantage 8.03 because it worked. Always. Iām on 10.something now and probably should upgrade according to mostā¦ but why? It works. My user base is familiar with it. Iām familiar with it. Itās stable - it gets the job done. It does everything we need and more.
Iāll be fine running 10.something until 2050 and happily not shelling out annual maintenance fees. Itās like living in a neighborhood with an HOA and paying monthly dues and never using its amenities. Iām content with living on 20 acres in a solid log cabin and not paying HOA fees monthly and ākeeping up with the Jonesāā.
Thereās no way Iād go to the cloud with Epicor. Not saying āthe cloudā doesnāt have its benefits, but Iām not interested.
23 Likes
Exactly Vic! We try to upgrade annually to remain current with Supportā¦ But at other companies we upgraded when it made sense, 10.1.600 worked fine, then Functions came and we went to 10.2.600 ā but overall there is absolutely zero need to upgrade to every patch, and even if you do, Epicors upgrades are extremely easy. An Epicor Customer with 1800 seats still runs on 10.2.700, the business doesnāt need every module, all the time ā once you find a stable position - stick with it, and keep monitoring release notes for bug fixes until you find that āOh this is importantā.
Even in the cloud, Epicor will NOT uplift your Customizations, and that is the hard part. Pushing the upgrade button and pointing to another .zip is 10 seconds of hassle.
We ran Epicor 9 for 35 users on a Dell Latitude Laptop for 2 years, worked fineā¦ It was Windows 7, not even Server at that time ā sure slow when you have 3 instances but againā¦ You can host Epicor yourself for 100$ now.
5 Likes
Well said Vic!
2 Likes
I hate how Epicor implies that non of us are competent enough to host Epicor ourselves. Do they think that non of us have other enterprise IT systems? Epicor isnāt even the most complicated or resources intensive thing we run on-prem.
6 Likes
TBF rate limiting is glaringly absent. Implementation using existing Azure features and established patterns with advance notice would be temporarily disruptive for some clients whoād need to align their API use.
I wouldnāt be terribly surprised if they tasked an intern to shadetree a proprietary solution on an 8 hour budget and break their own software as a surprise in the process instead. Still needs to happen for lots of tragedy of the commons reasons though.
2 Likes
If you pay for the replicated db, you can get direct read access.
If you want to write, you will need to redo your tooling and applications.
3 Likes
We finally got off that just last year, and the year before for another site.
3 Likes
That announcement back in November about maintenance increase hits different today. I took the opportunity to reword it for Epicor:
To cover expected loss in revenue by a decision we have yet to announce, a 10% annual increase will be applied to your contract, effective on your renewal date.
Now all those On-Prems that bail, meh, we donāt care.
10 Likes
Do we think there is any value in respectfully expressing our disappointment to our CAMs? The discussion here is great (mostly), but may be just preaching to the choir.
3 Likes
Nah. They have no power.
And they want the commission off a SaaS sale. So they donāt really care what us on-prem folks have to say.
4 Likes
Yes, we should focus on actionable items. The on-prem community has some decisions to make. The options:
-
Stay on Kinetic
Use Epicorās cloud or with one of the still unmentioned hosting providers. One can use the Ascend service to upload to the cloud or do a reimplementation. -
Migrate to another Cloud ERP
Even if one finds an on-prem system, one may find themselves in this same situation. Cloud ERP seems to be here to stay. -
Stay On-Prem
Stop at 2028.1 and pay, or not pay, for sustaining support. At some point, the underlying infrastructure (Windows/SQL Server) will become unsupported, or security/compliance issues will overtake the system and the can canāt be kicked any further down the road.
The five-year clock is ticking.
I largely agree with everything that Jose has said, but Iām going to push back here a little bit. I was an early cloud user in a Single Tenant (on-prem in the cloud) in 2015 and I was also one of the first Dedicated Tenant/Public Cloud users in 2017/18. I LOVED the cloud product and promoted it at Insights (2 sessions) and the MI-IN EUG meetings. I even had a small series here on EpiUsers called āCloud and Obnoxious.ā I was the āCloud Guy.ā
In those years I talked with Mark Pladson and Matt Meyers about the mistakes made with Multi-Tenant. The amount of additional code to āsecureā MT was tremendous. Why split the codebase between on-prem and cloud? 
I and other cloud users mentioned that we needed a cloud portal eight years ago. Upgrades were large events with big batch processes run manually around the world. They had some automation (except for the hardware) things were managed like an on-prem admin would with hardcoded scripts. My complaint was that Epicor was slow to adopt cloud practices and that they should be demonstrating these practices to the on-prem people to change the mindset. But cloud culture at Epicor has moved at a glacial pace.
With the advent of .NET Core and containers, things changed. But instead of bringing that world to the on-prem users, they locked it behind the cloud. If one wants people to stay current, why block the very techniques the rest of the world uses to do rapid deployments? We STILL argue about the importance of DevOps.
Again, I think there was a path where Epicor could have solved the problems Jose mentioned above by bringing the on-prem people along the cloud journey. Cloud architecture works on-prem too. And the nice thing is that once architected that way, users have the freedom to move in and out of the cloud as needs dictate. Imagine if āon-premā ran the same exact way in the cloud? The users would use the same container images and pipelines. One day, a hardware refresh comes in at high price or a security incident happens. The customer could ship the database, config, and Epicor could have that customer up and running in no time - and get revenue for selling a recovery license. No Ascend program required because the architecture is the same. Or a companyās business has slowed down. They run the container locally to save on infrastructure costs, but Epicor continues to earn revenue from the subscription. Itās the second self-inflicted wound by making two versions of the software.
Vendor lock-in in ERP will break down in the future, but thatās a story for another day.
Anyway, why is the āCloud Guyā disappointed? The move to the cloud for Epicor was based on predictable revenue streams. I am concerned that the organization doesnāt actually believe in cloud architecture and that the current instability will only get worse with an influx of more users. Other Cloud ERP companies were born that way. None of these competitors had to be convinced that cloud architecture was a good idea. For this reason and lack of transparency that other users here talk about, my confidence in the Epicor cloud is low. It feels like they are over their skis. Companies need to trust in their hosting service. As I told my CAM, mine is lower than Iād like it to be.
25 Likes
.NET Core LTS only is supported for 3 years 
4 Likes