by Barry Burke
Best Practice for Upgrading JDE EnterpriseOne
If we look at the typical EnterpriseOne life-cycle there are 3 major phases, the initial implementation phase, the major upgrade phase then the realisation that staying code current might represent a more sensible approach than undertaking major upgrade projects every 5 – 10 years.
In this series of blogs I will be focusing on upgrading your E1 system then staying up to date. These are NOT intended to be deep-dive technical blogs but will introduce you to the key considerations for each topic. The five topics to be addressed in these blogs are:
- Planning your E1 upgrade
- Executing your E1 upgrade
- Planning your E1 upgrade testing
- Managing your E1 testing
- Staying code current
There is a series of Webinars that builds on these blogs. Each blog will include registration details should you wish to join the live events or view a recording if you missed it.
Planning Your E1 Upgrade
In this first blog in the series I will consider:
- Upgrade considerations / questions
- How to reduce your modified footprint
- How to obtain accurate upgrade estimates
I would like to pose the following question. How do you estimate how long your upgrade will take?
For many people it is a bit of a guess, especially when it comes down to estimating uplifting your customizations, extensions and such like from your current release to the new release of E1.
Some aspects of your upgrade are easily quantifiable, such as installing new hardware and setting up new databases. But when it comes to uplifting your custom code, this is notoriously difficult to estimate. How long will it take? What resources will you need etc.?
As you head into the planning phase of your E1 upgrade there are a series of questions you will probably be asking yourselves. Those questions will identify a number of risks for the project.
Firstly, where do my mods exist and how extensive are they? This is pretty fundamental but if you can’t answer this question it can seriously impact the project. Typically, this may be done by running CNC reports. However, the modified flag searched is often turned on unnecessarily, which will result in an overstatement of the number of modified objects in your system. Often this will be by a matter of hundreds, if not thousands.
More dangerous, of course, is if the flag is not set, so you fail to identify modified objects that will need to be uplifted to the new code set. Also important is knowing the extent of the modifications. The more extensive and complex the mods, the longer it will take to uplift the code.
The type of mod is also important. Whether you have created custom code, modified standard code or taken copies of the standard code and modified that.
Knowing that breakdown is important as those different mod types represent different levels of complexity. Copies tend to be the most complex and pure custom the easiest. This is not always the case but is often so.
Looking at Version Overrides; these give you the ability to override versions of any given UBE, things like report logic and layout. These are difficult to identify accurately as there is no flag to indicate where version overrides have been used. So these tend to get parked to one side. And whilst some organizations do not allow overrides as a policy, some actually get shipped out of the box by Oracle, and power users may make copies of these, which in effect creates new version overrides.
The next three questions may be relevant if you have particularly complex modifications, where lack of accurate documentation may cause serious difficulties and where access to the original developers may be helpful. These are: Is my documentation up to date? Is it up to scratch? And do I have access to all the original developers?
What is important though is what proportion of your enhancements are standalone versus calls to standard JDE objects.
As an example you may have two UBEs the same size. One is completely standalone whereas the other makes several calls to JDE objects. In this second case, you need to understand by how much this UBE will be affected by the changes made to the standard JDE objects called by this UBE.
How do you know if the standard JDE objects you call have actually changed or not?
You then need to consider if any mods you made to standard objects will be affected. In a worst case scenario, Oracle may have removed this object completely. So how will that affect you?
You also need to determine whether it is better to keep your copies of standard and test it thoroughly to check if it still works the same or should you recopy and reapply the changes you made to the new release.
There is no absolute right or wrong answer to this. How you decide to upgrade these will depend on how many changes you made to the standard objects and how many changes Oracle made to those same objects.
So we come to the key question. What will your upgrade cost?
Certainly, if you do not have answers to the questions we just discussed this will be a bit like asking how long is a piece of string. Let me first describe how others tend to estimate, then I will explain how DWS does it.
The one-third rule
There was a theory that whatever the effort was required to develop the modified footprint originally, it will take about one third of this effort to upgrade it. But how many people actually understand the true effort and time involved, especially after they will have undergone subsequent changes?
Even if you do have this number, we know that the one-third rule is grossly inaccurate based on the hundreds of systems we have analysed and the hundreds of upgrades we have carried out.
The sample and extrapolate method
The method most people use is the sample and extrapolate method.
This is where the vendor or customer will review a sample of a small, a medium and a large modified piece of code. They will review these samples and extrapolate them across your whole system estimating how many of your mods will fall into each category.
Again this has proven to be a very hit and miss approach that relies on a lot of assumptions about the consistency of the complexity of the modified code. It is very risky to rely on this approach.
It is, however, the best that most people are able to do without the specialist analysis tools that DWS has developed.
The DWS Accurate Analysis Method
So let me explain how DWS estimates upgrade effort.
The DWS approach enables customers to Audit & Scope their E1 upgrades to a level of accuracy unseen before. We analyze every object, every line of code and every spec setting down to pixel movement level of detail. We identify the from/to base net change for every modified object and we identify the net change type and severity of impact against every modified object.
We also identify all those modified objects that are no longer actually in use, so do not need to be upgraded, as that would be a complete waste of time, effort and money.
With this detailed information we can estimate the upgrade effort required for every modified object not just in man days but right down to hours and minutes level of detail.
We call this service DWS Dimension Analyze.
The Proof is in the Pudding
Let us take a look at a few sample case studies. This first one was an upgrade from Xe to 9.1, so a major upgrade. Using Dimension Analyze we were able to identify a fairly large reduction in the modified footprint of 63%, which in turn saved 318 developer days.
In another Xe to 9.1 upgrade we were able to reduce the modified footprint by 51%, saving 165 developer days.
In a third example where the upgrade was smaller, moving from 8.11 to 9.1, we were still able to identify a reduction of 34%, resulting in a saving of 273 developer days.
Using the DWS Dimension Analyze accurate analysis method, DWS is able to offer fixed price and fixed timescale upgrade services.
So to summarise.
When planning your upgrade:
The DWS Dimension Analyze service is used in the planning phase to produce extremely accurate forecasts of the upgrade effort required. It can also reduce your modified footprint by up to 75%, thereby reducing your upgrade effort and costs.
In the subsequent four blogs in this series we will address the execution of your upgrade to explain how you can deliver your upgrades on time, in budget and with minimal defects.
We will then address the challenges of planning the testing of your upgrade and show you how you can minimize your testing effort by focusing on just what needs testing.
In the fourth blog in this series we will show you how you can automate your testing without the need for expensive technical specialists.
Then in the final one we will address the issues involved in staying code current.
If you would like to register for any of the live webinars that support this series of blogs, or to view any of the event recordings, please use the registration links below.
Date Title & Registration
1 January 28th Planning your E1 Upgrade
2 February 11th Executing your E1 upgrade
3 February 24th Planning your E1 Testing
4 March 10th Automating your E1 Testing
5 March 23rd Keeping your E1 code current
