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)
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.
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).
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.
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.
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.
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.
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.
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.
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)
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?
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)