When I go to networking events recently there is a conversation that I hear quite often, especially from the conference newbies. It is “We haven’t upgraded since 2019, I hear it is going to be a hard change going from 32-64 bit” Then the conversation turns into if they should replace the system or press on. What I want to discuss here is how organizational operating culture can impact how we perceive and handle this frame of mind.

 

I have been around enough of these conversations now to notice something. JD Edwards itself is almost never the real problem.

 

The operating model around it usually is.

 

JD Edwards, when it is used the way it was designed, is still incredibly good at what it does. Financially it is solid. Transactionally it is reliable. It handles manufacturing and distribution complexity better than most systems people would consider “modern.” Most companies are not struggling because JDE cannot do the work.

 

They are struggling because over time the business stopped working through it.

 

Processes move into spreadsheets because it feels faster in the moment. A customization gets added to solve something urgent. Reporting gets rebuilt somewhere else because nobody wants to touch the existing logic. Ownership slowly gets split between IT and the business and nobody really owns how the system evolves anymore.

 

None of this happens because someone made a bad decision. It happens because people are trying to get their jobs done.

I sometimes joke that these are survival decisions. They make sense at the time. The problem is they stack up. Five years later nobody remembers why something exists, but everyone agrees it is too risky to change.

 

That is usually when JDE starts getting labeled as heavy or slow.

 

In reality, the system did not change. The layers around it did.

 

And to be fair to JD Edwards, it is very good at letting companies run for a long time without forcing change. That is part of why companies stay on it for decades. The downside is that drift can go unnoticed for a long time too.

 

At some point the business starts operating around JD Edwards instead of through it. That is when you start hearing “JDE can’t do this.” Most of the time it can. The business just stopped asking it to.

 

This is usually where the conversation turns toward standardization, and that word makes people uncomfortable pretty quickly.

 

“Going Vanilla” gets interpreted as a cleanup effort or an admission that something was done wrong. That is not how I see it, and honestly it is not how it works in real environments anyway.

Customizations existed for a reason. They solved real problems when they were built. The problem is not that they exist. The problem is that businesses rarely go back and ask whether they still need them.

 

I talked about this more in a previous article, Going Vanilla in JD Edwards Without Breaking the Business, because the goal is not to remove everything custom. The goal is to remove friction where the platform has caught up or where the business itself has changed.

 

The companies that handle this well do not announce a big initiative. They just start asking better questions when work gets revisited. If we were doing this today for the first time, would we build it this way? Sometimes the answer is yes. A lot of times it is not.

 

And every time something moves back toward standard functionality, things get easier. Upgrades stop being scary. Integrations get simpler. The system feels lighter without anyone really noticing why.

 

Another big change over the last several years is that extending JD Edwards no longer requires modifying JD Edwards.

That used to be the only option. If you wanted something different, you changed the system and accepted that you were going to deal with it later. Tools like Orchestrations changed that equation quite a bit.

 

What I like about Orchestrations is not that they are new or technical. It is that they let companies solve problems without creating future ones. You automate around the standard transaction instead of replacing it. You remove manual steps instead of building new ones. Data moves where it needs to go without someone exporting it at 4:30 on a Friday.

 

And it is not just Orchestrations. Logic Extensions have changed the game in a similar way. Being able to write logic in a UDO that functions very much like an NER, using syntax that feels familiar to anyone who has written Event Rules, allows you to extend behavior without cracking open the core. That is a big deal. You can apply conditional logic, enforce rules, shape behavior, and still stay within a supported model. It raises the ceiling of what you can do without adding another “mod monster” to clean up later.

 

The result is not just automation. It is stability. And stability is what keeps JD Edwards viable long term.

 

The part that nobody really likes talking about is that none of this is driven by technology alone. It is operating discipline.

 

The environments that age well are not the ones with the biggest projects or the newest tools. They are the ones where someone is paying attention consistently. Small improvements happen. Processes get revisited. Workarounds get questioned instead of accepted forever.

 

Most organizations only improve their ERP environment when something forces them to. An upgrade. An acquisition. A reporting problem that finally becomes too painful to ignore. Then things settle down again and the cycle repeats.

 

That is where the drift starts over.

 

This is why I tend to think less in terms of projects and more in terms of operating models and operating culture. JD Edwards works best when it is treated as a core system that evolves with the business instead of something that only gets attention during major initiatives.

 

I have experienced JD Edwards being called a legacy system for my whole career and in most cases that label says more about how it is being used than about the software itself, because JDE is an AMAZING system! When companies simplify how they operate around it and develop that operating culture that leans into system self reflection, the conversation changes. Replacement stops being the default answer. The system becomes something you can actually build on again.

 

And honestly, that is what good ERP systems are supposed to do. Quietly hold things together while the business moves forward.

– Justen Geiger

Hey everyone! We really hope you enjoyed this blog by Justen Geiger.

At J.Geiger Consulting, we take great pride in delivering the best in everything we do, especially when it comes to JD Edwards insight, strategy, and real-world experience. If you have feedback or a topic you’d like Justen’s thoughts on next, please send us a note through our contact form, we’d love to hear from you.

And if you enjoyed this content, be sure to check out our JDE News page for one of the most robust collections of JD Edwards updates, insights, and commentary available.