Can I ask why? We just upgraded to Cloud and are surprised to see the amount of bugs and issues we are coming across that seem to us to be no brainers that should have been caught during testing. Where was their Pre/Post checklist and UAT? Seems like there was none for simple things like trackers to have the wrong shortcuts etc. And we keep getting told to use the Classic screens or desktop client when something fails in the browser. ??? Interested in this topic we fear we made a mistake going to Cloud also…
The sheer size of our environment will be growing over the next 3 years. The cost ratio for the size we are growing to does not make sense to host in the Epicor Cloud.
Such a good movie!!
@alafrance Pretty sure you were not asking me necessarily, but since we did leave the cloud, I’ll explain why.
#1 reason was MRP kept timing out. MRP is critical for us, but our pleas to support basically fell on deaf ears. I mean, they later dismantled MT SaaS after we left, so maybe it did get through. But we sure could not wait around for that.
Everything else is secondary. Cost. Ability to restart task agent. (But there is a cloud portal now, right?) Delay upgrade till bugs worked out.
Also, call me crazy, but I’d rather be on the hook for system-down events. The other option is days of system down that I have no control over.
No. Thank. You.
(Edited below) Here is the middle of a discussion where the consensus is that SaaS offerings are much more powerful now. And other arguments for staying on cloud.
I was going to ask the same question … why did you make this decision? Was it based on cost? Security? Control? Customizability? We are on-prem with no plans to go to cloud.
Will they ever give us cloud users an option to choose when we do updates?
Being cloud and being forced to update DESPITE there being system breaking errors is getting really draining and costly.
I feel like if we all speak up and vote on an idea we could maybe get it to go.
I think as businesses they need to design the product around us. And we also have to acknowledge how hard it would be to maintain 50 different versions as a SaaS conmpany.
I don’t think they will ever allow you to choose upgrade schedule, as that would undermine their flex offering. However, I do believe they have in the works the ability to implement minor updates in the cloud portal.
No, One of the main drivers of them pushing people towards the cloud (second to recurring revenue) is that if they can get a majority of their customers on the same version, support and development costs can be consolidated and reduced. If there is a bug, they want to fix it in one place, one version. Having multiple supported versions is a drain on their resources.
That said, their QA is severely lacking, and if their push to the cloud is going to be successful, they are going to have to learn how to stop breaking things…
It’s been 10 years. One would think that would be long enough.
There is no cloud service that allows waiting indefinitely. At some point, you get moved: SalesForce, M365, etc.
With Kinetic, you CAN choose when to upgrade, to a point. There is a flex option that allows one to pick two other deployment dates.
What other cloud providers do is continuous deployment. There are feature flags inserted with changed functionality and a small group of users will get this flag turned on. The new code is monitored for errors and user feedback. If there are major issues, the flag is turned off and the previous code runs. Doing six-month cutovers to new versions will always be spicey - for cloud users or on-prem.
Michael Feathers wrote THE book on updating legacy code.
That said, with the wildly different ways people use Kinetic (both planned and unexpected ways), it is literally impossible to test all combinations of scenarios, and quite frankly, is a very unrealistic expectation. What there should be is a way to push down some of that testing to the users. Sure, there is common testing that should work for everyone (session management, etc.), but there are things that companies do because they think they are unique and make sure their software reflects that. These are the items that we should be responsible for. But Epicor should write the software that promotes this kind of testing and have it provide the feedback early as possible.
To @Banderson’s point, we should all want to be on the most supported version of the software. We would all be better off, cloud or on-prem, if we coded to the Cover and Modify methodology rather than Edit and Pray.
Yeah but that isn’t what we are expecting. We are expecting the bare minimum basic QA has been done and foundational functionality hasn’t been broken with every single release. And every release we are disappointed. One could argue we are the crazy ones for expecting something different at this point.
100% agreed, just the ability to do ONE upgrade a year would be great. We’ve got a small team any many other projects to manage. Having 2x a year major Epicor upgrades gets in the way. It’s frustrating so I hope they’ll allow one-skip a year.
1000000000000% this too.
Things will always break in software changes. Always. The pain is, and I think you’ll agree, is that the feedback loop is too slow. Things stay broken way too long before the next release cycle. To speed up the loop, have coverage testing by Epicor AND the users. I am sure that Epicor has thousands of tests run for each release. But it is going to take a much broader base to find errors more quickly to correct them. Pushing errors through the support channel? Too manual. There are better ways, and AI could actually help Epicor in this regard. If each company had their own tests and could post those test failures to a common store, Epicor could let AI summarize and look for correlations. It’s better to divide and conquer than to expect a central authority to make it better, IMHO.
Controversial, some of this is self-inflicted. It takes time and energy to take care of pets…
Yeah I think they need to improve massively on this part. I have nightmares the night before each update on cloud.
My typical pre-update flow:
- Contact Support about issue.
- Support says they can’t replicate the issue therefore there is no issue.
- Support says they’ve replicated the issue but the devs have not planned a fix.
- Support say the dev’s have planned a fix, but there is no date on when you will get the fix.
By step 4, I’m thinking “holy shi…this update is being forced into live in 3 days and I don’t have a date or sufficient time to test the fix”
Happening a bit too often for my liking. Then I remember seeing you guys in the USA had a huge downtime issue with Kinetic America’s back in April.
Having Support gate the issues is problematic and not scalable. Turn in your test(s) with logs. A good test log should cover reproducibility by showing what data arrived and what events did or did not fire on the client and the server. Support should provide help in running the software, not testing it.
Actual picture of me holding on to my on prem deployment.
Same. They’ll have the pry it from my cold dead fingers.
