60 Upgrade Tool Best Practices

, , ,
1

Has anyone used the 6.0 Upgrade Tool on a recent migration and developed some best practices or procedures that worked well for your project?

The tool can be downloaded using the 6.01 installer and appears to do a good job of discovering brokers, adapters and components on a given host that need to be converted. It also produces a list of manual tasks that must be completed if you plan to use the IS packages it generates.

It’s fairly straightforward to change the default package names, but I don’t see an easy way to have the doctypes created in the main package for a given integration. Creating and synchronizing the doctypes is a nice time saver however.

One thing I found strange was that if you don’t have the JDBC Adapter installed on the target IS server, the tool appeared to generate only placeholder services for DBAdapter components. I need to dig in further to see what else depends on how your target server is configured.

Thanks in advance,

Mark

2

We did try to use it for one of project to migrate the 4.x EI to V6 IS environment. However, one of the developer spent two weeks in trying to
migrate just one transaction and failed. So we decided to port it manually instead.

3

Mike,

I’d be curious to know what the specific problems were related to your developer’s attempt to convert that transaction. Can you shed any light? Did you use any of the output produced by the tool? If not, did you create each doctype by hand?

I’ve seen similar anecdotal accounts before, but have not been able to drill deeper into the real issues.

Mark

4

Mark,

I will post our analysis later.

Mike

5

In working further with the upgrade tool, I found that it actually did a pretty good job of migrating ES integrations that used DbAdapter Services to IS JDBC Adapter Services. You need to create and enable the JDBC Adapter Connection for the DbAdapter you are migrating and then specify its name and folder name in the Upgrade tool before migrating. You can then use Developer to view the Adapter Services using the appropriate template (Dynamic SQL, Insert, Update, Delete, Stored Procedure, etc.).

I think our approach will be to:

  1. create a package and folder structure that conforms to the customer’s development standards on the target IS server dedicated to the migration effort, []create the JDBC connections in the desired package and folder location and enable them, []generate the migrated docTypes, commonOps and services into temporary packages after overriding the default package and folder names to keep each integration separate and to enable doing the migration in manageable “chunks” [*]We’ll then move the docTypes, services and commonOps to the desired locations using Developer’s drag-and-drop capability. When the “Rename” dialog appears we’ll take care to choose “Update All” each time to keep the naming dependencies intact.

This will still leave quite a bit of work (including extensive regression testing), but seems to be a huge leap over a 100% manual approach. This is especially true for ES components that have 6.0 ART adapters in IS and an Upgrade Tool plug-in.

After more adapters that use the 6.0 ART are released this quarter (or early in Q2), I think the Upgrade Tool will become more and more useful. My current project hopes to be able to use the Upgrade Tool plug-in for the 6.0 Websphere MQ adapter. The plug-in should follow the GA release date of the 6.0 MQ adapter by 6 - 8 weeks (we hope).

Mark Carlson
Conneva, Inc.