Patch level updates

Curious what on-premise companies are doing for the patch level updates Epicor is releasing.

We are trying to establish a best practice plan internally going forward, we are upgrading to 10.2.200 this weekend and already see minor patches have come out.

What time frame do you have for these incorporating these patch updates? Monthly or Quarterly?

What level of testing do you give them compared to the larger release upgrades?

Thanks.

Brad

I’m curious what others do also. We have been live for 1 year now on Epicor and have not moved even 1 patch… I feel like this is not the norm but I have trouble justifying the effort and risk of moving frequently if there isn’t a specific issue or feature I am trying to get to.

1 Like

We are currently in the middle of this planning as well. We are about to go live with 10.2.300.7 as an upgrade at one of our sites. I just brought 10.2.300.7 online at a new site on 1/1/19. I am looking to put together a plan which will push a patch once a quarter or once every other month. I have not officially decided yet. We are still documenting what some of our external programs that use web services need with the upgrade. The plan though is push the patch out to the development/test environment. Test it in a virtual machine workstation. Verify the internal apps. If all is well then roll the update on a Friday evening. I definitely see it as beneficial to roll the updates. Epicor is working hard to make sure the last version number does not affect functionality. It only fixes bugs and minor issues. As a result applying the fixes to the application server are getting easier and easier. While testing for the 10.2.300 go live I updated from .1 to .4 to .7 all very easily. The redeploy of help, education, and other extensions is also getting easier. I hope this helps a little! Once this plan is formalized further, and I can remember, I will try to update this entry.

I can’t find the post but I thought I read that the most current build (.300) gets a sprint every couple of weeks. The next previous build (.200) every month, and so on. So the older the code, the less frequency the updates.

FWIW, we on the public cloud are getting the patch that’s available in the middle of the month so it doesn’t interfere with end of month shipping or month-end close activities.

Mark W.

How much testing is everyone doing for the patch releases? Is there any point to doing a quote to cash test when cloud customers are live on it already? A full CRP seems overkill, and would be impossible to get resources to do that every time.

Epicor says that they are minor bug fixes, so nothing should be affected. In the past when applying SCR’s, we’d test that specific functionality in Pilot and cross our fingers, but it was easier to see what was affected by the dll’s being changed…

We’re in the middle of the 10.2.300.12 update right now. On Wednesday, our Pilot got the patch. We download the release notes and filter for the items that may affect us. We pass that around to the core team (who is our implementation users and know the full test process) and they look for affected areas. On Wednesday/Thursday everybody should update the Pilot client and smoke test their most used items. About 15 minutes or so for most users. The core team will give more attention to areas that were touched. If there are issues (which we haven’t had in ten patches so far) we would fill out an EpicCare Ticket. On Saturday the patch goes in, a few users might test it out on Sunday.

So we treat patches/updates like the monthly Patch Tuesday. Releases (.300 -> .400) and version (.2 -> .3) get the full CRP treatment.

Mark W.