Upgrade to 2022.1.x on prem taking excessive time

We have just completed our UAT/CRP for the upgrade from 10.2.500.x to 2022.1.x and will be upgrading this weekend. My team member who is responsible for doing the actual upgrade has noticed that it is taking excessive time for this upgrade (more than normal). Epicor says it should take approximately an hour but in our case, it’s taking about 10 (10 times longer!). We are on-prem. Has anyone else noticed this? Anything we should take a look at that might help to speed things up?

Any ideas would be appreciated!

2 Likes

10.2.600 to 2022.1 yesterday took around that 1 hour time. What step is taking the longest that might provide some insight.

1 Like

Upgrading to each version is taking about an hour. When we restore the DB, Epicor runs a bunch of SQL scripts and that is what is taking so long.

What do server resources look like during that time? Disk I/O, SQL Memory consumption, etc etc the usual stuff?

1 Like

We are working with our Core Services team members to take a look again at optimization of the server. We are not seeing anything out of the norm at the moment.

1 Like

@Beth if you upload your database to upgrade services and run the analysis, they do a top 25 table row count. you may have a table with too many rows that you can do some cleanup on.

1 Like

Thanks, Greg. I’m running this by the team to see what their thoughts are on this.

1 Like

If you do some index maintenance beforehand and also temporarily change the db recovery model to Simple it may speed things up for you quite a bit.

2 Likes

And I’ve noticed that if you have a complicated GL Chart (and thereby a LOT of GL transactions) the GL conversion process during the DB upgrade just takes forever. Our GL conversion takes longer than all the other scripts combined.

But I agree with the others also - indexes, turn off replication (for AFR or anything else), set to Simple backup instead of Full - all of these things will help.

And best of luck with the whole thing this weekend!!!

4 Likes

Thanks Tom and Mike! We didn’t think of the indexing. We’re taking a look at that now.