by Andy Patrizio

Bad migration experiences leave IT bosses gun-shy

Sep 16, 2016
App TestingEnterprise ApplicationsIT Governance

IT pros are hesitant to take on migration projects because a previous one left a bad taste in their mouths. However, they may only have themselves to blame for that.

migration primary2
Credit: Thinkstock

Previous migration efforts are often so bad that the majority of IT pros drag their feet on doing another migration project, even if they need it. That’s one of the results of a new study by a cloud migration specialist Vision Solutions.

The migration survey — see chart below — was part of a larger study, the Vision Solutions’ 8th Annual State of Resilience report.

The problem, however, lies with many IT shops, according to Vision. They either lack expertise to do the job properly, don’t plan well in advance, or both. Of the 935 professionals surveyed, 35 percent say that they lack the experience or the expertise to confidently perform a system migration.

migration stat

Click for larger image.

The most common mistake is underestimating the amount of time it will take, according to Alan Arnold, executive vice president and CTO of Vision Solutions. It’s a chicken-and-egg problem. “You have to do one to understand it. Much of it comes down to a lack of planning. They think it’s just a backup and restore. There are hardware compatibility issues, especially on sophisticated networks with a tight tie in. Many [IT pros] don’t understand what their apps do,” he says.

Brian Sullivan, a managing director with the giant services firm Accenture, echoes this sentiment. “It’s somewhat common in the industry where all of us have the challenge of you don’t know what you don’t know,” he says. “So if organizations have not embarked on a major IT project like a migration, then it is harder to understand why so much up front planning and risk mitigation and stakeholder management and data management are so critical.”

[ Related: 5 trends that will transform project management ]

IT shops don’t think about the web of dependencies and connections between what they are upgrading and other systems, says Arnold. They don’t look at storage subsystem compatibility, app dependency and true dependency of apps to servers. You might have to take down and replace several things all at the same time.

But therein lays the challenge. Arnold spoke with one CIO who talked of wanting to solve the constant change in his environment but there were too many variables in these migrations to make a move. “There is no one particular issue because everyone has a different experience. I’ve had people plan these out and thought they knew how it would go and had a storage subsystem fail on them,” he says.

Arnold says there is no single cause of failure or blame. But there is a methodology that needs to be followed because migrations are not like the old days. The interconnections and dependencies mean whatever server you are upgrading or migrating there might have a dozen more connections you haven’t even thought about.

Regardless of the initiative, you need upfront planning, says Sullivan. “That’s the case whether you are engaging with a services firm or not, then determine if there is enough internal institutional knowledge to do it on your own. It’s imperative that upfront planning discussions are held and a comprehensive look at the enterprise is done even if it is a small program,” he says.

Keys to success

It comes down to three things, says Arnold: planning, tools and consultants. Far too few companies go in with a comprehensive plan that covers contingencies, fallback, and the full scope of what needs to be migrated. Too many companies are going into migrations flying by the seat of their pants and you can’t do that with your e-commerce website.

If you don’t have the staff, he says, go to consultants who know how to do it. Hire companies that know migration. “Complexity and quantity determine where you go. Simple migrations anyone can do with the right tools,” he says.

[ Related: 10 tips to meet your project planning goals ]

Most ISVs like IBM, Microsoft and Oracle have their own tools for migrating from old versions of their products, and there are plenty of third-party migration tools vendors, including Vision Solutions. No one vendor does them all because there are too many scenarios. “App companies have migration tools, but no one leaves their environment a plain vanilla environment. Everybody modifies things a little differently, so the tools don’t always fit,” he says.

5 components to avoid painful migrations

1. Stakeholder management, ensuring all relevant stakeholders are onboard with the mission and the purpose behind the migration. Otherwise you are left with frustrated execs. “You might end up with a happy CIO, but an unhappy CFO or CMO, who are involved in and reliant on that technology,” he says.

2. A sharp focus on end-user adoption. Even if you have strong stakeholder management, if you are not focused on educating end users along the way, explaining why the organization has chosen to migrate to this technology and surrounding business processes, you will fall short of achieving your objectives, because the users are not using that system to its max potential.

3. Data – A lack of focus on cleansing and mapping data to the new target solution ensures failure. “If the focus is purely on standing up the new system, but not focusing on the past, you will be challenged with inaccurate or clumsy reporting. What we tend to focus on as a best practice is taking a look at interacting apps that surround what’s being migrated.” That means looking at systems sending data in or receiving data from the new system. “This is a common area that causes unbelievable amounts of frustration when there is not adequate design and testing of those interfaces,” says Sullivan.

4. Performance testing. Many companies fall into the trap of testing only how fast the screen refreshes. When you do that, you might miss other larger, more critical performances behind the scenes. “It’s common that a new technology performs well, but if you don’t think of lowest common denominator in the process you will have issues,” says Sullivan.

5. Making sure that your technology vendor is fully engaged and committed to the success of the program. “If you treat that as a one-time transaction where you get the software and walk away, you are setting yourself up for issues and have to go back and try to reengage with the vendor to get support, as opposed to periodic governance meetings where they are brought along with the project,” he says.

Every organization has a natural trepidation around making a change, especially where that change can have a large impact on critical business processes, says Sullivan. “However, if the organizations have done the upfront work and are clear on the ROI it will bring and the ability to mitigate risks, then there is enough data to avoid a gun shy feeling so long as they have continued governance to address issues along the way of the implementation of the program.”