At some point in time, JD Edwards users will consider upgrading their software. There are various reasons for upgrading, such as expiring support, the desire to use different hardware, or the desire to use new functionality that is available in later versions of the software.
At some point, the JD Edwards user will need to decide between three basic methodology choices when upgrading, with possible variations of each choice:
• Upgrade using the existing footprint first, then implement new functionality later.
• Upgrade and implement new functionality as a single project.
• Upgrade using the existing footprint, while implementing some new functionality, and adding other new functionality later.
Upgrade using the existing footprint first, then implement new functionality later
This approach is attractive because risk associated with introducing new functionality can be separated from the risk associated with the upgrade itself. New functionality can be introduced piecemeal, after end users have become comfortable using the new version of the software. Some JD Edwards users contend that this approach takes more overall time, and interest in using new functionality wanes because it is not a point of focus.
Upgrade and implement new functionality as a single project
This approach is attractive to companies that are upgrading from a very old version of the software, or are migrating from a World version to an EnterpriseOne version. Some organizations find it easier to budget internal resources to a single project. There is obviously more risk with this approach, with the possibility of delays associated with issues with new functionality delaying the overall upgrade project. This approach requires more upfront education of the project team and end users.
Upgrade using the existing footprint, while implementing some new functionality, and adding other new functionality later
This approach is often used by organizations that are upgrading because they require functionality that becomes available in a new version of the software. This approach shares some of the pros and cons of the other two approaches, and is often a good compromise. This approach must be managed, however, or scope creep will cause the upgrade to e extended and go over budget.
In summary, if new functionality will be implemented at a later date, consultants can help identify how new functionality can be used in the future as part of configuration and testing activities.
For more information about upgrade options, contact info@brij.net.
Kevin Beck
Senior Application Consultant, brij Image & Information
