v6.1 to v6.5 migration

, , ,
1

Hello,
We are migrating from 6.1 to 6.5 and use the following wM products:
(i) Integration Server 6.1
(ii) Broker 6.1
(iii) Mainframe (MIS) 6.1.1
(iv) EJB Adapter 1.2
(v) JDBC Adapter
(vi) Custom coded adapter in ADK v6.1
(vii) Trading Network 6.1
(viii) Workflow Server
(ix) Siebel Adapter 6.0

In addition, Deployer, Developer and Administrator are also being used.
The Broker and IS are deployed in a clustered environment.

My questions are
(i) What is the order in which the migration should happen for the products mentioned above?
i.e Should the adapters be installed before the IS/brokers?
(ii) Given the clustering that we currently have, how should the migration happen for the Broker/IS clusters?
What is the best approach for the same?
Any pointers/approach document/white papers on the above would be highly appreciated.

Thanks,
N

2

I would personally not attempt an upgrade-in-place with this many products and adapters.

In a dedicated upgrade environment, I would do the following

  1. Find and study both the webMethods 6.5.x Installtion Guide and tehe available upgrade documentation on Advantage.
  2. Install the database components needed for all of the products you will be using.
  3. Install and configure IS 6.5 SP2 and Broker 6.5.2 (the JDBC adapter 6.5 will be installed at the same time)
  4. Install My webMethods Server for Broker Administration and wM Monitor.
  5. Ensure the above are functioning well together
  6. Install the remaining adapters and configure one adapter connection for each to ensure the adapter is installed properly (restart IS as needed along the way)
  7. Install TN and perform basic configuration.
  8. Install the deprecated, soon to reach End of Support, MIS / Mainframe Integration server and configure a successful connection to a mainframe resource.
  9. Once you have this basic environment working, form project teams to focus on migration of the separate components.

Forgot to mention, don’t use an IS cluster as that has been deprecated and never provide much help in the way of failover anyway.

I would look at this as multiple migration projects and assign multiple teams to each area rather than have one team attempt to perform all of the upgrades.

HTH,

Mark