Commonly this occurs at end of life for a legacy system, when customers understandably have decided that the business cannot remain on an unsupported environment.
In a CA Technologies context, the customer legacy system is most often CA JMO and the new system CA dSeries.
In doing these migrations and conversions so frequently, we've evolved a methodology that is:
Safe - with us in all modesty the go-to people for this kind of project.
Specific - teaming with key client personnel from the application, scheduling and operations teams.
Valuable - delivering the best of new workload technology.
Effective - with a track record of highly successful conversion projects.
In this brief blog I'll walk you through our 10 point conversion methodology.
STEP ONE - SET EXPECTATIONS
When planning a conversion from a legacy Workload Automation technology to a new one, the most important first step is to set expectations; you need to ensure all those involved have an accurate and shared set of views and expectations from the conversion project.
Key stakeholders in IT and the user community should all be met, the differences between the old and new solutions explained, and the conversion process detailed to them.
STEP TWO - AGREE CONVERSION APPROACH
The next step is to detail the pros and cons of the two main conversion approaches with the customer, and to agree which is best suited to them.
The Big Bang approach, as the name suggests, is moving all your schedules from the old technology to the new one in one step. This requires a large support team during the cut-over, and testing requires coordination across multiple teams, but on the plus side there is no need to create dependencies from the old technology to the new.
The alternative is the Phased, or Schedule-by-Schedule approach. This has the advantage of greater schedule visibility during the cut-over process, but on the downside may require old technology to new technology inter-dependencies.
Usually it's a question of how many jobs the client has; generally, the Big Bang approach is best suited to smaller numbers of jobs - say less than 1,000.
STEP THREE - PROOF OF CONCEPT
Experience shows that an early positive outcome does wonders for the enthusiasm and confidence of the project members and executive sponsors. For this reason, and to test and fine-tune our approach, we recommend starting with a proof of concept.
In this way we first select a workflow for conversion, then set up a non-production infrastructure for the new technology.
We then undertake the workflow conversion, test the converted workflow and refine and fine-tune the new workflow code.
STEP FOUR - POST PoC PLANNING
With the PoC done, we can make much more detailed plans with greater accuracy and confidence. Thus we discuss the lessons learnt from the PoC with the customer stakeholders, and plan the full conversion in detail, complete with test criteria and specific delivery dates.
STEP FIVE - EDUCATION
Next we recommend agreeing a plan for training the users in the new technology. It's important to provide content that's relevant and also to deliver it via the most appropriate means.
Thus some users might be best served by standard vendor training courses, and others via bespoke courses specifically tailored to their requirements. In the same way, it's important to establish which users to train on-site face-to-face - very much our preferred method - and which to use remote user-paced training. Either way, it's best in our experience to agree and plan it at this stage.
STEP SIX - CONVERSION
After the PoC and advance planning, it's time to do the actual conversion - either en masse if using the Big Bang approach, or schedule by schedule if using the Phased Approach.
When the conversion of a schedule has taken place, we recommend the users review the converted workflows to make sure they still do the job, and to familiarise themselves with how the workflow operates within the new technology.
STEP SEVEN - TESTING
Now comes one of the most important steps, and probably the most time-consuming but ultimately the most critical - testing.
Here we're looking at a repetitive cycle of test, flag issue, fix & document, and retest, which typically lasts between 20 and 25 days and accounts for around 40% of the elapsed time of a conversion project.
Clearly this step needs to be as thorough and rigorous as possible and is key to the reliability and robustness of the final converted system. It concludes with exhaustive end-to-end running, typically over a period of 4 to 5 days. When the client and project team are happy with the test environment and what the batch is producing, they will then sign-off on that.
STEP EIGHT- RELEASE
When, and only when, we and the client are satisfied that every aspect of the new development system has been tested, and that we're both happy with the output results and have sign-off, we promote the converted workflows into production, with our and the customer's Subject Matter Experts providing close end-user support.
STEP NINE - SIGN-OFF
With everything uploaded, we start testing the production environment. As I said earlier, we now have the choice to either bring in the schedules in a phased approach or to use the Big-Bang methodology. Either way, as we've seen, this will have been agreed at a previous early stage of the conversion project.
End-to-end testing of the production system usually takes 4 to 5 days, after which the production environment is signed-off.
STEP TEN - ONGOING SUPPORT
Our involvement doesn't stop when the new solution is operational and signed-off.
We continue to support both the legacy and the new system during the transition process and can provide managed services to support the new solution.
We find that many clients prefer our Cloud-based services, which save them from the expensive investment in dedicated hardware and support staff.
So there you have the distilled wisdom from years of large-scale Workload Automation conversions by Extra Technology.
Our clients tell us this renders a potentially fraught and difficult process into a safe and effective one, and also delivers new technology in the best and most reliable way.
Bhupinder Janjuha is Extra Technology's Technical Director. Prior to co-founding Extra Technology, Bhupinder worked as a technical expert for manufacturing, financial services and software companies holding a number of technical management roles, including running the EMEA support team for a top-ten software vendor.
Bhupinder is a recognised expert in Enterprise Management, Application Performance Management, Databases, Virtualisation and Cloud technologies. He also specialises in product migrations, managing our experienced team of conversion specialists.
Copyright © Extra Technology Ltd. All Rights Reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.