Share this post:
I once saw a quote that said, “the only one who really likes change is a wet baby.” We all know that change is uncomfortable and can take folks out of their comfort zone. That’s definitely true when it comes to migration projects, especially for organizations that have been running their business on one specific technology for decades.
This blog post will look at some of those key worries and how you can better understand and minimize the changes that will result from migrating to a new technology platform. Remember that in this migration series, we’re talking about migrating the same workloads (applications and databases) from one platform to another. These migrations don’t involve changing any functionality, so your users won’t have to learn a new solution. They’ll be running and operating the same workloads as before — it will just be on a platform that’s much faster and more reliable.
Many companies run their business on a specific technology for 20-plus years. When a change to a new technology is required, the first thing they worry about is the lack of skills they have for the new platform. This is followed closely by concerns about the learning curve to get their resources proficient.
If the source and target platforms run Linux and/or UNIX, the learning curve is very short. Competent system administrators can transition between these environments in a matter of weeks, and there are many training classes to help with the transition.
Unless the database is being changed as part of the migration (Oracle to IBM Db2 for example), the database administrator’s world will be pretty much the same. They may need to change some scripts but the majority of what they do won’t change.
For the teams tasked with running the company’s business on a daily basis, the worries surrounding a migration are many.
- Will the applications work the same way as they did on the old system?
- Will we need new tools to manage the new environment?
- How can we test to make sure the performance will be the same and hopefully better?
- Is there a back out/contingency plan if the migration fails?
- Will customers, suppliers and users have to change the way they interact with the system today?
As I said earlier, a platform migration doesn’t involve changing functionality, so your applications will work on the new system as they did on the old — in the case of IBM Power Systems, just faster and more reliably. Because we’re not making functional changes, it’s unlikely that the client’s customers, suppliers or users will have to change the way they work or require new service level agreements.
The mock migrations we do prior to the actual go-live (see this post on ISV application migrations and this one on database migrations) provide clients with the opportunity to test the new environment in many different ways to ensure it works and will meet the required performance levels.
During the go-live event, a back-out plan is already in place if something isn’t right. You can stop the migration and resume operations on the original source system because the source databases haven’t been altered.
It’s likely that the new system will come with management tools provided by the vendor and will require training. If your organization is running a third-party tool, just check to ensure that tool is certified for the new environment.
Operationally there are three things that will change when you migrate from a competitive UNIX platform and/or x86 platform to IBM Power Systems:
- The performance goes up
- The reliability goes up
- The footprint goes down
I saved culture for last because it generates far fewer migration worries than skills and operations.
The culture of any organization is complex and has many components, and technology is certainly one of them. That said, I think the migration from one technology platform to another has a minimal effect on the overall culture of a company. Typically, the users, people who run the business on a day-to-day basis or the managers in the C-suite don’t care which technology platform they use. As long as it’s reliable, cost effective and gets the job done, they’re happy.
There are certainly culture discussions within the IT department and within the company’s technology community that can be intense. While different constituencies debate the merits of one technology platform versus another and try to influence the final decision, these discussions have a minimal effect on the company’s culture.
We’ve now worked through the top issues that cause clients to worry when faced with a migration project:
My next blog post will be the last in this series and will focus on migration best practices. Please stay tuned!
Meanwhile, if you’re looking for migration support, IBM Systems Lab Services Migration Factory is a team of experienced migration consultants who have the technical expertise to help. Email us your inquiry today.