What drives you to do version upgrades?

Off Topic
1

I see a lot of “We’re on version 10.p.q.r and moving to 10.x.y.z” …

What are the driving factors you use for minor upgrades (like 10.1.400.19 -> 10.1.400.23)?
Do you only do them if the update resolves an issue you have, or know you’re likely to run into?

Medium upgrades (10.1.400.23 -> 10.2.100)?
Do them when ever they come out? Wait for the first minor rev? Like waiting for 10.2.200, instead of jumping right to 10.2.100?

Major upgrades (9.x -> 10.x) are big undertakings, and not t be done without major planning and testing, so I’m not as much interested in those.

Do you do ever minor update, just to make sure you always have the latest?

Personally, I prefer the devil I know to the one I don’t.

2

Being Dedicated Tenant SaaS users, we patch once a month (on Epicor’s schedule).

I found that I didn’t always know the Devil very well. Often when I called about something, I would hear, “That’s a known issue and it’s fixed in 10.x.y.z”

Of course, changes are also unknowns but over time we hope to have enough testing around our processes to reduce those risks. But make no mistake, there are risks staying put, especially with changes in our environment (OS changes, integrated system changes, security patches, compliance, etc.) which can break things too.

Mark W.

1 Like
3

What are the driving factors you use for minor upgrades (like 10.1.400.19 -> 10.1.400.23)?
Only if there’s a fix that I really need, otherwise I don’t bother.

Medium upgrades (10.1.400.23 -> 10.2.100)?
I like to try and stay current with medium/major upgrades as it makes life easier down the road. It really comes down to the availability of my team to perform testing. If we don’t have time to dedicate and there’s not enough justification to jump to it right away, then it will get pushed off. We tend to wait until the general consensus is that the release is fairly stable by way of this forum or local user groups.

Major upgrades (9.x -> 10.x)
Big undertaking, indeed. Again, we like to try and stay current, but this one takes many months to do and we have to have the people willing to do it. As always, significant bug fixes or shiny new toys always help to motivate.

This, however, is likely to change as we bring our Mexico facility on to our version and server. It becomes more of a task to upgrade two facilities at once.

1 Like
4

@hmwillett, said precisely what I was going to say. I’ll add that if the testing process wasn’t such a pain and resource hog, we’d probably do it more often.

We are testing and hoping to move from 10.1.400.23 to 10.2.200.x this summer for a few reasons;

  • I like to stay current, and this is too far behind to me.
  • It fixes a few some issues we are currently experiencing.
  • We currently have some problems with a configurator, and I know part of the conversation with support will mention upgrading, so I’m upgrading before I open the call.
  • The REST services and EDD look like they will add enormous benefits for us.

If 10.2.300 includes the kinetic MES menu, as we heard at Insights, we’ll be doing that upgrade reasonably quickly, this fall.

5

The Minor upgrades aren’t a big deal. The Major ones, it depends on the benefit, unfortunately I am not at all impressed with Epicor’s QA department. Some of the bugs that come out are like woah a basic Unit Test oughta catch that.

Examples (fictional, but those who read the release notes know what I am refering to):

  • “Calculated Grand Total wrong.”
  • “MRP suggested to order more than you should oh and it ignored Purchased Material”.

I want to trust the computer and question my sanity not the other way around. We have come to a point where we question the logic before anything. The business users end up blaming Epicor first, process second - in several cases they were right, I can’t win. An incorrect BOM could cause a product recall (yes it could also be fat fingered, but lets assume it wasnt).

Bugs will exist I agree, but some modules like finance, payroll, ordering, shipments should be QA tested very well. I have seen trucks being searched because the BOL showed it being 120lbs lighter than it was due to some software miscalculating weight, who pays for those fees and inconveniences? How do you explain to your customer - yeah our XYZ Shipping Software had a bug, so the truck driver was accused of smuggling drugs, but on our entry screen it showed the correct weight =)

You have seen those bugs being fixed and wondered how was this even acceptable. For that reason I wait usually before upgrading to a Major upgrade, it hasn’t been stable. Here is a simple one on 10.1.500.x go to a Part and under MRP set your min and max to 1 and then create a SO with a Release of 100 - you should get 100 jobs, but instead >50 will crash your MRP, Epicor was able to recreate it - yet it took no effort to recreate, just a simple setting.

If you download MICR IEx and you deploy the .zip to the client it will not work… why? Because the .zip has sub-folder it will go to SubFolder* instead of the root of your Client, the fix is to unzip it and re-zip it right… Didn’t take much effort, deploy it and try it. How are they missed, I don’t know.

Overall, the decision is usually “It Depends”. We review the Release Notes as a Team for 15 minutes every 2 weeks.

If you have a developer sandbox, its good to keep up to date and play around.