by Ryan McBride
JD Edwards EnterpriseOne version 9.2 was originally released some 6 years ago. Since that time, each and every year, Oracle has released an Update to their 9.2 code base. Update 5 was released late last year and included in that (very large) release, the accumulated changes for 2020 and all preceding ESUs and Updates of E1 9.2.
For the sake of argument, let’s assume you weren’t the earliest of adopters and when you went live with 9.2 and everything included through Update 2. Since that point you have only taken limited and specific bug fix ESUs required to keep your system up and running as expected. Let’s assume there is new functionality your business wants to deploy and the decision has been made to go “code-current” and take U5 to unlock these new features.
Pop quiz: How do you figure out how much it’ll cost to retrofit your custom footprint to take this update?
Is it safe to say that the costs associated with your previous major release-level upgrade from 9.1 to 9.2 is a good place to start when thinking about retrofitting costs (assuming you haven’t done much additional customization in the meantime) for this update? No not really. Apples and oranges actually. Let me explain.
For a RELEASE-LEVEL UPGRADE, say from 9.1 to 9.2, you need to “touch” every one of your custom/modified objects and make sure they will work with the new underlying code base. Some objects will take a quick 15 minutes to verify they are compatible while other more heavily modified objects could take hours or even weeks to retrofit. Again, during an upgrade, every single object that makes up your modified footprint will need some level of attention.
Conversely, for a CODE-CURRENT UPDATE, say from 9.2U2 to 9.2U5, you only need to “touch” objects that are directly or indirectly impacted by the net new code being deployed. To clarify, as the entire underlying code base is not changing, you only need to look for specific areas of the code that have changed, mash that up against your modified footprint and isolate the “impacted” objects.
Good news, right? Even if it has been multiple update cycles, the retrofit might not be as bad as you thought or as expensive as you remember.
Not so fast. There are definite trade-offs and distinctly different considerations when solving for these two problems. The overall retrofitting workload might be less when executing a code-current update, however, the front-end analysis work is a significantly more complex. I’ll break it down further:
During a RELEASE-LEVEL UPGRADE, the flow goes something like this:
- Identify modified objects.
- Evaluate the need and utility of modified objects in the new version.
- Scuttle unnecessary objects.
- Retrofit and test remaining objects.
During a CODE-CURRENT UPDATE, the flow goes something like this:
- Identify modified objects.
- Evaluate the ongoing need and utility of modified objects.
- Ignore/retire/scuttle unnecessary objects.
- Establish a list of objects to evaluate for potential impact.
- Establish a “line-in-the-sand” code level you will be updating to (Update 5 or Update 5 + ESUs since U5 release).
- Technically analyze/compare the optimum object list to the agreed target code level.
- Identify objects that are directly impacted by the updated code.
- Identify secondary and tertiary impacted objects.
- Retrofit and test impacted objects
To recap, the retrofitting during a CODE-CURRENT UPDATE will likely be significantly less than the retrofitting associated with a RELEASE-LEVEL UPGRADE. Unfortunately, the front-end analysis is a bit more complex when this work is performed manually using standard tools. As fate would have it, and if I do say so myself, DWS is arguably the leader when it comes to advanced tools and talent geared specifically to help companies manage and maintain their modified E1 footprints.
If you need some help, give me a call or ping me on LinkedIn.
Cheers and Happy New Year!
