Difficulty to upgrade from 10.2.400 to 10.2.700 - can I do it myself?

ERP 10
#1

We made a big jump from E9 to E10 last year, and it was a pretty big project as we had a ton of reports, customizations, and bpms… Anyway our plan now is to stay current and I think we are ready to make our first “minor” upgrade from 10.2.400 to 10.2.700. I’d really like to learn how to do this myself. Please note I’m pretty technical, but have no experience with MS SQL(consultant set this up for us). I was responsible for most of the E9 server side Epicor but haven’t done anything with server side E10(a consultant set this all up for us).

We are considering hiring a consultant to help us get through this first upgrade and then ideally learning how to do it ourselves for future upgrades. But in thinking more about this I’m wondering if I can’t take this project on, on my own following documentation and then reaching out for help to this forum and / or consultants as I get stuck.

Any advice for someone who hasn’t been down this path before?

Upgrade from 10.2.200 to 10.2.600
#2

I did an upgrade from 10.1.400 to 10.2.300 myself, and there were some pain points.

First thing you need to answer is if you’re staying on the same hardware (the 10.2.700 Apps will be on the server currently hosting 10.2.400). Or if 10.2.700 will be on a new box. Ditto for the SQL server (assuming its on a different box than the App server).

Going to new “boxes” (or even VM instances) gives you the advantage of upgrading the OS and SQL versions too. It’s common to keep upgrading the E10 version, while leaving the O/S and SQL untouched. But you’ll eventually get to a point where E10.x.yyy isn’t supported on Windows Server 2016.

The new boxes also allow a completely isolated system from your current production. The down side to this is you’ll be doing a hybrid of new-install and upgrade. And the Epicor documentation really focuses on one or the other.

Doing it yourself mostly comes down to how much extra time you have for the learning curve. If you have it, then do it yourself and you’ll learn quite a bit. If you don’t, get a consultant and let them know you want to be involved in the install.

2 Likes
#3

We are going to go from 10.2.400 to 10.2.600 in a couple weeks on our own. I’ve done all of our upgrades except our first upgrade. We did a guided update the first time around with Epicor. I will say that was some of the best money we have spent with Epicor for consulting. They assisted with the upgrade and I could ask as many questions as I wanted. Going through it with Epicor the first time gave me a deep understanding of how Epicor is deployed and runs. Invaluable in my opinion.

@ckrusen made a lot of the points I would about about the hardware. So I’d second what he said. Personally, I’m going to new boxes for 10.2.600. I’ve had them up and running for a while now for testing. We are completely virtual so it’s easy to spin up new boxes.

3 Likes
#4

If you do it by yourself and are not an expert, I might suggest going to [vNext - 100], i.e. 10.2.600.

I personally am not brave enough to jump to a version that is still on 10.x.xxx.1 or 10.x.xxx.2. I am really thankful for all of you that do and work out the bugs, but if something crazy happens, all I know to do is jump on this site and search frantically for a solution.

Case in point, in January we were on 10.2.500.7 and went to multi-site, and on go-live for the new site on Feb 1, I go to import the on-hand quantity and DMT broke. Oh, I panicked. Turns out they fixed it in 10.2.500.8, and so I had do update to 10.2.500.9 during the cutover for the other site.

But if it hadn’t been for users working out the issue probably a month beforehand, we would have had to postpone the go-live for the other site!

Also, as many have said here, just assume you will be deleting the app server and creating a new one (in the EAC; I don’t mean an actual server). It’s not nearly as scary as it sounds.

2 Likes
#5

I would agree. I would go to 10.2.600 not 10.2.700 if you are going to upgrade soon. 10.2.700 hasn’t been out long enough for me to make that jump.

#6

Pioneers lead the way down the path, and end up with arrows in their backs when the next group comes along, drawing from pioneers’ experience and using the path already laid, to leave the poor pioneers dead in the dirt…

#7

If you have your test environment on a VM make a snapshot of you VM and give it a try. The instructions are normally pretty good. Doing an upgrade or a new install is a great way to get more comfortable with the admin console and can be helpful for other oddities that happen.
Testing, user acceptance and client deployments are all more challenging than the server upgrade.

2 Likes
#8

Any recommendations of which version of 10.2.600, I assume the most recent subversion - 10.2.600.15?

We are using VMWare VMs which sounds like what most people are recommending as we can easily copy/clone and sandbox things… Excited to dig in and learn more about Epicor :slight_smile:

#9

The latest, 10.2.600.15. It will have all the bug fixes to-date for 600. You will have to install the base 600 then do the update to the latest patch.

#10

I do our upgrades. First one I was nervous but after doing a few and gaining some experience** I have gained some confidence. One thing I have found very valuable is to clone the Live environment on a test server and upgrade that - if it fails completely it doesn’t matter and you just gained some experience. This will give you a feel for how hard the upgrade is. This also gives you a system you can test everything in - do all your reports still work, any issues with screen customisations, etc. Take notes on any fixes you have to apply to the test system as you will need to do that to the Live system as well when you upgrade that.

** experience is just a list of problems you have solved.

5 Likes
#11

Brett’s method is how SaaS users do upgrades.

Although, I’m not certain that they upgrade or build new, restore the database, then run conversions. :man_shrugging:

1 Like
#12

400 to 700 - the upgrade is easy. Felt more like a Service Pack. The hard part is reviewing all your Enhancements, UIs for overlap… Some RDDs for New Joins, Columns, Sometimes the Calculated Field changed… For example (dummy example) Epicor might have used Calc_TotalQty * Calc_TotalPrice and now they are using Calc_TotalQuantity where the math is done in the .dll so your RDL will break or in some instances double-dip.

Epicor injects also their new joins into your RDDs that are a copy of a Base, sometimes injecting extra joins / relationships that double your row-counts… I think we spent more time on RDLs than anything else.

1 Like
#13

So far, knock on wood, our 600 upgrade hasn’t been that challenging. We really only have run into a couple issues in our testing. I don’t expect any major issues when we go-live on 10.2.600 on the 23rd.

This has proven to be more work than we thought…

#14

Yep sometimes they don’t do much, sometimes they add bunch of stuff and move stuff… For us the RDLs are usually the toughest… That may be because we try to uplift them to current… so if Epicor added let’s say the Company EORI number, we go and add it as well, even tho we are not using it now.

Some reports we throw away and re-customize from scratch - easier to bring Epicor uplifts over.

Dashboards and BAQs usually are the simplest.

#15

We found some small stuff with some 3rd party integrations and customs. Epicor at some point between 400 and 600 changed a function to require 2 parameters instead of just one for example. Just little things to track down and fix. Was a single code line change but was broke till we did that.

1 Like
#16

We’re at 10.2.400, and I have been reviewing change lists for compelling reasons to update. We’re pretty stock, with only a few BPMs - but a large number of dashboards. I find the new Kinetic interface and tools interesting, but not fully baked - I originally tested at 10.2.600, and was disappointed at the missing Kinetic grid functions (group by, summaries, filters); however, all those are now incorporated in the 700 release. Added features in Advanced UOM and Collaborate will be introduced to the team in a 700 test environment. The tough part is walking the line between updating for bug fixes, and introducing partially-baked functionality that disappoints the team.

#17

You can turn off the Kinetic in 600 and 700 until it’s fully ready. That’s what we are going to do.

#18

How are you going about turning Kinetic off @chaddb?

Seems when I try to do this in the Kinetic Application Maint form when I turn off everything for All Companies my changes are reverted back

#19

Turn them off 1 by 1. Its a bug.

3 Likes
#20

Thank you @hasokeric, what I figured