I remember on-prem SAP in my EDI days. 
Damn, I’m old.
But if you read what they are doing and why, the reasoning is the same.
Restricting cloud customers is not the answer. That is bait and switch - the promise when going to cloud is that it was the same product just hosted by epicor. This whole thing is like bait and switch. Collectively thousands (hundreds of thousands?) of development hours have been invested in this framework. No restrictions should be implemented without AT LEAST 2 years advance notice and a clear instruction as to the alternative. Cloud customers are locked into the upgrade cycle and there are critical business procedures that rely on existing custom code base. Breaking it is completely unacceptable. What will it take to get Epicor to reconsider this path?
An exodus.
But in all seriousness, in an effort to remain constructive and not turn this into a 
, I am taking the time to write up an article with some things Epicor could do to make this transition better. Not a complaint fest, but something I hope they will take to heart. I don’t think they plan to reconsider, for better or worse. I also don’t think they have really considered what all this will affect, and how this figures in to the broader issues facing Epicor devs, and by extension, customers.
It may not be as extensive as @MikeGross 's group idea about the email and communication revamp, but something along those lines. There is a disconnect between devs and Epicor, and we need to bridge it.
This is my concern. The business LITERALLY will not run if these changes go into effect. The fact that no dates have been announced and no alternatives are clear is terrifying. We are already very busy with ongoing business priorities. If it turns out that a substantial amount of code has to be rewritten, or business processes have to be changed because Epicor has decided to no longer support these types of customizations, that is a years long path to business change and has to be worked into budgets and timelines. It simply cannot happen overnight. And an exodus isn’t an option, cloud customers are locked into 5 year+ long contracts. It would take a lot of money and/or lawsuits to change paths at this point. Even on premise customers, you can’t just change ERP systems overnight.
Surely you can’t have that much code that this will affect?
It doesn’t matter if what the code does simply cannot be done anymore due to the restrictions? Then its back to the drawing board to change the way the business operates? I honestly have no idea how many things are affected, just even reviewing everything and analyzing that is a project in and of itself. One that I have no time for given we are still working to transition from classic to kinetic.
I mean, you know me and what I do, and I think I have workarounds for most of this for business critical code. I’m sure we can all help each other figure it out.
As unhappy as I am about this, they are going to provide us with some tooling to ease the transition.
Love this
I have little confidence in that. But hey here’s hoping it won’t be a dumpster fire.
I was thinking about this one last night. I think the built in tooling that exists now should at least be able to be used to identify the problems. (As warnings)
The individual items will have to be looked at manually obviously.
As far as I have seen, the one tool they give us (configuration upgrade dashboard) doesn’t even look at functions. Which is where most of the code is or is going. And even for BPMs, it does not show the warning on the dashboard even when you get the warning when compiling it.
If that is the case, I’ll make a dashboard that does when I have time, if someone doesn’t beat me to it.
Nope definitely not what I was suggesting, just a way for controls to be put in place If you were cloud could not be changed by cloud customers, and if you enable it on prem you would get the same bahavior as if you were on cloud… Behaviour being enable/disable compiler warnings and code exclusions.
Hey @Mark, what about Serilog? What capability do cloud customers have with that?
What about the Upgrade Analyser, does that work with cloud? That would go a long way in identifying the work required to make changes if it had more detail about our compiler warnings.
My thoughts that Epicor should be able to use that tool as a means of analysing, (they probably are already) identifying and informing customers, of the issues, call it more of a best practice analyser than an upgrade one.
I do agree there needs to be a practical notice period. It is not practical to expect to stop all your ongoing development and circle back to reactor old. You have limited resources, and the business is relying on new functionality to be built , QAd and deployed in a given time frame., with other business resources/plans scheduled and dependent …Even with contingencies considered.
Sort of like driving down the highway and the person in front switches lanes, then halfway across they change their mind… Wildly pulling on the steering wheel in the opposite direction . Never really ends that well…
Unpredictable events are never good for business, and we all have seen how that goes. I could go on all night, but I’ll leave it with a short close.
As always it best for everyone to keep the lines of communication open, and clearly understand each other’s point of view., and work together on a mutually acceptable solution.
Been meaning for a long time to add it to the customization dashboards…
Again, that is what MT was. 
This. 
Not two codebases, some if statements would be nice
Poor choice of words on my part. Two code bases with IF statements is EXACTLY what MT was.
For us on-prem’s there are simple solutions such as Wrapping the Reflection Class in an External DLL and adding it to our Externals Assemblies folder that the Server loads, basically lets say if Invoke is restricted, make one with a method called Injection. But for cloud folks I am not sure.