Data migration planning: Key things to remember

Putting together a comprehensive data migration plan now can help firms avoid serious downtime later, according to experts.

Making sure that data migration projects go smoothly is largely a matter of getting the right executive backing, understanding business objectives and coming up with a comprehensive plan that accounts for aspects of data migration that are often overlooked, according to experts.

Not to be confused with database migration, data migration involves translating data itself from one platform or device to another, and experts say data migration projects are usually undertaken to optimize, consolidate or save money on resources.

One of the first things to do when planning for data migration is to make sure that all the department heads to be affected by the project are on board, and be sure to communicate with them early and often.

"You have to get full buy-in from the applications that are going to be affected and the owners of those applications," said Bill Peldzus, director of storage architecture with Framingham, Mass.-based technology consultancy GlassHouse Technologies Inc. "I believe you can never over-communicate any type of data migration initiative."

It's also important to get executive-level backing for the project, according to David Mancusi, a global solutions director with Avanade, a joint venture of Microsoft and Accenture that, among other things, helps clients conduct data migration projects. And the best way to get executive-level backing is to understand and then present the business reasons for the project to the company brass.

"First become very clear on why it is that you want to do this and what it is that you are trying to accomplish from a business standpoint, because that ultimately shapes a whole bunch of the rest of your decision making," explained Christopher Burry, Avanade's Americas director for infrastructure services. "If you're doing a data migration because you need better resiliency, well that leads you down one path. If you're doing data migration because of compliance issues, it may take you down a different path."

Data migration is almost never done simply for the sake of data migration, Burry said. It has to be tied back to something in the business, and IT managers need to generate their case around those business anchors.

"It's like, 'If I do all this then I can get better intelligence on my customers, and I can increase our customer retention, etc., etc.' But it's not as straightforward as, 'I can cut the growth of our storage in half,' " Mancusi said. "Data migration doesn't by itself have a business benefit, but a lot of times, IT organizations are challenged in terms of how to tie the outcome to enabling something that does have a business benefit."

Once the business reasons for the operation are identified, it's time to present the case. Mancusi said it's also a good idea to clearly define for executives the service levels that are going to be involved in the project beforehand, especially when the initiative involves mission-critical information.

"It just never ceases to surprise me how often I run into situations where the IT management teams have not decided or defined objectives for their IT infrastructure," Mancusi said.

When collaborating with team members and department heads to create a comprehensive data migration plan, it's important to consider all the details. According to Peldzus, several aspects of data migration are often overlooked during the planning phase.

"The first thing is the time that it actually takes to move that data," Peldzus said. "If you're copying it, for example, over a wide area network [WAN], what your anticipated speed [is for] getting x amount of terabytes from one location to another is sometimes overlooked."

IT managers can work with local area network (LAN) or WAN service providers to calculate how many gigabytes of information can be moved per hour based on the size of the connection.

"If it's a T1 versus an OC 12, that's definitely a difference. But there is also a difference between the latency and bandwith of that connection. For example, I can't speed up the speed of light," Peldzus explained. "So, depending on where I'm migrating to, there is going to be an inherent delay in getting data from one side to another. When [I] get a bigger or a fatter pipe, it just means that I can do more of the data transfers concurrently, but it doesn't necessarily mean that each of those streams is going faster. It's just more that I can do at the same time."

Organizations that plan to back up data onto tapes and ship the tapes over to the new location should carefully consider timing as well, because such operations often take longer than expected, and that can result in additional downtime, Peldzus said.

Next, he said, remember to consider how complex business applications such as those provided by SAP or Oracle-PeopleSoft depend on information in all its different forms. Getting those applications to run properly following any migration-related downtime means moving the information they depend on at a consistent point in time.

"Think of companies that take orders on the Internet. You log on and you're a new customer and you order whatever, and that order is going to be placed and shipped and we'll mail you a bill," Peldzus said. "Now, imagine if all of those systems were moved at different times. We would have customers without orders, orders without shipments, and shipments without billing because all of those interdependencies weren't taken into consideration."

Performance characteristics also need to be considered. Firms migrating data to a new platform or doing some type of consolidation should do some careful planning with regard to how I/O is performing at the original location versus how it will perform at the final destination.

"Another example of the performance issue is mixing the wrong types of applications on the same platform," Peldzus said. "A data warehouse versus an OLTP type application has different I/O characteristics, and if you start mixing those types of applications on the same type of storage array, you might not get the same performance that you had originally."

Another thing to plan for is when it's time to quit. Peldzus said that, too often, firms forget to decide beforehand exactly what it will take for them to back out of projects that aren't going well.

"If you decide to back out later rather than sooner, sometimes that's going to affect your availability because to get everything back to the way it used to be takes a significant amount of time," he said. "So, understand what your milestones during your migrations are, what you can do to mitigate risk and those key sign-off points."

Finally, plan to run comprehensive migration tests, because it's not a good idea to go into a data migration cold.

"I would do a full-blown test before actually cutting over," Peldzus said, "to improve my confidence level that this is going to work as advertised."

Dig deeper on Database management system (DBMS) architecture, design and strategy

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchAWS

SearchContentManagement

SearchOracle

SearchSAP

SearchSOA

SearchSQLServer

Close