We are planning an upgrade of our existing wM implementation, like so:
a. Upgrade from 6.1 baseline to 6.5 baseline
b. Upgrade underpinning database from Oracle 9i to Oracle 10g
c. De-couple Oracle database from current logical hpux 11i server, to a separate, neighbouring database server (also on hpux 11i)
d. Due to hardware upgrade, move from PA-RISC chipset, to Itanium chipset
The idea has been floated internally that we consider a ‘clean’ installation of webMethods, and promote across the in-house built packages to the new platform, for regression testing and deployment.
The alternative is to bring the files systems across from the old hardware, run up, and then run through the standard 6.5 update process as documented by wM.
Could anyone please advise what sort of process they followed to get from 6.1 to 6.5, and what the pros and cons are of the two options noted above?
Alistair,
We have just completed two production upgrades to 6.5. We made a copy of the existing installation and then upgraded the copy. It worked very well for us, plus left us with a backout plan if needed. The down side is that the outage is longer than the fresh install way. The old environment really needs to be quiesced prior to making the copy and needs to stay that way until the upgrade is done.
We are also doing a fresh installation for a different set of integrations. That one we will migrate the packages to the new installation. The real down side to that is that configuration of the instance can be a bit painful depending on the number of adapters, connections etc. Plus there is always the opportunity to miss some configuration and not know it till it goes live. The plus side to this way is that there is generally less of an outage to the clients.
Either way will work. I would probably in hindsight lean towards the fresh installation, just to minimize the impact.
Given the move to new hardware for both the IS and database servers, you might have the option of performing a fresh install, migrating the packages, testing everything as if it were a QA environment and then when all of the configuration settings have been verified migrate the production data from the old database, enable the adapters and start directing traffic to the new IS by using a load balancer or switching the IP.
The use of new hardware provides a better opportunity to test before conversion than the upgrade in place option without the downtime clock ticking so loudly.
I agree with Mark G that either should work, I just like being able to upgrade without the time pressures when the situation allows. Since you’re also switching hardware, chip architectures and database versions the upgrade in place seems more risky.