I’ve seen a few posts from the Yahoo archive but was wondering, If you’re on premise how often do you update/upgrade your Epicor? We upgraded from E9.04 to 2022.2 in 2023. There has been talk of upgrading to keep relatively current, just a version or 2 behind, we don’t want to be beta testers.
If we do an upgrade I’d have to do it all myself and while I’m not bad at what I’m doing I’ve never set up a server for Epicor.
Does anyone worry about being on sustaining support as we now are with 2022?
Another discussion was what version to move to. We all still use the classic (modern) UI so we want to stay in a version that still supports them. We also want to stay with a client and not be browser based yet.
Based on those criteria, is there anything in 2023, 2024 or 2025 (upcoming) that would benefit us?
This is one of the more common questions I get asked as a consultant.
My background is IT, so I’ve been updating and upgrading software since forever. Generally speaking, I would never want to get more than a year (2 at the MOST) behind current. I don’t need to be the bleeding edge, but I really do want current functionality and patches.
For a complex integrated system (like Epicor or any other ERP), this has a cost in testing time, but there is also cost the other way in missed opportunities, and eventually in the end of even security patches.
Classic UI is still available in the current 2024.1 version, and will be for at least another 2 years. That said, any NEW functionality is NOT being added to the Classic interface… so although the underlying plumbing is there, the fields/programs/processes to utilize them (such as Track Inventory by Revision) are NOT default in Classic. Theoretically you could add them. Theoretically.
Thanks. One of the things I’m doing now is going through all the release notes for 2023 and 2024. I’m looking for things that will benefit us directly and other items we could leverage that we’re not doing now. Trying to build a Pro/Con list to help with the decision making.
I agree this is a much more complex system. I get reminded of how “I can upgrade my quick books with just a button click.” And I try to explain how Epicor is so much more complex that that.
I do want to move everyone into Kinetic UI eventually but I still have users working in the old classic UI like from E9. There will be not just upgrading but training as well.
I’m trying to put this together as a plan by 10/1 for the owner.
We went live on 2022, had a lot of stability issues, fast-tracked to 2023.2. I think we’ll stay there for a little while…but I don’t see us staying there permanently for all the reasons @Ernie listed. Upgrades can be a double-edged sword…improvements, patches, fixes are the pro’s…but the time investment can be difficult when you’ve still got a business to operate.
All those who had a completely bug-free and trouble-free upgrade raise your hands… thought so.
We have a history of upgrading to whatever is current every 5 years or so, with occasional patch updates in-between.
We have too many customizations we’ve been dragging around and waiting on CSG to validate/re-create with every upgrade…
This time, expecting to go live with Kinetic middle of next year, but we’re cutting out customizations and building more in-house this time … we’ll see if we can get onto a more-reasonable upgrade cadence from here.
We’re on prem, use classic pages, current version is 2021.1.13 and upgrading to 2023.2.19.
My plan is to upgrade a major release every other year or to be 1 major upgrade behind. That way we are more current but are letting someone else find the bugs in the current release. I’m the only Epicor resource here (I feel your pain), so I’m doing everything myself expect for the database snapshots and cloning of servers. But if you have VM’s setting up the servers aren’t a big deal.
For the classic screens I’ve started rewriting those into Kinetic to take advantage of functionality that’s only available in the kinetic version. You can only do CPQ integration in Kinetic Quote Entry screens, kinetic part entry has built in incoming inspection, etc…
General rule for software versioning. If you’re on the cutting edge of releases, you’ll end up on the bleeding edge at the same time.
Yes, QB is much simpler than Kinetic. There are only a few sizes, and you have little customization ability. The only guardrails in Kinetic are self-applied…although that is changing. Epicor will sell you enough rope to hang yourself, and many of us have. I’ve worked at companies that are heavily customized and are having a terrible time staying current. I have also worked at a company that launched in Single Tenant, which is like hosting in Azure, and never upgraded. We moved to Dedicated Tenant (which became Public Cloud) and have upgraded twice a year starting from 10.2.100 to 2024.1. After the first two, they stopped complaining because they got good at it. They built a system. They had to, because there was a business to run.
Here we made the commitment to upgrade once a year to one release behind. We’re still on 2021.2. It’s easy to put off. The longer one waits, the easier it is to fall into sustaining support.
Anyway, the trick is to build an upgrade process that makes upgrades go quicker. This includes many of the DevOps ideas like having source control, good debugging/testing tools, and useful telemetry. It’s the main reason I keep pushing for this. I want to make managing the system easier and not let customizations hold us back.
Frankly, I don’t upgrade for new features. I worry more about the underlying infrastructure. If the ERP system is stuck on an older OS, database, identity provider, or application stack, my system can stop working too. It’s not risk free.
Now go have a nice weekend everyone!
If you upgrade more often then the pain will be less. I’ve found that big jumps are harder in many ways - the changes are bigger so there are more things to review and fix, and as the admin simply being out of practice makes it harder. We are still classic as well, and in the process of rolling out the Kinetic home prior to our next big update in January.
My ideal goal is to upgrade 2x year and hit every version, but with my time and other business requirements, upgrading every year is more reasonable. As others have mentioned, it gets easier and you will get faster. You will build documentation and tools for this upgrade to make the next one easier. Definitely set up a test server with the same OS/SQL stack so you can run through and work out some of the kinks.
I try to upgrade the minor fixes 2023.2.xx every couple of months in between, and while nowhere near as complex, it is still good practice and really lessens the user perception that the big upgrade will be scary and different. “Oh, just another update”
We don’t have a choice, but the 2x a year works well enough for us. I wouldn’t mind 4x a year actually, fewer things each update has, the fewer things can be broken at the same time.
If you’re upgrading 2x a year, how long is your process from create server to test to go live? I was guessing it would take me 2-3 months just to set up and test everything. I am doing this myself though.
I am expecting to have to test not only the data but the screens, dashboards, reports and MES system. I also need to make sure all our customizations and BPMs are working. We have some customizations but I’m starting to think there’s different definitions of customizations.
You do get the patches once a month… 
^^ This is so true!!! We upgrade ever 12 - 18 months, so only 2 or 3 releases behind. Every time we do an upgrade it gets easier. The core testers know their job, end users know their role, and IS/IT ensure its all looking good.
Ditto. It was weird to be on the current version!
We want to go to 2024.1 next (after 2024.2 comes out), but I am getting scared from what I hear.
I’ve normally been of the 2-releases-behind mentality, but our commitment to the browser has forced us to upgrade more often (that’s not a compliment). The bug fixes have been outweighing the bleeding edge issues. So far.
I’m apprehensive about the next jump. It’s one of those things where you really aren’t sure if the grass will be greener on the other side of the fence…and you can’t afford to lose the functionality (and/or workarounds) that you have now.
I just got a budget quote from Epicor. They want $6,000 to do a full Cirrus conversion from any major release to any major release. So going from 2022 to 2023 or 2024 would be $6k. I politely declined at this time.
We’ll keep working on a plan and figuring out all thats involved.
We upgrade without consulting or support. The only time I needed to engage support for installation was to activate our ECM instance once it moved to Azure. Our current cycle has been 1 major update every 1-2 years since I joined the company. Prior, we had been on Vantage until 10.1 was released.
Side note: $6k sounds on the low end, given hourly rates. That either will grow, or your upgrade is simple. As a consultant, I’ve seen significantly larger expenses regarding upgrade. Also, the longer you wait, the potential cost grows, depending on the complexity of the change (Like Vantage to 10. 
) Upgrade costs are why cloud gets its due consideration.
Epicor has documentation on all the steps to perform an upgrade, what specific changes are needed for the release, and a full install guide if starting new. If you understand your data and customizations, you should have everything needed to perform upgrade yourself.
2022 is incredibly unstable. Looking forward to our 2023 upgrade here shortly.
Once a year and it takes us about 3 months to do it between end to end testing and all that. We can’t do it any more often than that our system is too complex.
I would agree that staying current is paramount and going on sustaining support (for us) is not an option. There is new functionality in 2024.1 and 2024.2 that is super exciting to us.
We are in the midst of an upgrade now hoping for a go live at the end of the month. We’ve been testing since July.