We are currently running ERP10.1.600 on Windows 2012 R2 with SQL 2016. We are getting ready to build another VM for our upgrade to 10.2.300 but we were wondering what some of the major benefits (from an Epicor point of view) would be to running on Windows 2016 and SQL 2017? Looking for reasons to justify the upgrade costs otherwise we would just continue to use Windows 2012 R2 and SQL 2016 for ERP10.2.300 as it looks like those are still approved stacks for this version:
Thank you for any thoughts or recommendations anyone might have on this to help us decide what direction to take for our upgrade.
-Heather
We are Server 2012 R2 and SQL 2014 running 10.2.300.8 in Dev and 10.1.500.17 in Prod.
Since this SQL install is just the backend of Epicor, we don’t need any of the newer fancy bells & whistles so we’ll be holding off for another version or two. For us who are on a budget as well, once we get something working, we tend to save the money and headache of keeping current in exchange for not having to worry about it except in every other leap year.
Server 2012 R2 is no longer in mainstream support. Really depends on the industry you are in and how critical things like regulatory compliance (SOX, ISO27001 etc) and patching need to be in your organization. There will be organizations who will be obligated to run a critical business system like Epicor only on os’s that are on mainstream support but plenty more who where this is a best practice but not an obligation.
I would get off server 2012 but sql 16 vs 17 i wouldn’t go out of your way on that one unless the table caching stuff has been implemented to the extent they wanted. That might be a @Bart_Elia question?
This has some propellers spinning about some things but there is nothing short term coming to market that I am aware of that will require ‘Enterprise 2012 / Standard 2016’. If you are going thru the pain to jump from End of Life 2008, I’d heavily consider skipping 2012 but other than that, nothing we will require safe harbor, forward looking statement, etc etc
Do the math, review the new toys you get in standard now that can help you operationally.
Are the SQL things in your BAQ determined by the version of SQL that you are running backend? By that I mean, if all of the epicor versioning is the same, except you are running 201x and 201x+1, can you do the new things because you are running the new version? Or is that limited by what Epicor is up to?
We opted to upgrade from 2012/2014 when changing servers at the end of last year.
The key reason for us was changes to Analysis Services rather than Epicor directly, but we did get confirmation that we could go straight to 2017 rather than 2016 simply because we didn’t want to be forced to upgrade again too soon.
SQL has new functions IF Epicor allows you to call them (there are some security implications) then you can use them. A lot of SQL stuff you can call in-there if you are clever with it.
My understanding was that Epicor had the requirement from management to be able to switch DB’s within 6 months which is why they have never adopted DB specific SQL functions.
Yep the power of Entity Framework was always meant to support Multi-DBs… moves to PostgreSQL because MUCH Better Concurrency support and many more things it supported the JSON type before anyone else, those open source fellas are ahead of their time.
But then again Epicor has a ton of Stored Procedures catered to MS SQL. I doubt they will reach that goal until 2030
The majority of the sprocs (All the Get ones) are all generated so there is a lot of flexibility there. Management APIs, the full text search handling and the few custom sprocs for perf would be the things that are harder dependencies.
Architecturally, we always have a consideration for strange events to happen - MSFT going out of business is probably not one of them but you get the idea of potential risk management items we go thru in setting requirements and taking dependencies.
If you ever want a tour of those sprocs, speak up. They are the result of a lot of time with the SQL Server team to tweak and optimize holed up in Redmond. Hopefully the cobwebs have not totally taken over since working on that… 2009? It’s been a while.
it supported the JSON type before anyone else, those open source fellas are ahead of their time.