I have never been through an Epicor upgrade of any sort before, and we want to make the leap from 10.1.400 to 10.2.300. Is there anything stopping me from going through the entire process in our TEST environment, working out any glitches and then dropping current data in and using as new production environment? Or am I taking too many leaps? I am not experienced IT and I wanted to ensure that I was not going to have interaction between test and production during this process. Here is the structure in Admin Console. I am trying to update E10TEST.
Any guidance or advice would be very much appreciated. This feels like an intimidating process and I’m scared everything is going to break.
Also, does anyone know if our Ty Kinetics EDI scripts will continue to work on new version?
Alice, Here is what we typically do for our upgrades:
Have a test environment for upgrades that is isolated and sole purpose is for testing only (Virtual Machine is what we use, this will contain the app pools and SQL instance all in one. Its basically a replica of the current app/DB server but is an all in one environment)
Copy Production database and Report Server database
Install current Epicor production version in test environment (10.1.400)
Take a checkpoint on the VM in case you need to rollback if you mess up the version installation.
Restore production/report database in the test SQL instance with new naming conventions so you don’t get confused with production/test environments
Navigate to admin console on the test vm and create the new database server reference of the test SQL instance and your recent restored databases
After databases have been linked in admin console, then replicate your production app servers in the test environment
Once you have the recreated app servers up and running with version 10.1.400 and confirm basic functionality works. Then take another checkpoint in preparation for 10.2.300
In preparation for 10.2.300 installation I would read the release guides Epicor provides on the EpicWeb in case there are any new installation procedures
Once you have finished the 10.2.300 upgrade you can then proceed with having individuals utilize the test instance to ensure everything works as expected.
Then if all test scenarios pass, then set aside a weekend for an upgrade
**Couple of things to consider with building this test environment is to ensure everything is isolated, so its best to review the following for production references:
-windows service accounts
-SQL service accounts
-report server shared data sources
-admin console database server reference
-application server setup credentials and paths
TIE Kinetics EDI Questions:
-Unfortunately this is a tough area when it comes to upgrades as the only true way to find out is by having another test instance of EDI in conjunction with your Test app/db instance. But to provide some insight, we use TIE Kinetics EDI and from what we have noticed per each upgrade is that the report data definitions can have new field additions or be re sequenced with throws off the mapping for EDI. But if you have custom EDI scripts with direct code references instead of the report data definitions you should be fine.
Side Question:
-Do you have a DBA resource or IT team resource to aid in the setup? As the initial test environment can be quite time consuming, but once its setup you can always use it for future upgrades.
Tyler outlines a good process. Everyone does it a bit different of course. In my opinion, you NEED to have a replica of Production all set up and ready to use regularly. Each patch/update from Epicor should be tested, then applied to Production. Might as well get it all set up now, and get familiar with the process of moving a copy of Prod to Test (which can be done without rebuilding everything again).
Further gotchas will include
any 3rd party software from Excel to reporting tools, that may access the database - because the database schema has changes between those versions
any Epicor related application - AFR, EFP, EPM, Manifest, - it’s a long list of things that may also need upgrading, adjustments, or reconfiguration to use with the new version.
any custom code from CSG will need to be uplifted by CSG - this can take some time
The release notes will show any changes in the app and DB model - so ALL of your customizations must be checked.
And one small thing - if you have customized the UI, I would recommend removing the Personalizations from those screens before the upgrade. We ran into some trouble with those when they referred to elements that Epicor changed between versions.
Thank you so much. This is exactly the kind of info I needed.
So my understanding is that the TEST environment will need to be on its own SQL instance? Now, because of my ignorance about SQL, I need to understand - is each app-server listed under Server management its own SQL instance or are all of these currently lumped into one, in our case called EPICOR? Forgive my newbie questions. I have minimal IT assistance and I am really trying to develop some understanding of this. I’m sure there are many upgrades to come…
Its no problem, its what this forum is all about helping people.
Virtual Machine Setup Example:
-Install Windows Server 2016
-Install SQL Server 2016 (with reporting services) in the environment
-Install Epicor version
-Restore production databases on SQL instance inside the environment
App Server Question:
-Each application server that is setup in the admin console under server management should only have one database associated to it.
SQL Server Instance:
-This should contain a database for each application server as well as the main report server database (contains all of the standard and custom SSRS reports) and all of the temporary report databases (These get created upon the application server deployment) for each application server.
Depending on your load/user count, you could have just one SQL server servicing both the production and test instances. This is how we do it, and we just name the databases accordingly. So our single SQL server contains Prod, ProdReports, Test, TestReports, and the other DBs (temp, master,etc) that SQL needs.
We have separate Appservers though. Makes it easier to snapshot/test/break/reload as needed.
Is there a reference to the report server database in the admin console that I am missing? My extent of knowledge about the report server is that I access reports through the portal on my browser…(Epicor/Reports/Pages/Folder.aspx).
And within this setup, you are able to try out updates on your test enviro and avoid any unwanted interactions with production? This appears to be the way we have it set up right now, with one SQL instance but separate appservers. With my limited technical prowess, I would love to be able to use the TEST environment that already exists in our system.
@Alice_Elizabeth in admin console, click on an application server and to the right you will see “application server configuration”. In the far tab on that dialog menu you will see the report setup:
Yes. the SQL server is just the DB server - in the background so to speak. Everything you are concerned about happens on the Appserver. Inside the Appserver configuration you tell it specifically which SQL Server & Database to use so there is no reason they cannot cohabitate on the same SQL Server as long as it has enough horsepower to keep up with your load.
As for Report DB’s, these are also specified in the Appserver configuration, so they can be on the saem SQL server as well. But SSRS takes some horsepower too, so you have to judge your load appropriately. Many folks point the SSRS Reporting (and databases) to another SQL server for that reason.
Just for completeness sake and information for others, there is also the option of letting Epicor do it. The Cloud Upgrade tool is reasonably priced. You ship the database to them, they upgrade it, you restore it locally in a fresh install. You get a nice report about what will and won’t upgrade and they call out all of your customizations for you. For those companies with a full IT staff, they may want to do it locally - if they have the time to - or someone who really wants to see the sausage made, then doing it oneself is certainly an option. If you’re not IT or don’t fell comfortable, this might be a good option. That or hire it out to someone with experience doing it.
Wow, I didn’t even know that was an option. In our case, I do want to witness to whole gritty process and plan to enlist some knowledgeable folks to hold my hand. Thank you Mark!