Just curious on how well the programs upgrade and if it is cloud ready. If they are paying maintenance and you upgrade as needed, good for you (and them). I know customers who are stuck at old revisions because their really great tools done by consultants years ago are too difficult to upgrade and/or not documented.
Jenn
Definitely not cloud-ready (customer has no intention of going to cloud, they are still on 10.2.500), but any other upgrade should be fine… It’s not really that the customer is “stuck” on that version, more that they haven’t been willing to upgrade just for the sake of it. Upgrading for them would mean a ton of migration hours and basically no return on investment.
Good consultants include documentation as part of the scope.
Anything is cloud ready, honestly. We’re running 10.2.700 in Azure in private instances, alongside our mobile application that interacts with Epicor. Whether BO or REST, it’s all about how data moves.
Definitely, if they went on a “private cloud” on Azure, there wouldn’t be any issue, it’s the same as on-premise… I think when “cloud-ready” is mentioned here it’s more about Epicor’s SaaS platform though…
No one should torture themselves like that.
It’s not that bad. Don’t get me wrong, I would rather be on-prem, but I have been pleasantly surprised so far.
It’s fine if you have a very “vanilla” environment… If you have a lot of customizations, it’s kind of a giant pain in the ass, mostly because of the forced updates schedule…
I quite enjoy it.
The torture. Not the cloud,
It’s a feature, not a bug.
I wish my hair was still that color…and length.
Going to gently push back here a little bit. As mentioned on this list many times, cloud is on a spectrum - much like myself. Sure, one can do Infrastructure as a Service (IaaS) and technically call it cloud but it would missing many of the benefits of cloud computing. I worked at a place that did the Azure private cloud thing with a full VPN and File access. When their local network was popped, so was the Azure instance. They couldn’t think beyond the file share invented by Novell so many years ago and lost the opportunity to segment the ERP system. Had they thought differently, ERP would have been available while the local network was recovered.
Thinking cloud is not an easy mental adjustment to make. While Epicor sells a SaaS product, it may more accurately be called LaSaaS: Lift and Shift as a Service. Kinetic is still an on-prem system. Adding REST, token authentication, and a web front end has been an excellent start. When we get to the day where we don’t upgrade the our pets and just spin up a new server, then we will be getting the benefits of the cloud. Hopefully, we won’t be stuck on a version because the types of customizations we made. The world changes for all kinds of reasons. Government regulations, new markets, the underlying infrastructure, and security threats. Architecting a system that can be readily changed to meet today’s new challenges takes a different kind of thinking than we had for the first 30 years of my career in IT.
We’re getting close to splitting this thread. There’s a LOT more to say. So I will close with this thought:
The cloud brings constraints. Constraints breed creativity. Some of the most impressive things I have seen on this forum recently have been brought to us by cloud users.
Re-open that thought bubble because the new thread is here.
We use Azure to mitigate site outages from affecting the entire network, as they have in the past. IaaS technically, but redundant, so DC isn’t lost, and ERP is still available. Sounds like cloud to me, at least in the area of redundancy ideas, not necessarily scalability.
I love working within constraints. I don’t love working with my hands tied behind my back and expected to slam my face into the keyboard for results (*with a certain cloud product).
I’ve worked on customers who were on Epicor’s cloud. A single-tenant instance is not bad and is worth real consideration but is still extremely limited. It appears to be for smaller companies to get started who also have zero interest in managing complex infrastructure, complex integrations, and customizations. It’s not overly complex, but it is for teams with limited resources.
I worked at a company who had a data center in a different location. It worked great when the headquarters lost power - left all the other plants/sites up and running. Plus the data center had redundant internet, proven backups, etc. We still were able to do SQL queries (not that we did ), which I couldn’t do when we were hosted with Epicor originally. They’ve made great progress with their cloud and additional options such as single tenant.
My original post wasn’t meant to stir up cloud vs on-premise… it was more to be careful when you write custom code that isn’t within the Epicor toolset (e.g. custom DLLs) because it can make upgrading more difficult. It’s also more difficult on people like me who support those custom DLLs that don’t have access to the code. One of my favorite phrases from an Epicor consultant and mentor: “Just because you can, doesn’t mean you should”.
Jenn
I really don’t see how. Explain why you think it’s limited.
Lack of control for administrative actions. Your neat tool is helpful for getting the event log in Epicor, which is one of the missing items that could be in the software.
Ahh, you got me there.
Having some conversations with some of the backend peeps leads me to believe that that is on
the roadmap, however I do not have any more knowledge than that.
Yes, they certainly can fix this for single-tenant instances. Obviously multi-tenants are stuck where they’re at. A management panel will add a ton of value to the SaaS product.
Portal for Cloud Users for Some System Tasks | Epicor Kinetic Ideas (aha.io)
When I was Single Tenant, I had access to the EAC. ST is just IaaS and I could RD into the server. Multi-tenant should die and be moved to Dedicated Tenant/Public Cloud - call it Public Cloud Express to bring it back it its roots. Simplify the code. These users would still be the first users to upgrade like today. But every cloud product should use the same admin panel. Why create more pets???
Again, this isn’t a cloud issue. It’s trying to force on-prem product into the cloud is where were stuck. What is needed is a management/administrator API. There would be endpoints that do the same things the EAC does plus some infrastructure tasks: spin up a base version, spin up a dev instance, spin up an Education instance, patch to the current version, copy a database to another instance, restart the task agent, regen the data model, upgrade the instance, update the license, maintain extensions, install Electronic Interfaces, etc. All these endpoints should do the regular manual checks (any programs running? unposted groups? logged in users?..) and even add approval gates for SOX compliance.
Frankly, this administrative API should be available to on-prem users too. The more the two products are alike, the more companies would feel comfortable moving to the cloud if/when appropriate. Also, as an API, one would have far more security capabilities than having people log into the server.
Epicor does not create pets, they buy them. Guess we should make one and get bought.