What Manufacturers Should Audit Before Upgrading JD Edwards

A manufacturer preparing for significant growth recently took a closer look at how its teams were using JD Edwards. The company had JD Edwards in place, but many critical processes were still happening outside the system. Accounting teams relied heavily on spreadsheets, engineering processes involved significant manual work, reporting was difficult, and some users had access to areas of the system they didn't necessarily need.

Those inefficiencies were already creating challenges, but growth raised the stakes. The manufacturer was preparing to expand its operations with an additional plant, which meant adding new users, establishing master data, configuring security, and replicating business processes at a much larger scale. Carrying existing problems into the new operation could make them even harder—and more expensive—to address later.

The assessment revealed an important lesson for any manufacturer considering a JD Edwards upgrade: upgrading the software doesn't automatically fix the way you're using it.

Before moving to a newer release, manufacturers need to understand what they're carrying forward. That means looking beyond Application and Tools Releases to evaluate business processes, supporting technology, security, customizations, data, and opportunities to modernize.

Here are six areas manufacturers should audit before upgrading JD Edwards—and what this manufacturer's experience can teach you about each one.

Audit How Your Business Processes Use JD Edwards

One of the first priorities in the manufacturer's assessment was understanding how work actually moved through the business.

JD Edwards users walked through their processes from beginning to end. This showed where JD Edwards was being used, where work was happening outside the system, and where gaps had developed. Some employees brought spreadsheets they relied on, while others demonstrated their processes directly in JD Edwards.

Manufacturers should look for similar gaps:

Technology is only one part of an upgrade assessment but understanding everything that supports JD Edwards is critical.

For manufacturers preparing to upgrade, that means reviewing the Application and Tools Releases alongside operating systems, databases, WebLogic, Java, middleware, AIS, Enterprise Servers, Deployment Servers, and other supporting components.

But the technology audit shouldn't stop with Oracle.

Manufacturers may rely on third-party applications for warehouse operations, shipping, EDI, reporting, data capture, and other processes connected to JD Edwards. Those vendors need to confirm that their products will work with the target JD Edwards release and whether their own software needs to be upgraded.

These dependencies can be especially important in manufacturing because a compatibility problem may affect more than ERP users. It can disrupt the systems supporting day-to-day operations.

The lesson is simple: don't assume that because JD Edwards is ready to upgrade, everything connected to it is ready too.

Review Security and Access

Security was already a concern for the manufacturer in this assessment. Some users had access to areas of JD Edwards that didn't align with their responsibilities, creating unnecessary exposure as the organization prepared to grow.

Expansion could compound that problem. Adding another facility means adding users, assigning roles, establishing security, and determining which responsibilities will remain centralized and which will belong to the new operation. Starting with an inconsistent security model only makes that work more difficult.

Before upgrading, manufacturers should review:

• User roles and permissions
• Role-based security
• Authentication
• Separation of duties
• Compliance requirements

Pay particular attention to permissions that may have accumulated as employees changed roles or took on new responsibilities.

The question isn't only whether your existing security configuration is compatible with the upgraded system. It's whether that configuration still reflects who should have access to what.

Inventory Your JD Edwards Customizations

• Custom and cloned objects
• Modified Oracle objects
• Event Rules
• Business Functions
• Business Views
• Custom reports
• Other custom code

But identifying what exists is only the first step.

For each customization, ask whether the business still needs it. A modification created years ago may support a process that has since changed, or newer JD Edwards functionality may now provide another way to accomplish the same task.

That creates an important decision during the audit: does this customization still deserve a place in your JD Edwards system?

Anything that remains may add retrofit, maintenance, and testing effort to the project. Understanding that effort early gives manufacturers a much more realistic picture of project scope.

Evaluate Your Data Strategy

Historical data presents a different question: how much data of it needs to remain in your production JD Edwards system after the upgrade?

Consider a manufacturer that has accumulated 15 years of transactional history. The organization should determine how much needs to remain in production and how much could be archived. Compliance or audit requirements may dictate how long certain records must be retained, but retention doesn't necessarily mean every record needs to remain in the active production database.

Manufacturers should review:

• Data retention requirements
• Historical transaction volumes
• Archive and purge policies
• Database growth
• Reporting and system performance

The amount of transactional history maintained in production can affect system and reporting performance. An archive strategy can preserve access to required historical information without continuing to add unnecessary volume to the production database.

The audit should determine what needs to remain readily available, what can be retained elsewhere, and what data strategy makes sense for the upgraded system.

Identify Modernization Opportunities

Perhaps the biggest lesson from this manufacturer's assessment was that upgrading JD Edwards alone wouldn't address every problem the organization was experiencing.

One example was inventory receiving. Material was being received without an efficient way to capture transactions as they happened. In some cases, the transaction wasn't recorded until a day or two later—after the material was already being used on the shop floor. That delay contributed to downstream inventory problems and made reconciliation more difficult for Finance.

The situation became even more important because the manufacturer was preparing to add another facility. Replicating the same manual process at a second plant risked multiplying the problem rather than solving it.

That's where the audit should shift from asking "What do we need to upgrade?" to "What should we do differently?"

Manufacturers that haven't upgraded in several years may have access to JD Edwards functionality that wasn't available when their existing processes were designed. They may also be licensed for capabilities they simply aren't using. The assessment should identify whether newer functionality, including Orchestrator and other modern JD Edwards capabilities, could address some of the gaps uncovered earlier.

Not every improvement needs to become part of the upgrade project. Some may belong on a longer-term roadmap.

The purpose of identifying these opportunities isn't to make the upgrade bigger. It's to understand where newer JD Edwards capabilities could eliminate unnecessary manual work and give the business a roadmap for what to address next.

Don't Forget Testing Readiness

Testing readiness is another area worth checking early.

Organizations don't always have established test scripts available when an upgrade begins, which means those scripts may need to be created as part of the project.

Testing deserves a deeper discussion of its own, but manufacturers should at least determine whether test scripts exist, which critical processes and integrations need validation, who will participate, and whether enough documentation exists to support user acceptance testing.

Knowing that early makes it much easier to account for the testing effort in the project plan.

Final Thoughts: What Manufacturers Can Learn from This Assessment

What makes this manufacturer's situation useful isn't one unusual JD Edwards problem. It's that there wasn't just one problem.

Manual processes, spreadsheets, security concerns, underused functionality, and plans for significant growth were all interacting with one another. Adding another facility or moving to newer technology without understanding those issues first risked bringing them into the next phase of the business.

That's the real purpose of a pre-upgrade audit.

For manufacturers, the question shouldn't simply be, "Are we ready to upgrade JD Edwards?" It should also be, "What are we about to carry forward?"

Some things should move to the upgraded system exactly as they are. Others need to be cleaned up, retired, redesigned, or placed on a future modernization roadmap. Knowing the difference gives you a much clearer picture of the project's true scope and the work that needs to happen next.

At ERP Suites, that's the broader perspective we bring to JD Edwards readiness assessments: understand how the system supports the business today, identify what could create risk tomorrow, and use those findings to build a more informed path forward.