Hello all,
Sorry to create a new thread for this migration issues. However, I didn’t not see the information in previous threads. We are currently looking to migrate from 6.5 to 8.x and have been told by SoftwareAG that this is not possible. They have not given any hard evidence of issues concerning this but have pushed hard to have their Professional Services perform this migration for us. Our company is hesitant to take on this extra cost as we have handled other upgrades, IS 4.6 to 6.5 and BRK 5.x to 6.5 in-house. We have a couple hundred IS instances (prod and non-prod) and over a dozen broker servers so we would prefer not to have the overhead of migrating to 7.1.2 before going to 8.x. We have numerous applications under this tool along with outside clients and regression testing we have to concern ourselves with and this leads to a lot of off-hours work/testing. If anyone knows of concrete evidence of incompatability between 6.5 and 8.x I’d appreciate any postings.
You can migrate directly from 6.5 to 8.0, however the scripts given by wM REQUIRES you to perform a 6.5 → 7.1 → 8.0.
This means you would need to get a valid 7.1 running before you can move to 8.0, no need to get 7.1 on production
The database structure has change between versions, and while trying to reuse existing database you need to know internal structures, which you don’t.
Process for converting database requires then to execute the mirgration for the current suplied chain.
For instance 6.5 processes ran in Modeler, and stored in a repository inside WmModeler package. There is a tool for extracting this models and adapt them to new internals from 6.5 to 7.1, however not directly to 8.0. Unless you build your own tool then again the 6.5 → 7.1 → 8.0 stands.
Not to mention the new cluster settings getting rid of Repo servers and using now tangosol.
Depending what you need to migrate TN, Monitor/PRT, BAM etc the migration will be easier or harder.
The effort to build a migration tool is cost intensive, and jumping over 2 versions is not a common task, and not worth the investment.
There are many reasons why you would prefer when having 200+ IS’s and 12+ Brokers, to be done by PS. Still you can choose doing it yourselves.
You will require at least 3x the time with same resources, make your numbers and decide what will be best for you.
Thanks for the input. Since we do not use any database components, and limited IS/Broker functionality we are able to make the movement directly to 8.0. For our Optimize portions we are building new due to the fact we have one instance there. Our biggest issue has been the conversion from proprietory certificate management to Java’s Keystore. What a pain if you’re not familiar with that.
The code migrations were not impacted hugely and about 90% is working so far. Thanks for the input.
I found it:
Home > Knowledge Center > Product Fixes > Fix Explorer (Single Fixes)
under Integration Server, 8.0
IS_8.0_SP1_Migration_Fix1
Just tested out on Client Certs, works fine.
I have a question regarding this migration utility… I m trying to upgrade 6.5 to 8.x (side by side upgrade) source and target machines are different… when i m running this migration utility it looks for installed directory of 6.5 system… how can we pass different hostsystems in that parameter…
Migrations are supposed to be on same HOST, and I don’t think what you want to achieve is supported by the tool, but contact wM support and ask them as I’m not 100% sure. ( I never tried your scenario).
I somehow agree to this point, but still this a valid scenerio and currently in situation as well. Generally customers take the opportunity to scale their systems with application upgrade so this kinda scenerio’s are possible in upgrades
well i know one work around for this situation i tried to copy the entire webMethods directory from source (6.5) machine to new machine (8.x) and brought up the repository server by editing the configuration files. Migration utility wokred well in this way, parallely i have a logged a SR with webMethods technical support to see if they can suggest some better way.
Well migration means you run a server with one product version, and you upgrade to a newer one. It’s true wM 6.5 has some years, and servers running it also needs to be upgraded.
You plug in a new server with newer hardware ( more powerfull in CPU and RAM ), and you want to do all at same time, upgrade wM version but installing in a new HW.
That’s a perfectly valid use case, however it’s not only a “migration”.
You can “tar” all wM directory and move to the new HOST, however many references to old hostname will exist on many config files, doing a regexp search/replace should overcome this, and then once moved you perform the “migration” in the new HW. Again this is a 2 step change.
It would be lovely of course if migration tool would do all this for you in a 1 step, so let use know the answer to your SR
Well,I was just going through the entire thread; but I have some other issues. Currently I am planning was ding some research on the migration from wM 7.1 to 8.0 using a migration tool.
I am upto designing such a “Migration tool” that would do this migration.Now I have the following questions:
Is it possible to have such a migration tool that would migrate the code from 7.1 to 8.0 platform?
Request you to let me know with your suggestions on the above so that I can have some idea during the initial ideation phase.
