This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
If you’re moving your WebSphere traditional applications to Liberty (on z/OS or anywhere) a major question is how much you’ll need to change the applications themselves. It is entirely possible that you won’t have to do anything at all. You might be able to just take the .war or .ear files you deploy into WAS traditional and just add them into the configuration for a Liberty server (with appropriate datasource definitions etc) and that’s that.
It is also entirely possible your application developers might have to make significant changes, possibly even rewriting major bits, in order to get it to work in Liberty. That would be…unfortunate.
Or you could land somewhere in the middle, needing to make a few changes, do some testing, but nothing massive.
So how can you tell where your applications land on this spectrum? It isn’t a simple answer. What you really need to do is have a list of all the programming model things you made use of in your various applications and lay next to it a list of all the programming model things that are supported in Liberty and figure out what is missing or changed. It could be that some programming model thing you used is entirely unsupported in Liberty because it is very old and never got included in Liberty. Or it could be that Liberty only supports some newer level of some programming model and you’ll just need to make some updates to comply with the newer level.
That sounds like a really painful process. Which is why IBM created the WebSphere Migration Toolkit (aka Transformation Advisor). This is a set of free tools that can do exactly what we’ve been talking about. It scans through your application code and, knowing what Liberty does and doesn’t support and what the differences are among different programming model spec levels, can tell you what you need to do. It will point out the areas requiring significant change, but in the simpler cases can actually tell you what code change you need to make.
If you’re even talking about considering the possibility of migrating from traditional to Liberty I STRONGLY encourage you to get these tools and scan your applications. Having a handle on how much effort is going to be involved in moving the applications is going to be a key point in any discussion about migrating to Liberty.
If you can say that application migration will require a minimal amount of effort and have the reports from the tooling to back it up, that will help a lot in discussions about what to do.
And, of course, if it turns out that a significant amount of work will be involved, well, it is better to know that up front than to get started and find out along the way.
Run the tools, get the facts, plan the migration.