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.