How often do you update?

Epicor ERP 10
1

This can be more of a general discussion to help Admins plan their Epicor upgrades out for the year, but what does everyone do here? I know it can vary wildly based on business process, organization size, number of customizations and integrations etc.

I’ll start. Being new in my role at my company, I walked into a release of Epicor 10.1.400 that was 2 years old. Part of what you pay for with the software is continuous upgrades which is awesome, and many many bugs are fixed every 2-3 weeks. I’m starting to get us on track to stay current. Every 2 months we will apply the latest update for our release. And the moment a new release/version comes out we will immediately begin regression testing the software, but may wait for a few updates before fully going live with the upgrade.

image

We are starting to implement test scripts with the ATE tool for regression testing, and thoughtfully documenting every customization/bpm etc. My hope is that we can move quickly and keep pace with Epicor, that’s the goal for me anyway.

So, what does everyone else do? Any helpful tips to share with the community on how you stay current? :slight_smile:

2

We try to stay as current as we can but testing every release is not always easy, especially every few weeks.

Right now I think we are going to UPDATE quarterly. I review the update notes to make sure it isn’t something that will affect us. If it is we adjust accordingly.

We will do Version/Release as it comes out. We will do testing for a couple days then roll it out.

I hope it helps.

3

So far, our cadence is one major release or version per year (that’s about all the time our core team can commit to regression testing).
Updates will be upgraded to if there’s a specific fix we need, otherwise we don’t bother.

1 Like
4

I have a strong bias obviously, but, I can reduce all of the ifs / thens / elses down to the following quote that I literally just made up right now regarding changes to the update level (10.2.300.x) at least regarding when one should apply updates:

“One should apply the latest update to the release they are on in their testing environment every time a user reports an issue in your production environment to you BEFORE calling support to determine if the issue still presents or not.”

– Nathan Anderson, Sr Engineer, Epicor Support

If an issue doesn’t present in the latest update, then, there is the solution to the issue.

I defer to others regarding how they handle version or release changes :slight_smile:

3 Likes
5

We are Public Cloud with the deferred option. There are several dates offered to upgrade releases (.200, .300, etc). We just launched with .300 this weekend. The updates happen in the middle of the month so we usually hitting every other one. With the releases, we don’t do the full regression testing. We download the release document, filter for our products, and look at the areas changed and focus on testing that. Our Pilot is upgraded on Tuesday/Wednesday and we do target testing through Friday. On the weekend, Epicor applies the patch and we’re off and running on Monday.

When I think about the most important financial software package most companies use (Excel), it gets updated about a dozen times a month if you’re using O365.

With releases, when you do them as they come, they are smaller than jumping several. We don’t start using new functionality right away. We get to the next level and then play in the Pilot. We are also telling users that customization comes with responsibility. Users should test their own customizations. This could cut down on some requests. Also, the type of customizations can increase your testing cycle: compiled programs that link to the client DLLs are more brittle than a REST call or even less when BAQ and REST are used together. I mean, would you make Excel Addons that require you to distribute DLLs to each MS Office user? Reducing high-risk customizations will cut your time down too.

And you hit the nail on the last one. Automate as much as you can. You might find some of those tools useful in other ways between updates.

Mark W.

3 Likes
6

Having implemented and maintained lots of different ERP systems for more than 25 years, Jeffs comment

I know it can vary wildly based on business process, organization size, number of customizations and integrations etc.

is really significant. I am going to park the cloud offering because as Mark says, you are making a commitment, whether the organization fully understands it or not, to an ongoing regular update cycle when signing up.

I’ve worked on a big multi-site/multi-country/multi-year roll in a large corporate - the reality is that fitting regular upgrades that into what is already a complex cycle is really hard - you need multiple different businesses, of vastly varying sizes and resource to test and sign off.

I’ve worked in environments where being current on all software was mandated, and was properly considered and resourced. In others where the same mandated requirement existed but without the same capability, resources or understanding that this was not just an IT activity.

But frequently, and even taking into account the continuing shift to point release/agile upgrade models, it will get to the stage where the organizations will question whether the regular upgrade cycle is just creating busy work with minimal tangible benefit and that the resources needed to test could be better used on other activities to help the org meet it’s goals, or that despite having followed a regular update cycle for some time, some key functionality/process still isn’t in the system and that they are going to focus on customizing the system to incorporate that missing functionality recognizing that it will have major impact on ability to maintain a regular upgrade cycle.

What seems totally wrong headed to some may just be brutal pragmatism reflective of the organization for others. I’ve worked in orgs where when the ERP guy leaves, he is not replaced and the role is considered redundant and the ERP system becomes frozen in time. But also environments where implementing the ERP system created a whole new, non-IT business function to support and maintain it, often unintentionally.

We are on premise E10, off maintenance and several releases behind - personally I wish we were on a cloud based release as it would make my job a hell of a lot easier but I totally understand why the business made the decisions it did.

2 Likes
7

In our use of Epicor, it is a huge effort to apply an update. With the customizations (over 130 !) especially is time consuming to make sure no new field affects our added fields on forms, etc…
We started to go to the upgrade route as a lot of issues we had are resolved in a future version. (it was 10.1 at that time… ) That is the pitfall of staying at original level too long. Epicor won’t correct an issue for all previous versions when it is already corrected in a current one. And it is OK to do so. It is up to the customers to keep up…

So here we are…going from version 10.0.700 in 2015, to 10.2.300 in mid april … and the main reason I cannot attend Insights this year… (I guess management did not think of that when assigning that upgrade date… :thinking::tired_face: ) arrhghghghg…

Moreover, all departments need to get involved in the testing as new features may have been added but also to make sure, in their use, the upgrade version does their daily tasks without problems…

So for us, it is not an effortless task, but I forsee a future upgrade hopefully before a 4 years span… !!!

Pierre

2 Likes
8

Based on feedback from Epicor, we were led to believe that the ‘dot updates’ only needed a quick Quote to Cash validation, and did not require the full 200 hours of CRP testing we’d do for the .X00 level releases.

Following this advice, we updated from 10.2.300.7 to .12 two week ago to fix several bugs, and got burned.

It seems Epicor made an undocumented change between 10.2.300.7 and .12. It’s not mentioned in the release notes, and Field Help and Data Dictionary were also not updated. The upgrade process did not flag it either.

Epicor’s lack of testing and documentation on this .update change cost our company 48 man-hours in testing, meetings, and work-arounds. This also impacted 150 customers that needed to be contacted again by A/R for credit card information.

I can say for sure that we’re not going to treat upgrading dot releases without doing much more thorough testing… This will definitely slow down the cadence of updating versions for us, since it’s hard to justify all that testing to management multiple times a year, and goes against Epicor’s recent push for more updates, often.

*Devils Advocate - 2 weeks worth of broken counter sales, 48 man-hours company cost, $$$/hr external developer consulting, and 150 customers impacted is still less than the company’s cost to do 200 hours of CRP testing. I still don’t think it was worth the hit to our IT department’s (and Epicor’s) reputation to trust the .updates without thorough testing.

This was a lesson learned for me, and hopefully this prevents others from the same fate.

2 Likes