Nobody in IT welcomes a major data migration project, but the legacy storage vendors trap companies into going through them every three to five years. The process is fairly standard. Once your hardware platform starts to approach end-of-service, your rep from the big iron vendor – EMC, NetApp, etc. – offers two choices. You could renew the existing equipment at astronomical service and support levels. Or you could buy an entirely new array for less money.
At first glance, Door #2 seems like a win-win situation. The vendors move iron and you get the latest hardware at a relative discount. But there’s a catch. Migrating data from one array to another comes with significant hidden costs. One estimate puts them at 54% of the purchase price, so that a traditional $300,000 array actually costs $462,000.
The truth is that repeated data migrations are painful, expensive and time-consuming. They add no strategic value to the enterprise. They put IT’s reputation at risk. They’re also completely unnecessary.
Before I explain why enterprises should never have to suffer through another data migration project again, I’d like to dive a little deeper into the process. In this first of two posts, we’re going to focus on time. Because migrations are never quick.
“The truth is that repeated data migrations are painful, expensive and time-consuming.”
Vendors may claim that a data migration project will take 90 days. But in practice they can swallow up a year or more. There are a few reasons. The vendors will probably try to sell you on their latest and greatest model, but moving data to a different platform can increase the complexity of the project. Switching from VNX to Isilon, for example, or from NetApp 7-Mode to Clustered ONTAP. If you’re changing manufacturers, this process can be even trickier.
Unforeseen Complications Can Extend the Project Timeline
- Application Dependencies – Often, a group of applications need to be migrated at a single time. With Sharepoint, for example, you’ll need to migrate the relevant web content servers, SQL databases and file backups simultaneously. At a large company, that might involve dozens of servers. This isn’t just a degree-of-difficulty problem: If you’re not extremely careful planning this migration, you could interrupt service for end users.
- Change Windows – Implementing the migration requires creating an outage to complete and test the cutover. But downtime barely exists in large companies today. Manufacturing facilities often run 24/7. Businesses operate on the weekends. The distribution of offices across regions and countries means it’s always normal hours somewhere. This leaves you with a limited number of opportunities for outages. Some of the enterprises I’ve worked with only had 10 of these change windows a year – but they needed 15 windows just to complete the migration.
Three months or eighteen months, these delays aren’t just frustrating. They’re expensive and inefficient. If you buy a system and can’t install it for 12 months, you’re chewing through the service contract, losing dollars while your new asset depreciates.
Even if the refresh cycle is five years, not three, you’re still losing 20% of the value of the contract before you use the machine. Would you sign up for a three-year car lease if you had to keep the vehicle in your garage for the first year?
This extended, uncertain timeline is only one of the hidden costs. In my next post, I’ll review several more, and explain why enterprises should never have to deal with another refresh-driven data migration project again.
These vendor-driven data migration projects force companies to take on a whole set of potentially expensive and damaging risks, including: opportunity cost, data corruption, data loss, and shadow IT.