Webmethods Upgrade help

, ,
1

Hi All,

We are planning to upgrade from 10.5 to 10.11 in the traditional way (without using Command Central).

Our requirement is to keep both old and new version products running in parallel for some time to do some testing, and then finally uninstall old version.

I performed the below steps so far:

  1. Installed IS, MWS, UM with new ports (didn’t use side-by-side upgrade for MWS and UM) on the same machine in a different directory.
  2. Created DB components for the new version on new DB server.
  3. Created ZIP files for IS, MWS, UM as mentioned in “Prepare old installation for upgrade” section of upgrade guide.

Please suggest if upgrade is possible with the below next steps that I am considering:

  1. If I run the migration utilities against the ZIP files created from old installation, will it work wrt upgrade?
    Asking because when I tried to run the migration utility for UM it adds another UM server(from old installation ZIP) in addition to the new installation. This doesn’t seem like an upgrade though. Suppose same will happen with MWS.
  2. We don’t want to migrate database for TN, IS and MWS? Can we really skip DB migration(for IS and MWS; I think TN can be skipped) considering we migrate assets and then use this new DB for the new version.

Overall, what I am trying is to install products (IS, MWS, UM) on new ports on the same machine in a different installation directory.
Then use migration utility for upgrade, run both the versions on different ports for some time; and finally change ports for new version to default ports once we want to shutdown/uninstall old version.
Also have a doubt if changing UM port is possible.

Is the above feasible with respect to an upgrade?

If not, then should the best way be to upgrade with same ports, then change ports after bringing products up?
For this, can we change the UM port?

Thanks
Monika

2

In past, such as version 6 and 7, this approach worked okay. With the newer versions it is more problematic. I would strongly suggest to use new server(s) for the new version and copy/migrate to it. IMO, in place update should be avoided. Establish new infrastructure, install/migrate to that, decommission the old.

4

Regardless of “in place” or new infrastructure approach, the DB objects will need to be copied and migrated, if you want to keep the old data. You have to do that because if you migrate the DB in-place you’re likely to break 10.5.

On the surface it does seem the in-place approach is easier but it really isn’t. We found the parallel server approach to be easier and more flexible. And doesn’t risk potentially disturbing/destroying the existing.

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.