Overview

This article will give you an overview of the Agile Upgrade process, provide some pointers for best practices and tips for planning the upgrade. Agile upgrades often involve a variety of systems, interconnection, interface and desktop considerations that are far too numerous to address in this column. However, there remains a core set of steps that are common to all Agile upgrades. For the purposes of this column we will focus on the recently released Agile PLM 9.3.4. An Agile PLM 9.3.4 upgrade is a full installation and supports the most recent versions of Windows, WebLogic, Oracle Database and Java.

Before taking on planning for, or performing any Agile upgrade, you should review the documentation provided by Agile. Pay particular attention to the Agile Capacity Planning Guide for appropriate hardware sizing and versions combinations.

Software Requirements from the Agile 9.3.4 Capacity Planning Guide

Planning

One of the keys to a successful upgrade project is the initial planning of the project. Planning the server availability, sizing, naming and sequence makes it easier to quickly move to the next step in the project. It is advisable to consider building at least two Agile environments, one for testing and one production system.

Your planning should include time for additional installs (you may not be successful with your first attempt), ample time for testing and troubleshooting.

Testing is critical to a successful upgrade. Initial technical testing and full user acceptance testing processes with clearly defined business cases and goals for acceptance of the new system are essential to your success.

Installation

Every installation has 5 common components (in this order): Java, Oracle Database, WebLogic, Agile schema creation and finally the Agile application server.

The first build of your new Agile PLM system is the most difficult. Be sure to document every step (and every misstep) as you work through the process. I use extensive screenshots to capture items like passwords and configuration choices as I find it is quick and easy to transform to written documentation later.

Once you have successfully completed your first installation, create you documentation and then do it again following the documentation to see if you missed any steps or misreported any selections.

Upgrade the Agile PLM database using AUT

At this point you have a working Agile server environment and can move on to upgrading one of your existing databases for use in the new system. Upgrades are accomplished by use of the Agile Upgrade Tool (AUT). The AUT tool supports upgrading databases in-place or across separate source and target servers. Details are available in the Agile documentation and the best method will be determined by your specific requirements. However, our preferred method is to create an additional schema of the same Agile version as the source system, running AUT in place, then export the database and import it to the new upgraded version. Be sure to save the system passwords on the target system before performing an import. The passwords (and the AES key) are then updated in the new database to match those generated during installation.
(NOTE: A previous Zero Wait-State blog post, A Better Mousetrap (Agile PLM) details a simple solution to saving and restoring the critical system passwords.

Conclusion

On the surface an Agile PLM upgrade is a short set of simple steps. Under the covers Agile PLM 9.3.4 involves all new technologies and software versions that you may not be familiar with. Zero Wait State is fully prepared to partner with your organization to perform upgrades. We have the experience and knowledge to make your project a success.
If you liked this blog, check out our Agile Upgrade presentation on our methodologies for upgrading or contact an executive if you have any questions.

[Edit: Repost from February]

[clear-line]