IT migration success hinges on minimizing downtimeData, software and hardware migration projects should, but don't always, fully exploit the features and settings of the new environment and minimize application downtime.
Migration in the world of IT comes in many forms and levels of complexity. At its most basic, it involves migrating or updating data, software or hardware -- or some combination of the three -- from one operating environment to, presumably, a better environment.
You could move programs and software to a new or upgraded system or IT resources to a different software platform or hardware infrastructure with an IT migration project. Or maybe transfer data from one database type to another or between storage arrays, servers or formats. Or, perhaps, migration entails moving an application from an on-premises enterprise server or some other aspect of your IT infrastructure to the cloud or between cloud services.
In scope, migrations range from small projects that encompass moving a single application or system to large-scale migrations that comprise new applications, reconfigured or upgraded networks and many systems and servers.
These examples merely scratch the surface of what IT migration could entail. But whatever the type of migration and however complex it is, a couple of basic tenets govern the process:
- Migration should fully exploit the features and power of the new environment.
- Settings and configurations should be maintained or changed as needed to keep applications working properly.
Sounds simple enough, right? It isn't.
As big data and data integration vendor Syncsort's "2018 State of Resilience" report illustrated, IT migration projects rarely go without a hitch. Syncsort surveyed 5,632 IT professionals, and, of those, more than 1,000 responded to questions regarding IT migration.
According to the report, availability/uptime is, at 67%, the leading yardstick used to measure IT performance. No. 2, application performance, and No. 3, customer (aka the business user) satisfaction, were well behind. Only 49% named app performance, and 47% cited customer satisfaction as the main measurement yardstick.
Meanwhile, nearly half of respondents cited business continuity/high availability as their leading IT concern for the coming year. Achieving or improving on all of these -- availability/uptime, application performance and continuity/high availability -- are bedrock reasons for migrating data, software and hardware as well.
Migration in action
Leading migration objectives include updating outdated technology at 68%, followed by improving performance at about 50% and consolidating servers at 42%. Adopting virtualization technology and reducing maintenance costs round out the top five at about 35% each. These objectives play a direct or indirect role in supporting an organization's reasons for migrating and improving on the performance measures stated above.
To get an IT migration job done, the vast majority of organizations, 92%, use internal staff in conjunction with or without third-party consultants to see a migration project through from planning to testing to completion. The remainder, meanwhile, turn to third-party consultants to get the job done. When it comes time to cutover–the actual moving of data to the cloud, across arrays or databases -- nearly three-fourths (72%) come in over the weekend to perform migration cutovers, while 54% do so on weekdays after working hours and about 20% over holidays during regular office hours.
A little more than a fifth of migrations take more than 100 hours to complete, while just less than 20% last one to 50 hours. Between 10% and 15% go on for 51 to 100 hours and fewer than 5% less than an hour. And when IT professionals were asked about their latest migration, 64% said their systems were down from one to 48 hours and about 50% said they were down one to 12 hours.
Slightly more than half, 54%, of those surveyed have never experienced a migration failure while 42% have. These failures resulted from issues popping up late in the IT migration process for 43% of respondents and an inability to restart applications for 38%. Around 20% cited each of the following as the causes: inadequate testing before the cutover, critical data not migrated to new server, the lack of a plan and excessive downtime.
When a failure happens, the result is often to postpone the migration until a later date. For half of respondents that was due to concerns about accruing more downtime. For 40% it was because of a lack of resources to continue the migration project.