Caveat to statements below: Opinions below are my own and may not have any basis in reality.
6.0 is the first real effort to unify the up-to-now very distinct environments of B2B/Integration Server and Broker/Enterprise Server. Migration/update is primarily an Enterprise concern. AFAIK, the IS 6.0 is essentially IS 4.6 with some updates.
IS is becoming a full-fledged broker client capable of direct interaction with the broker without using a bridge. Enterprise adapters are being re-hosted in the IS environment. VI, ETE, the old Enterprise Manager, the ATC, and probably other “legacy” Enterprise components are being taken behind the shed and shot (someone please correct me if I have this wrong).
However, existing adapters/agents WILL BE SUPPORTED by the updated broker. This means existing infrastructures will continue to work, but YOU MAY NOT HAVE A MECHANISM TO UPDATE THEM if they need changing (e.g. no ETE to update infosets).
ATC Workunits and Blueprints should work with the new broker. Workunits could be updated, as those have always been external to the tools, but you may not have a mechanism to update infosets that associate the Workunit with an event. There is likely no tool provided to update Blueprints. Migration tools that come out may be able to automate the migration of Blueprints but Workunits will have to be reimplemented (no way to migrate what is essentially free-form Java code).
VI scripts will need to be rewritten (in FLOW) if you need to update them before migration tools are available.
If you have custom Enterprise adapters, and you want to take advantage of the new architecture you’ll need to rewrite so they can be hosted in the IS environment. You do not need to change them if they are performing as desired. Since the run-time libraries need to be supplied by wM to support legacy adapters, then you should be able to make changes to your own custom adapters as needed.
Can anyone speak to “…the 6.0 architecture’s new performance.” that Frank mentions as pertains to custom adapters? I’d suspect a possible performance hit, depending on how custom adapters are written (C, Java) but measuring is always the right approach rather than assuming.
Of course if anyone has any information to the contrary of any of the points above, please post it!!