Thanks for sharing your detailed experience.
APR will continue to be part of the external tool set like DMT for the time being. We donāt have full SQL capability in either APR or RDD using the tools available. I donāt know whether this is true for on-prem or not, but I know that I am frustrated at times trying to do something with the APR tools or RDD that would be simple to do if I had full SQL capability. Report creation/testing is more difficult on the cloud since we donāt have access to the Reporting Server outside of Epicor. It is necessary to download the report, modify it in Report Builder, re-import it, test, modify, re-import, test etcā¦
These are not major issues, just annoyances if you are used to having full direct access to the servers.
@hkeric.wci and @Banderson, I want to address some of what you saidā¦ but to do so, I had to call on a couple of internal experts (since SQL is not my specialty).
I want to add some important context here, because a key part of the picture is missing. Epicor application code is deliberately written to favor index SEEKs, not SCANs. Thatās a core design principle.
What does happen, though, is that customers create BAQs, dashboards, or custom queries that introduce scans through joins, predicates, or non-SARGable logic (Hope you know what SARGable means because I didnt until i looked it up). When that occurs, SQL Server behavior often gets blamed on āEpicorā when in reality itās the shape of the query driving the result.
Index rebuilds are also getting credited with more magic than they deserve. Rebuilding an index is a very big hammer. Yes, it can reduce fragmentation, but it also forces SQL Server to refresh statistics and recompile execution plans. In many cases, the performance gain people see has more to do with a newly optimized plan than with the index itself. The same result can often be achieved with a much smaller hammerā¦ updating statistics or fixing the specific query patterns that caused the problem in the first place.
MRP behavior is another piece thatās often misunderstood. MRP routinely clears out large portions of certain tables and then repopulates them. That will fragment indexes. But fragmentation mainly affects scan-heavy access. All server-side logic, including MRP, is designed around seek-based access, and seek performance is largely unaffected by fragmentation.
On the cloud side, database optimization is not being ignored. Our operations teams continuously analyze hosted databases, watch for plan regressions and problem queries, and step in when execution plans need correction. Customers give up the ability to manually tweak things, but in return they get a team whose full-time job is doing this across thousands of environments, consistently and safely.
Hope this helps in the continued dialog, and adds clarity to what happens in the cloud.
Nice post. Thanks @timshuwy
Perhaps in a low-trust situation, itād be helpful to make transparent roughly what maintenance plans the cloud team is doing and provide a dashboard enabling customers to exec or schedule common monitoring/troubleshooting DMVs so we can peak not tweak (and keep you honest)
For example, is AUTO_UPDATE_STATS_ASYNC ON always?
Are there ongoing maintenance jobs like:
Daily: EXEC sp_updatestats
Weekly: FULLSCAN stats on sensitive tables
Biweekly: Targeted rebuilds based on page density + page splits
Monthly: Reorganize where fragmentation affects scans
Quarterly: Review fill factor settings based on real page split data
Iāll show some more examples tomorrow, but Iām not talking about index maintenance here. Iām talking about the existence of a ton of indexes that have little to no usage history at all, so their very existence is a drag in the write performance and bloat of the size of the database. Each index is a copy of a part of a data table.
Imagine needing a dictionary to look up the definition of words, but the only one you had was also an english to Spanish dictionary, and an English to German dictionary and an English to French dictionary. And you wrote a lot of new words on those dictionaries. You only need the English ones, but since you have Spanish, French and German hanging around you have to keep those updated too. So you have a lot of extra work write the data and dead weight and paper to keep extra dictionaries in sync you donāt need around. Right?
You can look up the statistics of how often indexes actually get used in your database with normal use. Last time I looked in our database I saw a LOT of them that were never used in the period that was recorded (since the last restart was what I believe is how that works). So all of those indexes that arenāt being used still have to be maintained (written). (This argument sounds really familiar to another justification for not having to maintain two copies of virtually the same thingā¦
).
And I know some will argue that it doesnāt slow down the read performance, it only slows down write performance, but weāre having massive record locks and 10, 15 sometimes 20 minutes wait times to write a large order in. Itās a real problem.
If every once in a blue moon the system has to do scan because itās missing an index itās a trade-off I think we need to look at because at our company we are seeing very real useability issues with large order entry and Epicor is going to have even larger bills when it comes to unnecessary compute bills when the big corporations that have traditionally been on prem come into cloud.
I appreciate the post, but a statement like this isnāt something that brings comfort as we have all dealt with Epicor support staff and that usually ends in frustration. This statement is saying to trust them with it, theyāll do a better job than we are.
These statements are not consistent with my experience across multiple public cloud customers over the last several years. I can appreciate there are many cloud customers who are satisfied with the performance of the public cloud platform, and the support received from cloud operations.
However supporting SOME customers adequately <> supporting ALL customers adequately and consistently which is the bar here. If Epicor decides to continue with this decision and force all on prem to cloud, I believe the voices like mine are going to become a lot louder failing any substantial improvement in cloud operations and the cloud support experience.
I hate to pile on, but I have to accentuate the validity of this statement. You can see many instances of examples on this forum where going to support does not get you any answers. I know that my personal stance on support tickets is the only reason to put in support tickets is if I know the root cause of the issue and how to fix it (usually down to a source code level, discovered through debugging), so that it can be fixed for future releases and for the good of the rest of the customers. If I donāt know how to fix it myself, I donāt even bother talking to support, because I rarely have had them be able to fix anything for me.
I do understand that most of us here are anomalies on this forum in that we have extremely high skill and experience that isnāt the norm, but we are still having real problems that need to be fixed and thus have real anxiety over losing tools and levers to fix those problems.
@Banderson Youāre absolutely right, and I think this is an important point that often gets lost in these discussions. The fact that some users have high skill levels and deep experience doesnāt make their problems less real. If anything, it means theyāre encountering edge cases and complex scenarios that others havenāt hit yet but eventually will; issues that standard support channels often canāt address.
Thereās sometimes an unfortunate tendency to dismiss expert usersā concerns as niche āpower user problemsā that donāt matter to the broader user base. But experienced users are often the canaries in the coal mine, surfacing fundamental limitations before they become widespread issues.
Our anxiety about losing tools and control surfaces is completely legitimate. Many of us have developed workflows and solutions that depend on specific capabilities. Having those removed or restricted without adequate alternatives isnāt just inconvenient; it can be genuinely destabilizing to our work and the value weāre able to deliver.
The ājust trust us, the new way is betterā approach rarely accounts for the real-world complexity of what people have built. When changes happen without clear migration paths or acknowledgment of whatās being lost, it undermines the trust thatās essential for a healthy platform-user relationship.
As the IT leader, this decision impacts how the ERP fits into the overall IT vision for my organization. With an IT team of only two/three people, major changes like this create a ripple effect that forces us to evaluate the ERP value to the organization, as well as reprioritize projects and reconsider organizational staffing. These arenāt abstract concerns; they have direct operational consequences.
I know this isnāt going to change the outcome, because this really isnāt a debate. The final destination has been chosen. But, since the discussion is currently on support topics, to support @Bandersonās point, I wanted to bring this one back up and at least voice this as a concern for all of us. Iām a cloud customer, but the toolset available to on-prem has been a saving grace to many of us, many-a-timeā¦ this was just a very recent example:
Resolution:
To summarize: an issue that was brought to support a month before the update was to hit Production environments was not resolved and ultimately wonāt be resolved by Epicor until 2026.1 
. This issue prevented the printing of packing slips, labels, BOLs etc. Pretty crucial documents for companies that want to continue operations.
Had it not been for @josecgomezās use of on-prem tools (and blessing the community with his solution), would we have been at the mercy of Support and unable to operate for months?
This is why, even for us cloud customers, this is an important issue and the hopeful āmiddle-groundā solution is crucial to all of us.
Great example. I probably have a dozen examples where Iāve done the same thing and got the problem solved quicker as a result.
Iām not sure how Epicor feels about decompiling their binaries. Itās probably not something they intended for customers to do. I would think they would want to protect their IP. That becomes much easier for them to control in the cloud.
They had a class on .NET Reflector sometime at Insights 2012.
This is only one example of on-prem heroes being able to keep us SaaS folks functioning while struggling to get a resolution from Support. Opening a ticket with support often goes one of three paths:
- IF support can not replicate the issue it is basically dismissed as some kind of edge case issue not affecting other customers. Leading to back-n-forth with support trying to convince them this is a legit issue.
- IF they can replicate, a PRB will get created thatāll come back with āWorking as designedā or sit for who-knows-how-long before (or even if) a fix will be created.
- IF weāre lucky a PRB will already have been submitted. Near, āWinning the lottery oddsā a hotfix, or āfixed in xyz versionā, will be the answer.
Promises and statements from the CEO from 2 years ago are invalid because of āChanging markets and environmentsā. I donāt think a class from 13 years ago means anything.
I do it all the time and include the decompiled code pointing out the issue with the bug in the support ticket. It still gets stuck in PRB, but at least it got through support faster.
The overall support issue is what is making me extremely nervous. That is the part of the SaaS move that is making look at alternatives.
Business cannot wait on tickets and PRBs to sit for over a month with no resolution. I currently have one on Quickship that, if I wasnāt on prem, weād have to go back to Worldship and FedEx manager just to get international shipments to go.
Iāll be writing more about my views on the subject later, but I wanted to make a quick reply to this. Multi-Company has many, many issues, though it is slightly better than it was when we started on 10.0. Without having access to IntQueIn and IntQueOut Iād have to get fixes from support much, much more. Support has gone downhill since we started, I donāt use them unless I absolutely have to. I donāt think Epicor themselves have a clue of the scale of support requests that would have to come their way if we canāt fix it ourselves.
100%. Weāre already in the cloud. Itās beenā¦OK I guess. A few outages, a few bugs, but weāve been able to function for the last few months.
What really scares me is future volume. As customers shift from on-prem to cloud, will their support staff be able to handle the anticipated expontential increase in [EDIT - cloud related] cases?
Do you know if the Premium Support Package has any faster turnaround? Apparently it skips a level, and goes right to a SME.
I do not. Sounds like a horrible support model for moving everybody to the cloud, when we can resolve most issues ourselves now for less cost.
I spend more time in tickets and follow up than it takes me to resolve on my own most times.