Posting in case anyone wants to ask questions since it’s fresh on my mind…
Only took a few hours actually, until things just didn’t work right. Found some “mistakes” in the Epicor Upgrade PDF (already reported) and learned some things about the DEV team Only needed three EpicCare calls this morning, so I’m pretty happy.
If you think you have questions - We use a lot of the system, EWA, EMA, Mobile CRM, Configurator, almost all the other usual modules plus CSFs for UK and NL, Doclink (for now), AFR, EDA, and Agile ConnectShip(aka the non-Epicor Manifest) and I can speak to them all.
Great job Mike! May have questions later on Agile. We just did this three weeks ago to 10.2.300.7 at one of our sites. As long as the first three numbers are current I call us current nowadays. Hard to stay on top of the fourth number in the version.
I am just beginning our E9 to 10.2.300.10 first round and I have an embedded dashboard that does not filter. I saw an earlier post that embedded dashboards had an issue in 10.2 and am wondering if they still do.
Hmm, I think I have one on my Quote Entry screen that gathers up a customer’s history and I had to rework it form 10.1 to 10.2 because of the ‘subscribe to UI’ filter… I got my answer form this site I’m sure, but if you need me to share my UI customization so you can pick it apart, I certainly can.
Calvin - I quoted the word because instructions are often developed in the vacuum of a development lab somewhere and while not technically wrong, those instructions just do not work for us out here.
One example of what I believe is just incorrect, is that you need to plan ahead with your appserver upgrade. in my case, once I installed the 10.2 code and started the admin console, it was too late for me to remove and re-register my appserver. According to Epicor support, I should have removed the appserver before installing the 10.2 code and starting the admin console for the first time. I believe the comment was “Yeah, that never works. You need to remove the appservers before you do anything to the server…”
And that little tidbit cost me about 2 extra hours of trying, failing, cleaning up, and recreating the appserver from scratch…
And a few other things relevant to my installation but nothing outright incorrect for the purpose of the document.
If is not too much trouble. I got a confirmation from support that it is broken and the PR it is on.
I was thinking I could replace it with a baq to a grid and a button to run the query, but as I am on day three of this adventure, I am not ready for that yet.
Thanks for that. That’s the exact type of thing that’s good to share.
And expect that most “mistakes” are made when there’s something the developers do automatically (kind of an IT muscle memory) and forgot that us users don’t know these things. That, and ambiguous phrasing in the instructions.
@gpayne - I was incorrect - I have it on Order Entry. I’ve attached the UI customization export and the dashboard export (containing the BAQs) for you to play with. Please note that the OE screen has a tab called AR data that is not a dashboard, but rather calls the AR Credit functions and builds a dataview behind the scenes via code, then just maps the results to the screen. It allows our Customer Service folks to see the customer’s current AR status at the point of Order entry. App.SalesOrderEntry.SalesOrderForm_Customization_SalesOrder_C03_CustomExport.xml (548.9 KB) CustOrderHistory dashboard wBAQs.dbd (239.1 KB)
John - Have your dept supervisors check every screen and tab they use, then sign off that it’s good as-is. Same with reports and dashboards (both std and custom). We had enough issues during the first week after our upgrade to last 2 months! And we thought we caught them all during 6 months of testing. Ha!
John, that is a VERY good question. Yes and no, so I’ll explain (at length it would seem). I have the luxury of having a completely isolated server (aka SandBox) that I put both SQL and Epicor appservers on for testing. I can destroy and rebuild at will without affecting my Prod/Test/Dev environments. So I tend to do things like this:
I’ll do the upgrade without reading the manual (too thoroughly) at least once so I can just see what the process looks like
Then I do it according the to the manual.
Then I open my tickets with Epicor to get answers, fixes, etc. in order to make sure the technical side of the upgrade goes well.
Then I get the core users involved and work through all the customizations, processes, etc. and build a whole solution of custom objects to apply after the upgrade.
I also have a complete library of custom objects and an XLSX workbook that documents everything down to the smallest things. And it includes WHY they exist. Having all these exports (for each version of Epicor) is a nice library to fall back on when things start throwing errors.
Then I wipe it all out and do it again and again until I feel good about it and get my timing down.
I usually make a mess of my whiteboard as I outline all the steps needed that Epicor’s upgrade guide failed to tell me about or got wrong. usually not a lot on their part, but a bunch of stuff on our end because we use things like Agile, AFR, EDA, Doclink, etc… All of these things need to be addressed after the upgrade so I basically have a lot of notes about what to do and in what order.
Then I schedule the ‘downtime’ with everyone - from the president down to the graveyard shift guys - and I do it in person as much as possible.
Get any ‘training’ done before I do the upgrade. This really prevents a lot of headaches - trust me.
So would I do things differently? Not with the above process - I love it and it’s worked for me during three implementations and two substantial upgrades. I do however ALWAYS miss something. Aggravates the out of me each time. So I wish I could stop doing that.
But seriously - I wish:
I would have a second or third person working with you is the only thing I can think of. I don’t really have that luxury without hiring a consultant. Get them familiar with every step. Having a second pair of eye and hands helps to not miss anything and is a nice division of labor for all the post upgrade tasks that are not interdependent.
I would take much better notes. The few lines on the whiteboard may make sense when you wrote them, but a month later you’re like “WTF was I talking about?”
Another user sent my a PM, but my answer should be on this post as well.
@askulte made a response above that is totally correct, but I go much further with detail in hopes it answers your question regarding pre-upgrade testing by the users.
We have three levels of the Epicor upgrade team:
Technical - mostly us in IT, lead by me. I do everything I mentioned in the other post, and my folks are focused on hardware, client installs and initial testing/troubleshooting (SSO, AD issues, distribution via GPO, etc.) and I’ve got a Configurator guy. He owns the configurator and everything associated with it.
I also have someone in a cross-functional IT role who works up a test script - usually 25-ish quote-to-cash scenarios that test various parts of the process including job processing, scheduling, inventory, etc. all the way to wathcing the cash receipt hit the GL and the reports (everywhere) coming out right. This is so very important.
Core Team - Department managers and I get together to talk about what the upgrade means (everything I found in the upgrade, new features, and release notes) and they get first crack at testing the new version. They get a few weeks to play around and check things.
At this point we work on getting any bugs out of the system - BAQs, BPMs, UI customizations, UD Fields, etc - so the rest of the testing goes as smooth as possible. This gets me to my ‘comfort zone’. I could do the upgrade here and deal with everything else like Andris mentioned after the fact.
My Rule - Accounting must sign off that every bit of testing gets numbers into the GL and that their reports are all perfect. I will NOT do an upgrade until they sign off.
Departments - Members of the core team go back and work with their departments on testing things. This I leave up to them because I just can’t spend the time micromanaging this part. this part is pretty much so everyone doesn’t feel ‘shocked’ with anything new on the screen or any process changes that the core team decided upon.
Basically the whole process is a continual effort to get each of the core team members to ‘sign off’ that they are satisfied with how everything will be on Day 1. Lots of emails and iterative processing of issues we find.
Then we do the upgrade and they find all the rest of the that they ‘said’ worked alright before and I spend 2-3 days fixing little things.
I’ll say for the record, it is now DAY 3, and I can spend two hours on epiusers.help because I’ve got nothing pressing to work on that can’t wait for me. so the process I use works pretty well - but it takes a LOT of energy on my part.
Congratulations @MikeGross! Thank you for all of the helpful information! I have a 10.2.300 VM up and running and ready to unleash the testing hounds against in the next day or two.
Did you run into any major issues with your Configurators in this upgrade? That’s probably our biggest concern as we have a LOT!
Was EWA easy to setup and do your users use it a lot? Do you run many Customizations through EWA? I’ve had some problems getting our Customizations to work in EWA.
As for the users - no griping from them, generally speaking. I am very upfront - and truthful - with all of them. They know why we HAVE to do this (for all the reasons we here all know), and when explained properly everyone feels involved and in the loop. And they all know they can ask me any question at all - and I will answer them truthfully. This kind of relationship takes time to build but is SO worth it. Plus, most of them get to see parts of it before the upgrade so that is how we control the rumor mill.
We also have a Office365 Teams group that I communicate with all the time.
We basically work the same. We are fortunate to have a team of 4 IT guys (well 3, 1 is mostly networks and computers… ) working at making Epicor be at it’s best for our users needs !
We meet every Managers responsible of departments, showing them the new application and asking them to provide a script of what they do everyday, forms they use etc… so we cover 90% of their work. (we do not know every workflow they use so making them part of the upgrade process is important.) We ask them to spend the week testing, and come back with feedback.
We are under that process right now. So far so good.
We did already convert all our customizations to work well in 10.2, spent two weeks on that part.
Our first upgrade test was somehow corrupted, password reset was not even working…
We did a test upgrade last week and it went well…including password reset… so we did a backup just in case… if needed.
Only needed three EpicCare calls this morning, so I’m pretty happy.
out of me each time. So I wish I could stop doing that. 
so the process I use works pretty well - but it takes a LOT of energy on my part.