Separate the Wheat from the Chaff When Upgrading EBS

Farmers know which tools to use and how to use them to get the job done, whether they are planting, harvesting, herding or threshing. It’s part of how they ensure they do what they must, when they have to do it, because, as the agronomist Norman Borlaug said, “Everything else can wait, agriculture can’t.”

You’d do well to apply the same attitude to managing your ERP transformation initiatives, as many teams nowadays are facing mandated Oracle EBS upgrades with short timelines. But it is a mistake to assume that you have the right tools just because you got them from Oracle.

Their free 12.2 Readiness scripts are, in fact, designed to identify many of the technical issues you will encounter in an upgrade, especially around your customizations. However, Oracle did not tell you that their free tools only cover about 40% of your customizations.

If you were a farmer, would you use a harvester that could only plow 40% of your field?

This is due to the fact that Oracle Readiness scripts examine customizations within the database, like packages, functions and views. But most of your code is deployed outside of the database, in forms, reports, framework pages, host scripts and more.

Your developers should not have to settle for this unacceptable coverage. It translates into hundreds of hours of manual code analysis, plus extended project burn time.

Moreover, the more customized your EBS implementation is, the longer it will take to upgrade, potentially affecting critical business processes. You need to be able to accurately identify all custom objects, and remove from the scope anything that will slow you down, such as irrelevant objects, unused solutions and unnecessary customizations.

As Mahatma Gandhi said, “Weeding is as necessary to agriculture as sowing.”

In short, you need to make sure your team has the right automation tools to analyze all of your customizations. Unfortunately, the Oracle tools will leave more than half your field unplowed.