Other than it was time for a new server (Windows Upgrade) even going from 10.2.600 I to 2022.2 I wouldn’t have setup a new server. For upgrade testing a different server is great to just have standard but beyond that meh. Our upgrade from 2022.2 to 2023.1 we will for sure be doing an inplace. I’m not setting up new servers every year, way too much work and dependencies.
2 Likes
We also run 2022 and 2023 on the same server, as we are testing 2023, no issues there. Remember Epicor just changed their Naming Convention 2021 - 2023 you are technically on Epicor 11… Once they hit that big milestone of Epicor 12, thats when you rebuild because chances are you want to get SQL Server 2024 then and SSRS 2024, Windows 2024 anyways… (assuming thats a thing by then). But the ultimate answer is “it depends”. Some folks stay until EOL, just fine.
In the past we did use new VMs because we could configure Production ahead of time and then 2hrs before, just swap VM Images and just restore PRD Database. It was simpler for a 24h shop to have minimum downtime.
4 Likes
having separate VMs is definitely so much smoother for 24hr shops and in general
1 Like
Personally, I like a new VM each time for any update - but not patches. There’s less cruft to build up and possibly interfere. It lets us do trial runs and testing without messing with production. Like Haso says, it allows for a restore, run upgrades, and go in a shorter period of time. Finally, rollback is easier (if necessary) since there are fewer moving pieces to worry about.
I’m not as brave as @jgiese.wci
**EDIT: Also, feels more like cattle than maintaining pets…
3 Likes
Really comes down to complexity of the setup. Like for us we end up piloting the upgrade 3-4 times just because of general testing. During that time we have a checklist developed of the go live tasks.
For go live we take a full DB backup, you’re setting up a new appserver anyways so you keep the old one. Worst case if it goes sideways, restore the DB and turn on the old appserver and you’re right back to where you started. Epicor has done a good job isolating versions these days.
Doesn’t take that much bravery LOL! I’m not so brazen as to even attempt in place Windows upgrades 
I would tend to disagree with this. It takes less time to upgrade your production app server than to do a DB restore and then Upgrade. We have our upgrade process down to a point I would even be willing to do it during production hours with a 1 hour window. We get all day Sunday, we’re 24/6, so it would be silly to do that, but if I had to I would do mid day.
There are a lot of variables that play into this including level of familiarity with the Epicor framework, size of your database, complexity of your customizations and integrations, IT support staff skill level, etc.
For a same major to same major I wouldn’t let them spend the $s on a new VM (i.e. 2023.1 to 2023.2) but if comfort level is higher then let them do it for 2023.x to 2024.x. Just my 2 cents 
2 Likes
For sure! A new VM does give one the option to update the OS and/or SQL too. 
1 Like
I also do new VMs, but I have seperate live, test and dev servers. That allows us to have the new production client installed and running as a pilot environment and I only have to upgrade the db for go live since I only have from Saturday evening to Sunday evening when production starts again.
1 Like
I can see it both ways yeah
We try not to live bleeding edge with M$ they scary sometimes. We probably get a new live VM every other M$ major release. We skip those “Vista” releases LOL
See that might be where we differ too. At go live I take the old production sysconfig and change the deployment location to my new install. Then when a client opens Epicor it just deletes and re-installs the client from the new deployment location. I never even worry about the client installs, my users see it as any old auto update, just takes longer.
Even when we switched from our old to new VM for production last fall I put a 10.2.600Deployment in my new server but all it was, was the paths to the production.sysconfig pointing to my new 11.2.200Deployment folder. I let DNS handle the rest.
I’m the least qualified to weigh in, but I’ve done 5 upgrades, (1 in place and 4 new VM) and I prefer the new VM like @Mark_Wonsil.
There is no dedicated Epicor manual for this style of upgrade (you you have to piece together parts of the in-place and the “I’m new to Epicor” guides). But once you get the hang of it, it’s great.
The new production VM we use is just the dev VM. After I have tested the dev environment, I just add an app server for Production and upgrade the DB, and then we change some bindings, etc.
However, I actually can’t do that anymore.
For performance, we put the app server on the SQL server last year. So unless I want to set up a new SQL server every time we do an upgrade (no thank you), I’ll be doing in-place upgrades again from here on out.
I like you think we are looking at bleeding edge and not just moving off of 2008 or 2012. 
1 Like
@hkeric.wci, you said something about not needing Windows features and .Net Framework tools on the 2022/2023 servers. Question: What tools/features are you talking about? Is that only in the case the server is only running the Epicor servers?
1 Like
I’m pretty sure he was talking about not needing the features the older versions of Epicor required.
Ie, just having whatever .net tools the current version requires.
Yep I think like 2023 requires half the Features and Roles than what I usually had Configure for 10.2, like I no longer need the IIS 6 stuff. Something along those lines. Windows Features / Roles.
2 Likes
@utaylor Hello. I was wondering if we could have an opportunity to talk more about this question outside of the forum. I am on the same IT team as @matt-s who posted this question. We are looking to upgrade to the most recent release for Kinetic next week. We are on prem and have have similar concepts when performing our upgrades. I was hoping to collaborate on a few questions that have came up recently. Thank you so much! Jason
jasonr@qual-fab.net.
I’m gonna tell you right now there are some HEAVY hitters on this thread who I would trust in a lot more than myself @hkeric.wci @klincecum @Mark_Wonsil @jgiese.wci .
I’ll reach out in any case.
1 Like
@Mark_Wonsil @jgiese.wci @hkeric.wci @klincecum
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!!!
You can leave me out of it, I’m a SaaS guy. I’m just a good sounding board.
1 Like
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.