General question regarding upgrade to V2026 in Pilot. We are fully browser since upgrade to Kinetic cloud last year. We have been on-cadence with Epicor-managed upgrades in Pilot and Live so far which works well for our limited in-house IT resources. In looking at the Cloud Managment Portal, upgrading PILOT to V2026 looks very straight forward. Would there be any reason to hold off on that for a while? Upgrading Pilot now would certainly give us more time for testing custom BPMs, dashboards, etc before Live is upgraded. Not sure why we would wait for the scheduled date rather than getting a head start on testing.
It has already been rolled out in ANZ for Pilot so check the upgrade schedule it should not be far away. Personally I would just be that little bit patient for this one.
Generally on upgrades, especially major version upgrades, there is a ton of work post upgrade to get things ready for users. Conversion Workbench, etc things needs to be ran. I assume there is an upgrade guide you can review to see if anything required would be more than you’re willing to do solo.
I’m with @Hally and wait as it’s coming soon after Insights.
Thank you all! I’m sure I was over-simplifying and will take heed to the advice. I certainly do not want to spend the next few weeks applying updates/fixes to Pilot and ending up at the same date as the Epicor-managed scheduled date. I think there should be more than a month to test between Pilot and Live for this level of upgrade. We are fully browser and I imported/applied all customizations post-Live using Solution Workbench. We’re anxious to test all customizations esp dashboards. I’m working on learning App Studio but will miss Dashboard Maintenance.
EpicCare has acknowledged this issue and created PRB0317202. Thisis currently keeping us from testing all custom reports, since they all throw the same exception due to logo’s being added. Once the logo is added, there is also no way to remove it as far as I know.
Hi Brian, can’t say this will work for you, but I did have some issues with custom reports in my testing. This was during the Controlled Release, so it may have been related to THAT specific environment and not necessarily applicable to an on-prem system… but…
My issue was my custom reports weren’t working at all… errors saying the reports could not be found, locations, blah blah blah.
Obvious next step was to take my custom reports from my LIVE (2025.2) environment and upload them into (2026.100). This also failed!
My existing custom report styles would not take an upload.
I found I was able to get around this by making a fresh copy of the BASE “Standard - SSRS” report style from within 2026.100. I then uploaded my zipped custom RDL(s) into that fresh copy. Repointed to my custom RDD (if necessary). I was then able to run my custom report.
Can’t say why that all was needed, but making a refresh custom report style WITHIN the 2026.100 environment worked. Using report styles created in previous version would not.
Again, just something you could try and see if you can get any further so you can continue testing.
But hey, good news. Testing not needed in the future 
to that post? 
I suspect it had just been too many years since the last versioning numbering scheme change. 
I had an issue with reports. They printed fine.
However, when trying to download them from Epicor (Report Style maintenance), I got errors like:
No HTTP resource was found that matches the request URI ‘http://localhost/Reports/api/v2.0/CatalogItems(path=‘/KineticUpgrade/reports/CustomReports/ARInvoiceForm/ARFormEMEA’)/Content/$value’.
My issue was resolved by upgrading my SSRS Services from 15 to 16 using:
To resurrect a dead horse, all I really would like is DMT in the cloud. Then I have no worries about Power Tools. But that Idea seems to be dead.
Dont lose hope. it is NOT dead… just not started yet. We have had multiple discussions, but priorities were to get the primary end user into full browser mode… we created the Powertools as a holder for the final few TOOLS that still needed a bunch of work. These were all specialized features that need rewrites to make them browser based.
For quite a while there’s been a little voice in my head saying that a simplified DMT would be straightforward to build off of the rest metadata.
This returns all the service endpoints: /api/v2/odata/<company>
From those results, grab the url value for a service and do like so /api/swagger/v2/odata/<url value>.json to get service methods and their fields and field types.
Staple on any old csv parsing solution, add a pinch of validation, mangle the results through curl, and you’ve got a primitive DMT. Could be a web app. If you Power Query wrong enough you can DMT from Excel.
Optional step 2, desktop DMT embeds a lot of hardcoded multistep processing. For example, bill of materials / operations will check a revision out and (usually) back in for you as part of a material or operation update that’s a single step in DMT. That feels to me like a nice-to-have since IMO anyone DMT’ing needs to know all about what’s going on regardless of any black box helpers.
And… fixt TOs.. Unless it already has and I missed it all
No idea what that says, but I believe in you!
We may just have the solution for you, are you at Insights this year? We are looking for Beta testers…
I can not find the PRB number which you mention. Is this the correct number?
