I’m sure there is a KB article you can refer them too. 
Well, support finally responded on this. There is so much wrong with this that I don’t even know where to begin.
Hello,
I appreciate your patience as we’ve worked through this. I understand how frustrating this situation is, and I want you to know that I’m fully committed to helping you get to the best possible outcome within the constraints we have.
After reviewing the details of your case and environment, I believe we’re aligned on the challenge you’re facing. Unfortunately, I need to share some difficult news: we’re unable to remove the current resource restrictions. This isn’t specific to your company; it’s due to the broader impact such a change would have on the entire system and all customers.
Removing these limits from your company’s database would require us to remove them for every company using this shared server. That would allow any company to consume resources without constraint, very quickly leading to server overloads and failures. In those conditions, the server can’t remain stable or responsive, which would negatively affect all clients—including you.
Right now, several clients share the same server you are on:
Some run well-optimized reports and queries that filter data down to a manageable number of rows.
Others run very complex queries directly in production, often without prior testing, significantly increasing the load.
And there are additional clients whose usage, while more moderate, still contributes to overall server strain.
To keep things fair and stable for everyone, we enforce resource constraints so each client can reliably access their fair share of server capacity. These constraints are essential not only when the SQL instance is under contention, but also for maintaining consistent quality of service across a diverse client base with very different usage patterns.
You’re absolutely right that this is not a data or environmental issue on your side. The key difference between the pilot and production environments is scale. The pilot environment has far fewer users and much lower traffic, so it doesn’t require the same constraints. Pilot typically runs at only about 35–45% of the traffic we see in production.
In theory, removing all constraints might seem beneficial, but in practice, the server becomes overwhelmed within 15–20 minutes. We’ve seen CPU utilization spike to 99% in that timeframe, leaving the server completely unresponsive. That data is what drives our need to keep the current resource constraints in place.
I recognize this isn’t the outcome you were hoping for, and I know that running your report in smaller chunks is not ideal. For example, processing 10 warehouses at a time or running for one week at a time across all 30 warehouses—and then applying your mathematical and statistical calculations—adds extra steps.
That said, this approach helps ensure the reports complete successfully rather than fail outright due to server overload. To make this as practical as possible, here’s a recommended workflow:
Narrow the report parameters into smaller segments, either by date range (e.g., one week at a time) or by warehouse groupings (e.g., 10 warehouses at a time).
Run each segment separately, keeping each query within the resource constraints so it can complete reliably.
Combine and refine the results from those smaller runs to create your full consolidated report.
For clients who truly cannot operate effectively within these shared-resource constraints, we do offer an Enterprise Cloud option. This provides you with a dedicated server, not shared with other clients. In that environment, we don’t need to apply the same resource restrictions because your usage alone determines how the server’s resources are consumed.
If you try the smaller-batch approach and the report is still failing—or if it’s simply not feasible for your business process—please reach back out. I’m more than happy to:
Please take a closer look at the specific report, identify potential optimizations, and work with you on changes that can help it run faster and use fewer resources.
I truly appreciate your understanding and patience as we work within these technical limits. Please let me know how your next set of runs goes, and we can continue to refine things together if needed.
We just had a hiccup…roughly 30m in duration, before the bulk of our staff came in.
Program Ice.Services.Lib.RunTask when executing task 2698811 raised an unexpected exception with the following message: RunTask:
Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
—> System.ComponentModel.Win32Exception (64): The specified network name is no longer available.
Posted same error text in a different thread as others are reporting what appears to be network-related issues this morning.
@aosemwengie1, it may be time to move back on prem for you or in your own private cloud. What does management think? I feel like you have done everything you can to adapt and move, but the implications of the cloud are much more severe than maybe anticipated?
Not sure how related my thing is but I have packing slips that are taking hours to print, that post is crazy. I can’t wait to switch to my own cloud server, hopefully this gets resolved soon.
Would you be willing to connect at some point to talk roll manufacturing?
Sure! How can I best reach out to you?
Beyond the response… This actually tracks with a lot of issues we have been seeing. It seems like a lot of issues have been coming from them trying to simultaneously share all resources and constrain them at the same time. Does anyone see a way forward from here besides moving away from their SaaS?
I mean that reads to me like, “if you can’t live with this, you’ll have to find another alternative” in a respectful way of course. You can talk to your CAM about other SaaS options where resource constraints don’t exist or are higher… I do believe they have an option for this.
Its not legitimate to constrain resources to the point that basic, core functionality breaks.
I agree @aosemwengie1, but it sounds like this is the level of service/performance they have deemed proper for the make, move, and sell economy. That’s why I’m asking how much longer you’re going to give this a go. It’s not for a lack of effort I can definitely see that. You’ve championed cloud for many years.
That’s absurd on its face. Which inventory-holding company does not need a year end stock status report of all inventory on hand?
If you consume any Epicor marketing materials around cloud, they are selling an elastic, scalable solution, with no transaction limits, no database size limits, that is supposed to scale to whatever load you place on it. That is the promise, not the reality.
Imagine if the marketing team went around telling people, yeah our solution scales but if you add too many parts (we won’t tell you exactly how many), you will no longer be able to generate a stock status report. How many people would move to the cloud then?
I see what you are saying and I was thinking the same. That’s an unfortunate reality but I think they have turned the dial too far towards cost savings.
Don, I am pretty sure they have other SaaS options where you have dedicated runway to consume as much memory and compute as our hearts desire though right?
Alisa, that’s what gets me though. They have different offerings, right? Are all the cloud options the same shared resources?
The question is irrelevant. They are charging for a service that they aren’t providing, and trying to gaslight customers into accepting the shortfall.
Epicor confirmed this morning’s printing issue was on their side.
We apologize for the inconvenience caused. Upon reviewing the logs at the mentioned time of incident, we identified an alert in SolarWinds indicating a disconnection of the SSRS service, which led to the issue. To resolve this, we restarted the service, and after the restart, the servers are now back online and functioning normally.
Alisa, I see where you’re coming from. I would be disappointed as well, especially given how much effort you and your team have put into testing, being on advisory boards, adapting, overcoming, etc., but what you just said says it all… “they aren’t providing the service you expected”. So why stay on any longer? You have a well-documented list of shortcomings, a system that doesn’t fit your operation, etc. Can you use that to end the contract and move on to hosting it yourself until you see the improvements you wish to see?
I know you know, but I’ll say it just to say it. Vantage 8 to Epicor 9, 9 to 10, etc. they all took years to get “right”. I don’t know what “right” is for everyone that uses Epicor, but I have seen how much you have put into what “right” looks like for you and maybe it’s time to switch back. I do feel like Epicor will be able to provide a system that is “right” for more and more people in the coming years, but yeah, right now I think it’s moving through the paces of another large shift, larger than any of the version changes above, and unfortunately burdening the make, move, sell customer base with ERP issues they never would have imagined when listening to the value propositions of moving to the cloud. I do believe Epicor wants to deliver on the value props and in many ways, they are… just not all of them.
In any case I appreciate everything you have done to try and catch bugs, get answers, and move the product forward for us users, truly.
Not that its up to me, but the reason is because Epicor locks you into the cloud. You can’t leave without spending thousands or hundreds of thousands of dollars to buy back the licenses you have already been paying for every month the whole time you have been on cloud.
You manage to get in front of a lot of the people needed to resolve issues that seem too big to resolve. I know this subject matter (contracts and business negotiations) may not be something we have much experience in, but maybe there’s a way to find the right people to have these conversations and figure that out without sinking the ship.