When arriving at an Epicor version that requires upgrading your server OS/SQL, how is everyone doing this? Are you doing in-place upgrades or setting up a new testing stack of servers with fresh installs and then migrate/upgrade the DB?
Our servers are all virtualized. We have 2 application servers and 1 DB server all on Server 2012 R2 with SQL Server 2014. We’re currently on 10.2.500.8 and wanted to upgrade to 10.2.700 just on our Test stack of servers (to get familiar with App Studio and see how many customizations will need to be redesigned before Kinetic 2021). Since we don’t meet the minimum requirements for 10.2.700, we figured we would upgrade to the latest OS/SQL (2019/2019). In-place upgrades for all of this sounds great, but I’m wondering if this actually works. Has anyone done this yet with any success?
I saw that @MikeGross was planning to do something similar (link below) and would love to hear how it’s going for him too.
One question I had for him was how does he keep the cloned VMs off the network while still being able to fully test the upgrades?
Thanks for any advice/experience anyone has on this!
-Sharla
lol, yeah well, this all got pushed to maybe Memorial Day weekend. All the Work From Home malarkey has really put a damper on my Sunday morning maintenance schedule (plus we cover about 18 time zones normally)
As for your question, the snapshot thing works well enough, but my engineer figures he can also clone them and disable the Network Interface. That way I can go through the VM Console and do things to them if I need to check/change/etc. during the upgrade process. You can’t actually do the Epicor upgrade with these clones, just ‘look’ at stuff if you need to compare config files and things like that…
I forget the order, but I think it’s OS+SQL on the DB server, then OS+ Epicor on the Appserver(s), then reconfig the appservers, then the Client’s DB Update. We’ll do in-place updates on the Appservers using VMWare to do the OS upgrades, but we’re now planning on a whole new SQL server and a massive script to backup everything, then restore to the new server, and some ancillary scripts to adjust users and stuff…
Anyone have a great script/tool/app to ‘migrate’ an entire SQL server like this so I can keep the same name?
So Mike, you’re snapshot or clone of your existing server(s) is just a point of reference… or in case things go wrong with the in-place OS/SQL/Epicor upgrades to your existing servers, correct? I’m still trying to figure out if we want to try the in-place OS/SQL upgrade route or just stand up brand new VMs (already at the right OS/SQL level) and “implement” the new version of Epicor (and then migrate/upgrade the DB). I’m just not finding alot of other posts on here about what others are doing for this jump.
Thanks for your help/advice!
in a nutshell, yes. but you can do it many ways… I like the snapshot for going backwards. If something happens and I’m not happy with the install/upgrade, then back she goes. Then I’ll take a week to figure it all out again and reschedule. I like the offline clone because sometimes the appserver drop/recreate process messes things up and I can go to the clone and see what it should look like… or if something mangles a URL or a web.config - I’ve got a reference point at my fingertips.
We just did an upgrade and built out brand new servers. Windows 2012 + SQL 2014 + Epicor 10.1.400 to Windows 2019 + SQL 2019 + Epicor 10.2.700.
We had so many gremlins on the old servers that in place upgrade never crossed our minds even a little bit. Even if your servers are “clean”, it’s still a good idea to rebuild periodically. Sure, in place can work but most people shy away from them. Just think about what your Go Live weekend will look like… OS upgrade/patching, SQL upgrade, Epicor appserver install, and database upgrade all in 2 days! We had the entire db server prepped the week before so upgrading the database was the only real weekend task and that was hard enough.
