Leveraging Upgrade Investment Effectively

There are many reasons why companies upgrade their existing JD Edwards version. An upgrade may typically include access to a new functionality, facilitation of regulatory compliance, improved performance and eligibility for product support.

Any upgrade has several factors associated with it; support time frames, functional capabilities, technical infrastructure and business needs are some of the key factors. A company may prefer to move to a supported version or upgrade to utilize a new set of features which fulfills its business requirements adequately.

An upgrade can be looked at from three angles:

1. Functional
   • What are the new functionality / features that have become available through the new version?
   • Have any changes been made to the user interface?
   • Does it involve establishing new set-ups or making changes to existing set ups?
   • Are there any training requirements?
   • Are there any testing needs?
     
     
2. Development
   • Does it involve retrofitting?
   • Does it involve new development in addition to retrofitting?
   • Have any changes been made to the development tools?
   • Does it involve training the development team?
     
     
3. Technology
   • Does it involve change (upgrade / new) of hardware?
   • Do any changes need to be made to associated softwares?
   • Are there any new training requirements?

Of these, the technology activities are critical to the success of the upgrade.

Prior to starting the upgrade, it is necessary to evaluate the current hardware as well as software used by the current JD Edwards set up. This is then compared with the Minimum Technical Requirements (MTR) prescribed for the new release. Typically, a hardware sizing exercise by the preferred Hardware vendor (for e.g. IBM, HP, Dell, etc.) is recommended. This helps you arrive at the gaps in the infrastructure that need to be addressed.

The use of latest production environment and production data is recommended in the environments that will be initially upgraded. (This environment will be used for testing). Also, it is vital to ensure that the Minimum Technical Requirements have been validated and met. They should be verified for compliance to avoid future complications. Since the actual upgrade is a predefined technology process that occurs on deployment and enterprise servers, once the environment is upgraded, all the available and recommended ESU s should be applied. It is important that this is accomplished before the environment is made available to functional / development teams. It is necessary to install and configure a web server after the required surface testing is conducted as it highlights major issues, if there are any.

The following aspects should be examined to reduce the risk during an upgrade:

1. Verify if the company can upgrade to the target release directly or they would need to upgrade to a previous release.
2. Evaluate the efforts required and the complexity in the upgrade. This is influenced by the number of modules implemented, number of interfaces and integration points, number of business process scripts and also by the quantum of customizations carried out.
3. Like any complex project, the upgrade project’s success is dependent on planning and project management. This should be coupled with effective scope management and strong and visible executive ownership.
4. Project Management should be aided by the Change Management strategy. This is necessary in the areas of application configuration, development and technology.
5. Upgrade team should be staffed with skills that complement each other. The project should be overseen by an effective steering committee. Different skills are required for the upgrade at different stages of the project. These should be appropriately made available from within or outside the organization.
6. Depending on the criticality of the business needs, available functionality in the target release should be evaluated and adopted where necessary. While undertaking this task, one must analyze the associated risks and also the pros and cons.
7. It is necessary to reduce downtime during the final stages of the upgrade. Performance tuning of the new system helps in reducing downtime.
8. Gather relevant information about the upgrade initiative.
9. Issues that surface during the upgrade process should be managed very effectively.
10. Creating an organization for the upgrade initiative is important. The Project Charter is a good starting point. Discussion should be initiated in the early stages with the affected organization about the planned work as well as the likely changes.
11. Quality of data is another important aspect of the upgrade initiative. Standard practices should be put in place to handle data integrity issues. Before the upgrade, time should be spent to ensure that the data is reliable. Ensuring high quality data helps in timely completion of table conversion.
12. Existing system and configuration should be analyzed and inventoried. It is said that upgrading is analogous to moving; before moving you have to know where all your belongings are and that they are being handled appropriately. Information about hardware, operating systems, databases, patches, tools release, localizations, customizations, interfaces, integrations and third party softwares should be gathered during this inventory process.
13. Risk assessment should be carried out early in the project phase. Appropriate mitigation strategies should be developed considering probability and impact.
14. Upgrade involves several technological decisions that directly impact the success of the project. These could be related to hardware platform, database, middleware, Unicode or web architecture.
15. Accurate hardware sizing should be carried out. An early sizing exercise helps in decisions related to the current hardware and new hardware.
16. Considering the difference in architecture and server resources required by the newer releases, it is highly recommended to conduct a Stress Testing exercise to determine the load and performance capabilities of the architecture.
17. Any customized programs should be identified for their current need. The required ones should be retrofitted early to ease the pressure on timelines. Often, this is the longest running phase of the project and on the critical path, depending on the nature of the project. Where there is an opportunity, existing customizations should be retired with the functionality in the new release.
18. Existing database should be reorganized and de-fragmented, as these help in improving the efficiency of the system.
19. Ensure compliance with the current Minimum Technical Requirements.
20. Implement most current ESUs and patches.
21. To minimize downtime at the time of upgrade, it is suggested that database size should be reduced. This should be achieved through judicious archiving and purging strategies.
22. Use existing CRP scripts to build test scripts for the new release. In case such scripts do not exist, new scripts should be created. This saves significant time during upgrade testing process.
23. Database triggers slow the data conversion process. Hence, where it is possible the table triggers should be disabled.
24. Custom indices, if any, should be re-evaluated and created again, if necessary, after the upgrade is complete.
25. Train super users on the features of the new system, who in turn can train the end users. This ‘train the trainer’ methodology will reduce the training costs.
26. Testing is the key element of the upgrade process. User testing as well as integrated testing of the system should be carried out to ensure good quality of an upgrade. This should be coupled with performance testing.
27. Go-live decision should be made by the group that represents all the affected parties, from business as well as IT. Usually, the Steering committee takes this decision.