I seem to recall reading that the v6 broker is able to “read” the v5 broker datastores. IF this is true…
Has anyone proven this out?
It would see to me you could just stop the v5 binaries and start the v6 binaries. Yes/No?
Thanks!
Raymond, have a look at the webMethods document “webMethods Integration Platform Upgrade Guide Version 6.0.1.” (webMethodsIntegrationPlatformUpgradeGuide.pdf).
The following comes from page 46:
‘Important! If you are upgrading from a 5.x Broker and want to use your 5.x data files, do not uninstall the data files when prompted by the webMethods Broker uninstall program. See �Use Upgrade Option for Enterprise Server 5.x� on page 49 for information on using
your 5.x data files in your 6.0.1 installation.’
Good luck!
Wayne
Raymond,
Yes, I have proven out that you can swing from 5.x to 6.x binaries and keep the same datastores. It works just fine. I did have some trouble with using the server_config utility to make the changes (exec path/6.x license key) and had to manually edit the awbroker.cfg files to effect all the changes.
Another thing to remember is that you still need to have the Enterprise Integrator installed so that you can access/modify your EI components, but other than that you can use the 6.x tools to manage the broker based on a 5.x created data file.
Steve
Steve,
Thanks for the info. Would you say I should just plan on having to manually modify the awbroker.cfg file while the broker servers are down, prior to starting the v6 binaries?
You say I need the EI tool still… How then do you plan to “move on”? Is a redesign of your integration(s) required to remove your need for the EI tool?
Ray
Ray,
I used server_config to change the exec path using “server_config add <datapath> -e <6.0>” which changed the awbrokermon.cfg and awbroker.cfg files to use the 6.0 exec. What I couldn’t get to work was using the -k option on the server_config add to change the key so I had to go into awbroker.cfg manually to update the key. I should probably log a ticket with webMethods on this fact. If you want to do everything manually then don’t forget to edit awbrokermon.cfg along with the awbroker.cfg files.
As for moving away from the EI tool, we need to wait for the upgrade application from webMethods due out in Q3 sometime. This application will migrate your EI Components into IS flow script. My plan is to 1st upgrade the brokers to 6.x and then selectively migrate off the EI.
The nice thing that webMethods has done is make everything backwards compatible so that you aren’t forced to migrate all your legacy integrations before you can take advantage of the new versions features.
Steve
Steve,
Thanks again for the info.
Now… how did you get to v5 broker? Did you upgrade from v4 (which is my plan) or did you start out with v5?
I’m told by webMethods I need to engage Professional Services in order to transition from v4 to v5 broker… 
Ray,
It all depends on which of the v4 technologies that you are currently using. Are you using ATC? Are you using Blueprints or WorkUnits? Are you using ATE?. If you are using these technologies, then your migration will be more difficult and requires some special handling which is why the recommendation for Professional Services.
We actually began on Activeworks v3 before they were bought out by webMethods and then moved to v4 and to v5 and are now moving to v6.
When moving from v3 to v4 we avoided using the ATC/ATE technology as we got good product roadmap info from webMethods that it was soon to be obsolete and those features would be embedded in future product versions. We built all of our v4 components directly in EI after it stabilized and thus our move to v5 was straight forward. We had no ATC WorkUnits or BluePrints to deal with.
Also, with the backward runtime compatiblity and technical support we were not required to do a “big-bang” conversion and we were able to build new integrations in the newer versions and upgrade older ones as needs/changes dictated.
Steve
Steve,
Lucky you, we didn’t get good roadmaps from webMethods. We too started on v3 (ActiveWorks) BUT we have ATCs in our integrations - they utilize workunits. Actually my team is the reason there was a transition “tool” to get from v3 to v4.
We also still have some v3(.1.3) adapters hanging around (I beg and I beg - but that’s a different story 
), do you know if “standard” v3 adapters function on a v5 broker? I making the assumption the “standard” and “intelligent” v4 adapaters will be ok since they are supposed to work with v6.
I’m not up on the integration/developer lingo, my team focuses on the infrastructure, there is another group that does the integration development. I’m tasked with architecting the infrastructure, so I’m looking for the best (read least downtime/least risk of data loss) way to get to v6…
Thanks again for all your help.
Ray
Ray,
Yes, v3.1.3 will work with v5 and v6 brokers. We do have some v3 legacy integrations that run on the standard IntegrationLogicAgent and on the standard Oracle DB Adapter. These are both currently running on v5 in prod and on a test instance of v6. They are essentially the same adapter executables as when it ran under 3.1.3 but we are actually using the v4.1 standard adapter versions of these and using ADK 4.2 for the adapter processing engine.
So, unless you have some custom built 3.1.3 adapters then I think you should be just fine in your upgrade to v5 and onto v6.
webMethods backwards compatibility does work, it is not just talk!
Steve