Solved

Limited UAT 10.2.500.19 TO 10.2.700.9

  • 15 February 2021
  • 1 reply
  • 94 views

We have a need to expedite an update of Epicor from 10.2.500.19 to 10.2.700.9.  I reviewed the Release Guides and Feature Highlights for .600 and .700.  Other than some of the financial updates in .600 I didn't see much else that was applicable.  Our Finance group is the one pushing this update  to implement DocStar AP Automation.  Consequently, they are ready, willing & able to test the release.  The other departments however are not as eager or “available”.  So my question is, can we perform this update with little UAT? We are a little heavy on the customizations (Service Connect, C#, Linq, Handhelds, APM etc). I spun up a new app server with 10.2.700.9.  I tested the integrations of service connect and the reports and everything seems to be running as expected.

icon

Best answer by Tim.Berryman 16 February 2021, 16:39

View original

1 reply

Userlevel 3

@mgaritta the million dollar question! Can we upgrade with little/no testing?

My 2 cents worth (I apologise for the waffle):

It depends. There are a number of factors that add significant risk to that question and a couple of these you’ve already mentioned. The key question is can you afford not to test? For some companies the most cost efficient answer is Yes (but this applies in very few cases).

Epicor upgrades are becoming smoother, simpler and less prone to errors. This is primarily down to lessons that are being learnt through the cloud platform where customers have fewer options around deferring or delaying updates, as updates are taken/pushed out on a regular cycle.

For on premise customers this means an improved experience (in most cases) when upgrading. However, this isn’t always the case and the fewer patches/service packs you are away from the prime release the less error prone the process. 

If yours’s was a minimal customisation** instance of Epicor I don’t believe this would pose too much of a problem. 

If you need to prioritise resources to push through the upgrade as quickly as possible, focus in on those business critical elements. These aren’t always the obvious elements or systems, but if a process/element was unavailable could the business continue to trade effectively?

Recommendations:

  1. Test the complete quote to cash process
  2. Check the outlying order/job types/processes that don’t follow the normal process
  3. If you’ve had issues with a process at a previous release make sure this is thoroughly tested
  4. If you’re using Scheduling/MRP/PO Suggestions DO thoroughly test these items
  5. Test anything else the business relies on
    • If a process would cripple the business if it failed, you can’t avoid testing it

Your upgrade experience (and more importantly that of your users) will only be as good as your testing and that of the software (both Epicor’s code and your code). 

P.S. I have done service pack upgrades in the past with minimal testing. However, a recent upgrade from 10.1 to 10.2.700 has failed on a number of elements. Both customisations and BPMs and will require a reasonable effort to correct these failures.

** A customisation for the purposes of this post, is anything that requires custom coding e.g. Screen customisations utilising manually written C#/Linq, BPMs with custom C#/Linq or service connect with custom code/elements. Customisations/BPMs written using the wizards/standard tools “shouldn’t” be too much of a problem when upgrading.

This view is my own personal opinion as a user of Epicor ERP and not that of the Epicor Users Group. Any information included in this post is opinion only and readers own judgement/discretion should be used when reviewing any information provided.

Reply