It’s not just about adding more heads, its about adding more SME’s. Epicor is vast, its complex, and dismissing it and thinking one can just hire 100 help desk staff, is the worst thing one can do.
Not everyone has the tenure of @aidacra and its not something you learn overnight. It will be interesting to see how they scale that up. I always put in the reference field “SEND_TO_NATHAN” but they ignore it 
Even if you get through (or skip) Tier 1, that doesn’t make development any faster.
I think this is probably one of my bigger, overall issues right now, the amount of PRBs that we see that are set to be resolved in 6-18 months out while we just kind of have to site there and tell our users:
Not trying to complain here- these are real problems, real things happening… can’t deny that. That’s why it’s so hard to sit there and say to our users, “this is innovation”. You like this right? It’s helping you in your everyday work, right? I feel like with the change to Kinetic, there should be focus groups for every screen… So that we can learn from the users using those screens. Don’t know how many of us are on focus groups, but Epicor does really well with the ones that I’ve been fortunate to be in… I just wonder if doing this for each form would be beneficial and lead to better quality, stability, and improvements that the users actually want to see.
I got an email from EPICOR today (Did anyone else? It seems that it came from people based in the US) but i dont know if it was because of them responding to On-Prem users that have voiced concerns in this thread OR it is because i have contacted my CAM and Sales Director about Cloud and our pathway if we were to take it (Were supposed to come back with some times for a call). I have reached out again to my CAM and SD but seem to be out of the office.
Nothing here.
Nothing from them for me either
They had a class on .NET Reflector sometime at Insights 2012.
A blast from the past!
More specific? I got a couple (in quarantine 
) with this subject:
Last Chance to Register! Back to Basics - Mastering Product Groups, Part Classes, and GL Controls
But otherwise, no, nothing new.
Tim hosted it, I tuned in for that and just to make sure nothing new came out or that I didn’t miss something from the past.
Man, you get them to listen?! I do that and they still ignore me. And no, I don’t know why I keep going back to them anyway.
Yes!
This is my feeling with financial bugs. Finance is basically a black box until someone combs through the hundreds or thousands of pages in the Inventory/WIP Reconciliation Report, if they do. The only people with the knowhow to dig through the PE Log Viewer ARE the power users, even if they are not specifically IT people. (Though I imagine it’s likely.)
Not an on-prem point I am making, but just for the grander point that Support seems to be bred to ignore the future.
Also the other point in this thread 
is that I blame “Support,” but that’s metonymy. It’s the Support-Dev-Ideas industrial complex. Support and Ideas are the gatekeepers to dev, and sometimes they just will not pass on your (proven) concerns to dev, or if they do, then dev sits on it.
Saw you there… hope it was somewhat useful for an experienced person like you.
It was a good review as we’re gearing up for integrating our new acquisition into Epicor this year.
Always is, I am exploring sales category right now. I wish that there was a sales category on the part so that it would default on the orderinvoice.
– WARNING: LONG RANT –
I came here shortly after receiving the email last week but was letting things develop first before chiming in.
First, a bit of background on my company:
We’re a small-to-medium manufacturing company that sells a highly customized product and operates in two countries. Almost all our sales are engineer-to-order/make-to-order; as such, we have generated tens of thousands of different parts and specifications. We have an extensive machine shop with all kinds of CNC machines of all ages.
When I joined, we were using an old version of Infor Visual (4.52, I believe) that was already out of support, but everything was working well enough. In the first few years, the time taken to create and maintain old BOMs led us to look at product configurator software. We ended up engaging a consulting company that helped us implement our choice (BuyDesign, which ironically was bought out by Infor later on) and integrate it with Visual. Eventually, though, Visual proved unable to meet evolving needs that required customization, so we started looking for another ERP.
In the end, we made our choice between Epicor 10 and Microsoft Dynamics. The decision was mostly decided by the .NET stack and customization capabilities. With some partner assistance, we implemented the migration to Epicor in under a year, including integration with our existing configurator. It has now been 10 years and we’ve implemented many more customizations to meet business needs, including transitioning to the Epicor Product Configurator. We have done this by creating most of the logic in our own .NET project and mostly using the Epicor PC as a glorified interface to create orders, parts, and jobs. The BOM calculations are done by our code. This was done to give us more flexibility, as we wanted to also have versions of the configurator for other platforms, like our website.
So, as you can see, we’re a very customized outfit, and even though the company is fairly small with around 150 total employees, we have a capable IT team that can develop the solutions we need. We’ve lately been moving more of our code from Epicor to external APIs to allow for easier integration and what was going to be the uplift to Kinetic. We virtualized our environment before “cloud” was really a thing. Our company is very cost-sensitive and we prefer to own and maintain our environments. Over the years, exploration of cloud options always came back as much more costly than using our internal resources.
So that brings us to now, where continuing with our current ERP may introduce a forced migration to the cloud. Here are what, in my view, are the biggest detriments to going this way for us:
Cost
Maintenance costs are already fairly hefty, and it feels like all new features being added are even more costly. Not only do we have to think about the cost of running the ERP, we also have to think about the cost of all the changes we’d have to do to even be able to go that route. If this was a new implementation, you would prepare everything that way; but changing everything now takes a lot of time and money that would be better spent in other ways.
Support
When we first started using Epicor, we had a non-negligible amount of issues, many of them related to Multi-Company. At the time, when I needed assistance, creating a ticket would result in a remote desktop meeting in short order, and the issues were resolved fairly quickly.
Over the years, it has gone downhill and is now dogshit. Any ticket takes a while to be responded to in the first place, then becomes a string of emails back and forth with Excel sheets of requested data. If you’re lucky, it may get resolved. If not, eventually they may finally agree to do a remote session to figure it out. If you’re still not lucky (and you’re often not lucky because these support people don’t have much knowledge), then you have to upload your database, wait days for it to be loaded, then go back to the same string of emails back and forth.
It is almost impossible to get someone knowledgeable from the start, which would cut down the time from ticket to fix immensely. There should be no need for you to go to Insights and get chummy with developers to receive decent support.
I’ll give the example of my worst experience so far. This is long, so you may want to skip this, but it’s completely ludicrous how it happened. I had a user report an issue with alternate parts and attachments in jobs. We didn’t use alternate parts before, so it was something new to us. Support came back and requested me to make a video of the issue, which I added. They asked if the problem exists on the latest version (we’re a year or two behind at this point). I got a new instance up on the latest version and it’s still there. A remote session was scheduled where I was asked to show the issue. I’m not sure why, because I already provided a video, but we still went through it. The case got escalated, a supervisor came in, and we did another remote session, again asking to see the issue. I showed them the issue yet again. Months went by and I tried to get some feedback. The initial person scheduled a session and asked to see the issue. I denied it and tried to escalate. The same supervisor came in, remembered nothing about the case, and tried to get me to show the issue again. I put my foot down; they had a video of the issue and I had already shown it to them. They said they were going to go back and go through the previous session to find out where to go from here. Why the hell did they not go through it before the meeting? Eventually, they had to send it to devs or something. Eventually, the first support person came back and said that the issue doesn’t happen on the latest version. I again spun up a new environment and verified that it does still indeed happen. I go a bit scorched earth at this point, reply back, and involve my CAM. Someone else takes over, and within a week or two, I get confirmation that they finally do see the issue and created a PRB for it. It is now slated for 2026.1. This whole saga took around a year to go through, with months in between where I’d hear nothing until I pinged the ticket again. WTF.
Epicor lock-in
One thing I haven’t really noticed too many people discussing, though @banderson touched on it a bit, is the lack of agency and ability to plan something stable. If we move over, what happens if Epicor yet again makes another turn that invalidates us or requires a lot of cost and effort that we cannot absorb? What if Epicor itself disappears? Software companies do not last forever, and while Epicor is probably big enough that it will not happen, what’s the failsafe plan? If Epicor is suddenly gone and servers are shut down, how do we run the business? On-prem, we can just keep going as-is without support. Yes, there are risks to continuing this way, but you have time to figure it out. ERP is not like other software that may be easy to transition. If you can’t use AutoCAD, you can change to a different CAD program; there’s support for different formats. If Exchange Online is gone, you can move to Gmail. ERP is much more integral to how you run your business, and it takes months or years to migrate.
Another question that comes to me is why did Epicor not iron out the details of this plan ahead of time? From what I’ve read above, it seems like partners were not informed and plans were not made for alternatives for their hosting. It’s like they tossed out this grenade and are waiting for the fallout to settle to figure out the best way for them to come out ahead.
The excuse that it’s to simplify delivery and not needing to support downloadables for on-premise is very flimsy. In the first place, Kinetic is not a cloud-first product. And the cloud isn’t any magical fairy dust; it’s still server hardware, which we, too, can purchase and maintain. Of course, that requires us to do that, but we don’t need to be able to spin up and down VMs due to usage. An on-premise environment will at worst be as complex as the cloud that we’re discussing, but in our case, it’s much simpler. We don’t need multiple app servers for an environment. We have one VM for production and one for other environments. We don’t need load balancers. The maintenance required for the most part is just regular updates, upgrading the OS/SQL/frameworks as demands require, but that is once or twice a year.
The discussion about containers above was interesting, but again, nothing prevents us from using those. Running Docker on a server, downloading containers, setting up configuration files, and so on is not extraordinary. We’re using it for other purposes. While many companies would not have someone who has the technical skills to do so, they’re probably also not the ones that would need the customized environment that we’re discussing. For them, the cloud may be a good solution, especially if the company is designed from the beginning to be cloud-first. Those like us that do require the customization will find resources, either by hiring personnel or consultants to do it.
My last point, as this has become way too long, is the decision we have to make. We’ve had Epicor for 10 years, so we’re used to it by now. We don’t want to switch ERPs, but if the effort to continue with Epicor is a significant percentage of the effort for a full implementation with a new ERP, we have to evaluate other options to see if Epicor is still the one that fits us the best. We haven’t migrated to the Kinetic screens due to all the work involved yet, and the change to the new interface. If at the same time we have to do it for the cloud as well, we can maybe go the extra length and switch ERPs. In my view, Epicor has decided that their revenue will be higher by dropping some of us, and that inspires no confidence that they’re keeping the customers’ best interests in mind.
Thoughtful post. Thanks for sharing.
We too are in a similar boat as you as a small MFG that is 100% dependent on the PC and our 10k lines of logic behind it. I agree with your post and find myself thinking that we should build our own industry specific PC to decouple ourselves from Epicor and explore ERP options that have a robust API for all we want to do.
If you make it to Nashville, we should meet up and talk PC stuff over a few beers.
We are heavily dependent on the PC to. In the same boat as you and @MikeGross with thousands of lines of custom logic.
We’ve got a few pretty simple PCs so my hats are off to you guys with complex ones. PC makes my 
I think the new theme of software is going to have to be decoupling from any specific software as much as possible because you can’t depend on a stable landscape anymore. You need to be able to change quickly. Whether it be configurator, portals, ERP, project manager, anything. The days of building on a central platform are over because there aren’t stable platforms anymore.