We are planning to migrate 8.2.2 to 9.8 version, Please let me know the best procedure to migrate the below components in short period (within 3 months) and also let me know in case of any complexities.

IS
TN
MWS
Broker ( planning to migrate from broker to UM)

Hello Krishna,

8.2.2 to 9.8 migration need to be done in SBS mode.
The best way to do the migration is to first take the backup of DB dump & file system(i.e. SAG installation directory).
Restore the DB dump & file system in other machine, then run the migration by pointing to clone DB.

The Benefit of take clone DB is if by any chance any failure will occur during migration, so you have the backup files to restore and continue the migration again from the beginning after rectifying the issue.

Steps for migration of IS, TN & MWS is available in Upgrade Guide @ http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite9-8/SysReqs_Installation_and_Upgrade/9-8_Upgrading_webMethods_and_Intelligent_Business_Operations_Products.pdf

And steps for Broker to UM migration is available @ http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/Migrating_from_Broker_to_Universal_Messaging.pdf

Please let me know if you need any further help.

Thanks & Regards,
Abhishek

OK, Suppose if we are doing for development environment,

• we will take the backup of file systems and DB , move to new server
• install 9.8 version
• execute the migration script for DB and file system ( let me know if there is any other best procedure?)
• bring up the server

If i execute all the steps , i will be able to bring up the server, but current data will not get it , I mean the current development server data.

How will we sync Database (current and new) after new server is ready? is there any scripts that i need to execute again to sync Database?

The purpose of doing this Side-by-Side migration is to find out all the issue which can be encountered without impacting the original servers(Original server will be kept on running in your case development environment).
And once the migration went fine and all the issue gets fixed, user opted for the migration on the original servers.

AFAIK during migration phase development work should not be stopped(i.e. while doing the migration on the original development environment).

Yes, this i got it , but when we are decommissioning the old server , how will we sync the current database from old to new?

There are some changes might have happened on correct database.

When you go for the final migration than at that time, again you have to take a fresh backup of DB and file system. And you have to run the migration script on the fresh copy of backup.

Thanks for the info.

Whether we need to migrate the file system again? If we done this, whether it will problem for the new configurations correct?

How will we do that? It will be helpful,if you share the steps to perform this.

Yes, you are required to migrate the file system again. Let me explain you from beginning.
Let’s suppose your Original servers are running on machine A and your new server machine will be B. Initially take a back up of DB + file system from machine A and restore in machine B. Here you servers on machine A will be kept on running.
Install the 9.8 products on machine B and migrate the DB & file system on machine B. Find out all the bug and resolve it.
Once all the bug will be fixed.
Delete all the installed 98 product and drop the DB in machine B.
Take the final copy of DB + file system from machine A and bring down servers in machine A. Then restore to machine B, do the migration and start the 9.8 servers in machine B.

Thanks for the info again.

For the below points, have few questions…

• Delete all the installed 98 product and drop the DB in machine B.
  Whether i need to uninstall the 98 product?

-Take the final copy of DB + file system from machine A and bring down servers in machine A. Then restore to machine B, do the migration and start the 9.8 servers in machine B

Whether i need to install 9.8 products again and do the migration start from scratch.
Or only migrate the file system and DB is fine.

Whether I need to uninstall the 98 product?
Yes you are required to uninstall the 98 product.

Whether I need to install 9.8 products again and do the migration start from scratch.
Or only migrate the file system and DB is fine.
Yes, you are required to install 9.8 products again and do the migration start from scratch.

why we need to uninstall the complete 98 environment?

Is there any way that we can upgrade on top of that?

Is it fine to just remove the new database and create the new DB from old DB server?

If you not don’t install fresh 9.8 and just migrate the DB after taking fresh DB clone, then your file system & DB will become un sync. And due to which you may face numerous unwanted issue. Even migration may also fail.

In this approach, we are doing double work correct.

First step we are testing our DATA by implementing POC.
Second step we are uninstalling that.
Third step we are again taking the backup and installing again.

But we have very strict timeliness. There is no other way, is it?

When we execute the migration script, it impacts only IS correct? Not other products like MWS, TN.

Why can’t we execute the migration script on top of new environment (file System level) and pointing to new DB? Is there any issue.

Hi Krishna,

as TN is installed on top of IS, this will be migrated together.

MWS needs to be migrated separately.

There are migration guides for Broker->UM-Migration available.

As the migration covers several releases, you will have to do a lot of testing (and trial and error) on both installations.

We had SAG Migration support involved in our 7.1->9.5 migration and we have found several things during testing which were not reported during the migration itself nor were documented in the guides.

Regards,
Holger

Holger, if you can give me details of the things you had trouble with, and the info you didn’t find in the 9.5 upgrade guide, I can investigate improving those areas for the 9.10 and later releases.

Marianne

@Holger, Thanks for the info.

Can you provide the things that you had trouble with, and the info you didn’t find in the SAG guide.

Also review the below high level steps, and let me know whether i need some more

• backup of file systems and DB , move to new server
• install 9.8 version
• execute the migration script for DB and file system
• bring up the server
• At the time of final migration again copy the file system and DB backup, run the migration utilities.

Thanks for your support.

Hi,

here are some points we have observed:

• some public services have changed their default behaviour or their signature which was not reflected in the Build-In-Services guides
  – pub.prt:logCustomId fails when being invoked without customId instead of setting “NO VALUE”.
  – some of our WS Descriptors were not working after migration and had to be recreated from WSDL.
  – SOAP-Fault structure has changed due to newer Spec Version
  – Websphere MQ Adapter Services and Notifications have differing field types on certain fields (introduced in MQS_6.5_Fix25, but not fully documented in Readme, Readme was corrected in MQS_6.5_Fix26)

Regards,
Holger

hi Holger, all the changes you mention with one possible exception should be documented in the IS readme. The upgrade guide explains how to upgrade, but does not (could not) cover all the changes for every product.

The possible exception:
– some of our WS Descriptors were not working after migration and had to be recreated from WSDL.

Were you able to figure out why they were not working - was it because of changes that were not written up in the IS readme?

Marianne

Hi Marianne,

thanks for your reply.

The issue with the WS descriptors was (partially) with request and response structures being defined in a manner that is not supported by the newer spec version.
Even pre-8.2 compatibility did not help here.
Some had problems with namespace declaration or namespace prefix generation.

One of our partner systems is still not able to consume the wM 9.5 WebService, but as this application part is going to move to an other ESB in our company soon, we can accept this to stay on wM 7.1 until then.

Some issues turned out to be located in the wM code (meanwhile fixed via Support Incidents and regular Fixes)

Regards,
Holger