My company has (finally) started seriously preparing for an upgrade from 10.2, and after attending insights and many different speaking sessions afterwards I feel like I have a good grasp on the mountain of work ahead of us for kinetic screens, kinetic in the web, and a possible cloud transition. I however do not have a good idea of what the workload for the version upgrade itself is like. Ignoring everything else, how big is the workload to just get an on prem epicor installation up to the latest kinetic release, keeping everyone on the smart client? Does anyone have any experience in doing that and gradually easing people into kinetic screens, rather than dedicating a ton of work to making sure that people are using kinetic screens the day the update is live?
Itâs not that bad. If youâve never done it just follow the upgrade guide. If youâre staying on the smart client itâs not big deal to upgrade really. Youâll have some work to do if you have BPMs and customizations probably.
I upgraded from 10.2.700 to one of the earlier versions of Kinetic a couple of years ago. The process wasnât too bad, just time consuming.
Custom SSRS reports were one of the biggest headaches.
There were a bunch of BPMs with custom code that needed to get reworked.
But other than that, test, double test, triple test everything. Every single personâs process.
There was this one custom receipt labels report that I didnât know existed and it had a double table join that stalled the app server company wide. It made for a stressful day to say the least.
The hardest part about moving to Kinetic screens is user adoption. People will complain about anything and everything.
The kinetic screens will predictably be a big lift for users. Can you give an example of a BPM that needed to be reworked? What changed in the upgrade that caused custom code to break? We donât do a ton of SSRS reporting but have plenty of BPMs, many with custom code.
As far as BPMs go, one of the biggest issues that I faced was the change to the way that companies and/or sites needed to be changed, ( CallContext.Current.TemporarySessionCreator.SetPlantID() , etc..). I was not the original author of the BPMs and was surprised by how many we had that required this change. Thatâs just one example. If youâre not multi company or multi site, that shouldnât be a problem for you.
Weâre seeing this pop up a lot in BPMs too:
The type âTransactionScopeâ is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Transactions.Local, Version=8.0.0.0, Culture=neutralâŚ
If youâre moving from on-prem to cloud - watch for anything with a filepath where youâre changing from an app server to an Azure share. In our case weâve got quite a few things with EDIHQ and BarTender (ânot available in cloudâ, had to bring that app on-prem).
Itâs not that bad, but depends on how customized you are. We had a lot of Service Connect trouble with the 10.2 to 2022.2 jump, a handful of SSRS reports that broke, and a handful of BPMs we needed to rewrite.
If you are still using net.tcp bindings youâll have to switch to HTTPS and learn how to deal with SSL certs and all that.
Are you keeping the same servers or doing an infrastructure refresh as well? It will add a chunk of time if youâre building out new servers.
I think for me too, the SSRS part of the upgrade was the harder part- not knowing how SSRS works to its core.
Weâre on prem and in the process of converting from classic to kinetic screens. Instead of doing it all at once we are doing it in a staged approach, by department.
The biggest hurdle we have faced so far is learning how to do things in application studio / functions vs c# in the classic screens. Little in depth documentation on how to handle migrating customizations, the best documentation I have found is on this site. Good luck.
The biggest issue weâve seen the with BPMs that the method used to trigger events have sometimes changed in the Kinetic UI. Youâll get use using F12 to chase down those new events.
One example is Erp.BO.EngWorkBench.GetECORevData is now GetECOGroupandECORev. Since we are still running hybird of classic and Kinetic we have to have two method directives to cover both UIs. There have been a few others weâve run across but they really can only be found by testing each one.
oof. this is bringing me back. I canât remember all of the details but there was a lot of updateable ones that needed to be changed to look at CompanyID (i think??)
There was also the below issue which was on so many.
Previous admin had a bunch of BPMs that were like this.
var PartRow = (from ttPart in ttPart select ttPart).FirstOrDefault();
When the Epicor conversion happened it rewrote them to
varPartRow = (from ttPart in ds.Part select ds.Part).FirstOrDefault();
But they needed to be
varPartRow = (from ttPart in ds.Part select ttPart).FirstOrDefault();
This sounds like something that I wouldnât have to deal with in the initial upgrade then, right? If I am just upgrading the epicor version to 2025.2 but keeping everyone on smart client + classic screens I can hold off on needing to update that BPM until that group of users moves over to kinetic screens.
I believe new servers would be getting built out, although I would not be primarily responsible for that. Itâs tough because we likely want to eventually move to the cloud, but the 3 headed dragon of version upgrade + kinetic screens + cloud transition is realistically not something we can tackle all at once.
If I can just get us on the last version of kinetic before the smart client sunset, that buys us time to start rebuilding customizations/bpms for kinetic. In my head we would upgrade to 2025.2 or 2026.1 (whichever is the final smart client update), after a successful upgrade with everyone still not touching kinetic screens we would start rebuilding bpms+customizations and start having groups of users test and migrate to kinetic browser. After all that, then we could take another look at the cloud.
Correct. Some of the other items mentioned may come into play if your coming from 10.2 to 12.*.
Yeah, I would not even think about SaaS until you are 100% browser. If you go to SaaS while youâre still on classic you will have a gun to your head that triggers May 2026.
Weâre lucky, we started on browser with a handful of exceptions. After the upcoming cloud move the only things weâll have left on client: DMT and BAQ Designer (cuz I hate hate hate hate hate hate the browser version)
Yep that was the impression I got at insights. The benefit of the smart client sunset is that it gives me some perceived leverage to make sure that we get an upgrade through before the smart client disappears. if we wait for 2026.1 to come out, we are hosed.
The hardest part for us was that AR Invoice changed from the ARForm RDD to the ARInvoice RDD, forcing us to convert all our AR Invoices to use copies of the new RDD, but try to do minimal name changing. All of our invoicing is FAR from what Epicor wants to do out of the box.
Pay close attention to bpms with custom code. There were namespace changes which will trip you up.