I’ve done several “upgrades”, but they’ve often been under vastly differing circumstances. Like our upgrade from 10.2.400 to 10.2.300 also included a move of both the App and SQL servers. So those were really like new installs, as the destination servers had neither the App server software installed, nor SQL DB’s configured.
This time we’d like to upgrade and stay on the same servers. So this is a classical Upgrade.
But the upgrade docs tell you how to do the upgrade, and kind of gloss over the fact that you need your current production system to remain up and running while testing the the version. For example, from the Upgrade guide (10.x to 10.2.600):
When you upgrade the Epicor application to a new release, you can reuse the application servers (AppServer) from the previous release. Reusing the application servers allows you to keep the settings from the previous release for use in the new release. Upgrading the application servers is a two step process: first you remove the existing application server from the Epicor Administration Console and register it again. Then you select the deployment folder where all the files for the application server will be deployed for the new release.
Now how do I do that without losing my PROD environment?
I’m guessing the process would be:
Duplicate the PRD_102300 DB to a new one named PRD_102600
Create a new App PRD_102600, identical to our current PROD app (PRD_102300)
Change App PRD_102600 to avoid resources used by PRD_102300, like:
a. The DB used by the App
b. SSRS
c. others ???
Install E10.2.600 on the app server - This won’t interfere with the PROD environment running 10.2.300?
What about default directories like c:\Epicor, c:\EpicorData on the app server? Make copies of them like c:\Epicor_102600, and c:\EpicorData_102600, first. Then direct 10.2.600 to use those?
Do the “upgrades” to App and DB PRD_102600 (which is at rev 10.2.300)
We did this when we went from 10.2.300 to 10.2.400 and for the life of me I can’t remember how I did it… but we did have .300 and .400 running on the same servers. We are right now planning our .600 upgrade and I’m planning new servers for that.
When we went from 10.1.400 to 10.2.300 (which was to new servers too), I did a new install of 10.2.300 on the new server, then replaced the DB the install had created with a copy of the one from 10.2.1.400.
And like you, I don’t recal the exact details. And even trying to document it was hard. If you make a mistake, do you document making the mistake and then how you fixed it? Or just what you should have done right the first time?
Doesn’t Epicor suggest new server for major version changes? I thought I read that somewhere, maybe not. That’s why I’m doing new servers (VMs) for this upgrade.
If I remember what I did I’ll share here but really struggling to remember how I did it. And looking at my notes isn’t much help. They don’t make sense now
I thought the 2 in 10.2.300 was the major revision indicator. So I was only going from .2.300 to .2.600, it wasn’t a “major” change
Plus, the Upgrade guide tells you how to do it on the existing server. My issue is that it kind of leaves out how to install it on an existing server, so it “plays well” with the prior version.
You’re right I should have said doesn’t Epicor suggest new servers for release upgrades. I know you can do them on the same server. I just though best practice was new servers. I could be thinking major releases though.
With that said though, I may need to rethink our 10.2.600 upgrade. If I remember what I did to run .400 on the same server as .300.
I have 10.1.500, 10.2.200, 10.2.300, 10.2.500, 10.2.600 on a single sandbox and when you install Epicor will just update your Admin Console and keep adding Snap-Ins.
One thing I do recommend is that you recreate the IIS Instance (aka AppServer node in Admin Console). Just get rid of it and then when you click Add New the Snap-In selector will show-up.
Example:
The only one that seems to kind of fade away is the Task Agent Settings the 10.1 or 10.2 ones will disappear from the list and sometimes the new one wont work with old one, but you can always offset that to another server or just manage it manually.
On my sandbox I run everything on there… 1 OS with SSRS, SQL, AppServer, Agent, Service Connect, BarTender etc… all smushed together into 1 800$ Lenovo ThinkServer with 64GB RAM and multiple versions too of Epicor.
Personally I would only consider putting patch release on an existing production server. Perhaps I am being too cautious.
10.2.400 to 10.2.600 or perhaps .700 will be new server instrances, but we are a virtual shop and it really takes no time at all to build some new environment. Can do plenty of parallel testing and the practice conversion process. All without risk to the production environment.
And this is the part that concerns me. Besides point to new folders (say adding the suffix _102600 to each), do I need to copy any contents from the “old” folders to the new ones?
Say my current server is \APP001 and 10.2.300 was installed on the C: drive. It created (and uses) folders: C:\Epicor and C:\EpicorData. And echa of those has may sub folders, some containing customizations and what-not.
If I install 10.2.600 to that server with the default install settings, it would write over 10.2.300, no?
If I install it to C:\Epicor_102600, it would create that directory. I guess I’d have to use SQL to update the SysAgent setting in the DB for 102600 to change C:\EpicorData\ to C:\EpicorData_102600\. Or is it safe to launch 10.2.600 just to change the SysAgent settings?
Either way, after I’ve got 10.2.600 installed to use those two new directories, is there anything in the original dirs (c:Epicor and C:\EpicorData) that needs to be moved to the new dirs?
I thought it would. But looking at my app server Epicor directory I don’t think that’s the case. I don’t remember creating these release directories for each release but I may have… it was over a year ago I did the .400 upgrade from .300. And much longer for the .300 from .200.
Nothing would overwrite. You could even leave your EpicorData the same, its just temp-stuff. You only get in trouble if you are running like EDI Import or some directory watching service like BarTender Integrations/Commander…
I just named mine EpicorData, EpicorDataTST, EpicorData102600 etc…
I should have said doesn’t Epicor suggest new servers for release upgrades. I know you can do them on the same server. I just though best practice was new servers. I could be thinking major releases though.
and multiple versions too of Epicor.