C2B2 logo icon

Is JBoss EAP 7 Migration Right For Your Organisation? Part 3 - Creating a Migration Strategy and Plan

In the penultimate part of our JBoss EAP 7 migration series, we offer guidance on the key approaches needed when building a framework for migration.

“With JBoss EAP 7 having been on the market since May 2016, and 7.1 expected towards the end of Q1 2017, JBoss EAP 5 and EAP 6 customers will be acutely aware that product support for those versions is moving inevitably towards the end of its lifecycle. Now more than ever, thoughts are turning to upgrade and migration, with target architectures that should be looking towards RHEL 7, EAP 7 and Java 1.8.” 

Brian Randell - c2b2 Principal Consultant
and JBoss Middleware Specialist


Part 3 - Transcript 

Hello, and welcome to the third in our series of JBoss EAP 7 migration videos.

We’re going through our ‘What’ stack and this is the ‘Action’, creating a migration strategy and plan. In the first slide, you see a mind map of the things you need to be looking at when creating your plan.

In order to plan effectively, we need to cater for any possibility, and examine any place that might need to change as part of that migration. If we identify it, and it does need to change, then fine, but we need to look at all of the things that could possibly change as part of the migration - and if there are things that need to change, we might need to redesign, we might need to change our processes and procedures. So, a number of things that might have to change when the things we need for the EAP 7 migration have been implemented.

This will fall into some broad categories, and code is one. What code needs to be changed? In part two of this series, we looked at the code challenges that we had, and what code needs to be changed with the upgrades of Java, JBoss, and JEE, and of course, we need to load-test that code as well, so that it can cater for anything required of it.

The next section would be Platform and Interfaces, and whether there are any resources required there that we need to change, such as the specs on our machines, interfaces, or any dependent software that might need to be re-configured. Is the software compatible? Is it supported with the new environment? All those platforms and interfaces need to be looked at and understood.

Design. When we’ve done our code and platform analysis, does that mean that there’ll be any infrastructure changes required? Do we need to change our HA and DR architecture? Do we need to utilise the domain model for example, rather than just have stand-alone? Do we need to change anything to fit in with our security policies? We need to go through everything and ensure that our design at the end will match the changes that we have to make.

Then, when we’ve made our changes, what about our operations? How do we run the software once it’s in production?

So, the operations team will need to understand the environment – the differences that environment has, how to manage it, and how to troubleshoot it. Monitoring may need to change, a whole raft of scripting may need to change for maintenance, indeed, lots of things will need to be thought of in that areas. And in terms of processes, as part of the migration, are there any procedures that need to be tested and amended? Any CMDB entries that need to be added or removed, or perhaps any ongoing maintenance patches.

So, in those five categories, there are lots of different things that we need to be looking into, so we can provide a plan for everything, and if we don’t have to do anything, then fine, but if we do, let’s plan it, write it down and make sure we have it in our schedule.

As we say, we need to define a few things. We need to define (for platforms) our target environment, what our network sizing is, and the interfaces – and we need to start putting a picture together of what that looks like - and the differences from what that looks like now. It could well be that there’s not much at all, but we need to make sure that we’ve analysed and understood that.

From a design point of view, are we going to make any changes to our platform considerations in terms of monitoring or migrations? How are we going to do this? Are we going to change our deployment? Sensibly, you try and do your migration as like-for-like as possible, and then if you have any improvements to be made, you’ll do them afterwards. Also, is there anything of the new features in EAP 7 that you would naturally utilise as part of that deployment?

One thing out of the design phase that’s often forgotten is the data. Are we going to change our data bases? How is the data going to be migrated? Can we turn our servers off for a period of time, where caching is not an issue? Can we do that and make sure our data integrity is as it was before and after the migration?

In previous videos, we’ve been through code, and the number of changes we might need to make there, so I’m not going to go through that – but just be aware that Java versions, JEE versions and JBoss versions have changed or are likely to have changed, and so therefore it’s worth going through that in great detail.

As we’ve mentioned, operationally, there are things that have changed. The admin console, the CLI scripts that you might need to use to query and identify and change the server configuration. How do we troubleshoot this? We need to understand these, we need to write them, we need to document them.

Logging has slightly changed - the change  from JBoss AS to the WildFly core, so we need to ensure that our monitoring is correct. And we need to review any scripts that have been written on the current stack so that they work on the new stack. And, as I said for process, there’s a whole bunch of documentation that we need to write there, so we understand that the service desk know the environment, they know what to do, and how to react to any alerts that come up, where they get pushed – and if we can automate any of this, the better. If we can automate an alert resolution, we should.

So there are the areas to focus on.

To facilitate this, we have provided a guide to planning a successful migration which gives you the nice lifecycle management schedule which we’ve presented in this series, and a whole section where you’ve got all the categories listed for you, and which you can use to go through and tick off the ones that you’re going to need to look at – and use it as a guide to plan the migration.

That’s it for this video, and next time we’ll be looking at the vision of what happens after your migration. My name’s Brian Randell, and I’ll see you next time.

PART ONE: The Drivers Behind Migration
PART TWO: Working Through Development Challenges
PART FOUR: Vision - a Guide to the Future