Migrations can be tough. Sometimes it can feel like we’re back to the drawing board when things don’t go as planned. Even worse, sometimes it can feel like there is no drawing board to go back to at all. Like a stray dog, the way we approach it will require some strategy and tact – or else we may get bitten. By simply applying the principles of Agile, our migrations can be as smart as our processes. Although this article is in direct reference to the IBM BPM to IBM BAW Migration trend, these principles can be universally applied.
First, we will discuss a few best practices, and then we’ll apply those best practices to their corresponding phase in the Agile Iteration or Sprint. Let’s look at a few recommended best practices to consider as we begin to migrate:
In an ideal world, all your applications are “Lift and Shift” and migrating them will be like an airplane ride you slept through – gracefully awaking on the other side well rested. In the real world, migrations experience turbulence. In the real world, our apps tend to develop idiosyncrasies over time due to an array of factors: workarounds due to product shortcomings, not adhering to best practices, “band-aid fixes”, inexperienced developers, floating business requirements, etc…
Before we begin to migrate, it’s important to be cognizant and take inventory of all these things. At best, our Migration Plan will account for and correct all these issues. At a minimum, our Migration Plan should prevent any further idiosyncrasies. We want to fully examine the health of our apps before we begin to treat them. Every hour spent planning will pay off in spades.
For IBM BAW Migrations, TWX Analyzer from Salient Process can help get a bird’s eye view and spot issues in the planning phase.
Although it sounds a little counter-intuitive, the goal of a migration project is not to migrate, but to improve our applications. After all, the reason for migrating is that the product has been improved (i.e. a new version). Take a step back and analyze the functionality that has been added and/or deprecated. Is anything being removed from the product which your applications relied on? Is anything being added that can make your solutions more elegant?
Take this as an opportunity to improve problem areas and strengthen your overall codebase / user experience. Since the migration process will require time and materials anyway, you might as well maximize the expenditure. Whatever you do, address breakage responsibly – this is no time for “band-aids”!
For IBM BAW Migrations, TWX Migrator from Salient Process can help modernize antiquated code, transition to new artifact types, and rapidly apply pattern changes that adhere to best practices.
Consider this a sequel or epilogue to the previous entry – Focus on Improvement II: The Rise of The Realist. We might find that there are more improvement areas than are practical to pursue. In this case, we need to “size and prioritize”.
Keep in mind, there is a difference between improved functionality and core functionality. Assuming these apps are worth their weight in megabytes, the core functionality must be preserved. Thus, the migration duration must be at least long enough to address all of that. Improved functionality, however, will come down to what else fits in the timeline. Once a list of improvement areas has been created, taking the time to estimate each line item and assigning a prioritization will be critical to the user story green-lighting process. Getting teams together to size and prioritize will also help facilitate invaluable conversations which result in unparalleled alignment. And if star alignment isn’t in the cards, team alignment is the next best thing.
If you are unsatisfied with the improvements you’re able to accommodate given the time constraints, don’t overextend the timeline or Bogart requirements. Remember that future iterations are like Paris – we’ll always have them.
Testing is key! Regression testing will be paramount as you move from point A to point B. If you have a vast application landscape and testing seems ominous, consider a slower roll-out strategy. Here’s some good news: regardless of how much you improve / change your applications throughout the migration process, the testing requirement should remain relatively static – another reason to entertain the improvement mentioned in the former section.
And if you don’t have a good suite of test cases, use this as an opportunity to collect them.
Once your solutions have been migrated and are available to end users, consider draining (old work completes in the old system, new work begins in the new system). It will require some change management to make sure end users are not confused by the dual task lists (two systems); however, the additional complexity of the in-flight migration is often a greater loss in resources than the gain in convenience or clarity.
Remember that the amount of time your end users will spend with dual task lists is directly correlated to the average cycle time of your processes. This means that, if your cycle times are short, they will end more quickly, thus getting you to a single task list sooner. If the cycle times are long, we will be maintaining two task lists (and systems) longer. Longer cycle times also may put you at a financial disadvantage upholding both support and licensing of two products simultaneously. So, do the math. If the cost to maintain two systems outweighs the cost of the in-flight migration, proceed knowing you made the right choice.
For IBM BAW Migrations, Process Federation Server can help hide the two task lists making the end user experience seamless while draining – removing the change management component entirely.
Now that we have a few best practices in the forefront of our minds, let’s walk through an agile iteration step-by-step and look at how it all fits together:
Much like Sprint planning, we want to examine our backlog, then select a group of stories to tackle. We also want to sift before we shift and add additional work items to the backlog accordingly. An output of this sifting will be a (hopefully short) list of required and optional improvements (focus on improvements) written as stories. Once we have all this information, it’s time to size and prioritize. This is also the time to determine whether draining (to avoid pain) or migrating your instances makes more sense. If draining doesn’t work for you, that’s fine – just be sure to allocate more time.
Hands on the keyboard! It’s time to develop. As with any development cycle, it’s important to invest in testing. This includes unit testing, user acceptance testing, and systems integration testing when applicable. There’s no way to lose the trust of your end users faster than to roll out a new application that is worse than the previous one. Throughout this phase, remember to focus on improvement. You’ll notice that focus on improvement is listed in both this step as well as the previous. SPOILER ALERT: It will also be in the next. This is because focusing on improvement is not a step, but at the risk of sounding like a yoga teacher, a way of life.
Once your migration has concluded, and the instances are draining (or have been migrated in-flight), conduct a Retrospective. For those unfamiliar, this is when the team gets together and reflects on what did and did not work. Obviously, we want to repeat what did work, and delete what did not. It almost sounds like a… focus on improvement. When possible (i.e. your apps are not intertwined / dependent), roll-out your migrated applications incrementally. This will allow you to reap the full benefits of the Retrospective: responding to your findings and doing an even better job next time around.
The IBM BAW Migration process shouldn’t feel monotonous or obligatory, it should feel exciting. It should feel like a new iteration, because it is. It’s a new chapter. A new start. From IBM Business Process Manager to IBM Business Automation Workflow, and beyond. It’s like a bunch of British chaps on the Mayflower, soon to be pilgrims on the steady shores of Massachusetts. Fast forward several migrations, and America is a thing. But, as Humphrey Bogart might say, “we’ll always have [Plymouth Rock]”.
