We are using Kinetic 2022 and wanting to upgrade to 2023 in the next week or two. We have 3 VM’s (appserver, Docstar, sqlserver) running on our server and have been using Kinetic for about a year. We have done one in-place upgrade and because of all the bugs we wanted to take a new approach. We think creating a new VM would be the best option, but are looking for someone with your experience to help guide us through the process. Would either of you be willing to assist us for a few hours and we would pay you for your time? Please reach out to jasonr@qual-fab.net. Thank you!!!
I unfortunately don’t have the bandwidth to take something like that on in a short timeline. There is a fair amount of discovery that would need to take place before coming into it. My 2 cents Best Practice For Major Release Upgrade? - #8 by jgiese.wci
If you’re a small shop, if you’ve already done your testing in a pilot system and found the bugs, and produced solution packages to fix them post upgrade, just do an in place upgrade. The same as you have been. 2022 to 2023 is not that stark of a difference if you are using classic. If you are using the Kinetic UI then you might have a fair amount of FAFO to perform.
I can see and relate to all sides of the discussion. Years ago, I would agree with the new VM side, hands down - but since Epicor got into the business of hosting clients, they have cleaned up their upgrade routine substantially; and there are far fewer problems encountered than in the Vantage and E-9 days.
Now I’m more of the mindset that unless Epicor requires a new SQL or OS version, then there’s no reason to setup a completely new environment. We spun up a new VM this past December, mostly due to the OS reaching end of life with Microsoft, and migrated our current version to it at that time. Due to priority projects, upgrading Epicor got put on the backburner until now. So last month, we spun up a new development VM environment to match our new production environment, and I installed our current version on there, and ran through the upgrade process twice. After encountering no major issues, I’ll be upgrading our production environment this weekend.
We’re going from 2023.1 to 2024.2 (And I can’t wait to be rid of all the bugs in our current version!). It’s far fewer moving pieces in an in-place upgrade than it is with migrating to a different server altogether. Having done both, spinning up a new VM is something I personally recommend only when necessary. Not every single year or upgrade.
And personally, I’d rather do the migration and then the upgrade, so it’s easier to pinpoint what’s at issue should a problem arise. Is it something with the migration, or something with the upgrade. Doing both simultaneously is just adding to the complexity.
It’s interesting that Epicor is moving to Linux containers, which by their nature, are always a new environment. We don’t upgrade containers. We make a new image and spin it up. It’s always the same no matter who the customer is. This makes support far easier than the unique snowflakes out there in the on-prem world. At least to me, in place upgrades hide little logic bombs until we get to the day where we have to upgrade to a new environment. If I leave my company and kept everything standard, a consultant can work on my system without surprises, support will be working with the same version, and the next person should be able to take it over with few issues.
