Transcript of a sponsored BriefingsDirect podcast on proper planning for data-center transformation and migration.Listen to the
podcast. Find it on
iTunes/iPod and
Podcast.com.
Download the transcript.
Learn more. Sponsor:
Hewlett-Packard.
Dana Gardner: Hi, this is
Dana Gardner, principal analyst at
Interarbor Solutions, and you’re listening to
BriefingsDirect.
Today, we present a sponsored podcast discussion on the crucial migration phase when moving
or modernizing
data centers. So much planning and expensive effort goes into building new data centers or in conducting major improvements to existing ones, but too often there's short shrift in the actual "throwing of the switch" -- in the moving and migrating existing applications and data.
But, as new data center transformations pick up -- due to the financial pressures to boost overall IT efficiency -- so too should the early-and-often planning and thoughtful execution of the migration itself get proper attention. Therefore, our podcast at hand examines the best practices, risk mitigation tools, and requirements for conducting data center migrations properly, in ways that ensure successful overall data center improvement.
To help pave the way to making data center migrations come off nearly without a hitch, we're joined by three thought leaders from
Hewlett-Packard (HP). Please join me in welcoming
Peter Gilis, data center transformation architect for HP Technology Services. Welcome to the show, Peter.
Peter Gilis: Thank you. Hello, everyone.
Gardner: We're also joined by
John Bennett, worldwide director, Data Center Transformation Solutions at HP. Welcome back, John.
John Bennett: Thank you very much, Dana. It's a delight to be here.
Gardner: Arnie McKinnis, worldwide product marketing manager for Data Center Modernization at HP Enterprise Services. Thanks for joining us, Arnie.
Arnie McKinnis: Thank you for including me, Dana. I appreciate it.
Gardner: John, tell me why migration, the process around the actual throwing of the switch -- and the planning that leads up to that -- are so essential nowadays?
New data centersBennett: Let's start by taking a look at why this has arisen as an issue. It makes the reasons
almost self-evident. We see a great deal of activity in the marketplace right now of people designing and building new data centers. Of course for everyone who has successfully built their new data center, they have this wonderful new showcase site, and they have to move into it.
The reasons for this growth, the reasons for moving to other data centers, are fueled by a lot of different activities. Oftentimes, multiple factors come into play at the same organization.
In many cases it's related to growth. The organization and the business have been growing. The current facilities were inadequate for purpose, because of space or energy capacity reasons or because they were built 30 years ago, and so the organization decides that it has to either build a new data center or perhaps make use of a hosted data center. As a result, they are going to have to move into it.
It might be that they're engaged in a data-center strategy project as part of a data-center transformation, where they might have had too many data centers -- that was the case at Hewlett-Packard -- and consciously decided that they wanted to have fewer data centers built for the purposes of the organization. Once that strategy is put into place and executed, then, of course, they have to move into it.
We see in many cases that customers are looking at new data centers -- either ones they've built or are hosted and managed by others -- because of green strategy and green initiatives. They see that as a more cost-effective way for them to meet their green initiatives than to build their own data centers.
There are, of course, cost reductions. In many cases, people are investing in these types of
activities on the premise that they will save substantial
CAPEX and
OPEX cost over time by having invested in new data centers or in data center moves.
Whether they're moving to a data center they own, moving to a data center owned and managed by someone else, or outsourcing their data center to a vendor like HP, in all cases you have to physically move the assets of the data center from one location to another.
The impact of doing that well is awfully high. If you don't do it well, you're going to impact the services provided by IT to the business. You're very likely, if you don't do it well, to impact your
service level agreements (SLAs). And, should you have something really terrible happen, you may very well put your own job at risk.
So, the objective here is not only to take advantage of the new facilities or the new hosted site, but also to do so in a way that ensures the right continuity of business services. That ensures that service levels continue to be met, so that the business, the government, or the organization continues to operate without disruption, while this takes place. You might think of it, as our colleagues in Enterprise Services have put it, as changing the engine in the aircraft while it's flying.
Gardner: Peter, tell me, when is the right time to begin planning for this migration?
Migration is the last phaseGilis: The planning starts, when you do a data-center transformation, and migration is actually
the last phase of that data center transformation. The first thing that you do is a discovery, making sure that you know all about the current environment, not only the servers, the storage, and the network, but the applications and how they interact. Based on that, you decide how the new data center should look.
John, here is something where I do not completely agree with you. Most of the migrations today are not migration of the servers, the assets, but actually migration of the data. You start building a next-generation data center, most of the time with completely new assets that better fit what your company wants to achieve. This is not always possible, when your current environment is something like four or five years old, or sometimes even much older than that.
Gardner: Peter, how do you actually pull this off? How do you get that engine changed on the plane while keeping it flying? Obviously, most companies can't afford to go down for a week while this takes place.
Gilis: You should look at it in different ways. If you have a disaster strategy, then you have multiple days to recover. Actually, if you plan the disaster in a good fashion, then it will be easy to migrate.
On the other side, if you build your new engine, your new data center, and you have all the new equipment inside, the only thing that you need to do is migrate the data. There are a lot of techniques to migrate data online, or at least synchronize current data in the current data centers with the new data center.
Usually, what you find out is that you did not do a good enough job of assessing the current situation, whether that was the assessment of a hardware platform, server platform, or the assessment of a facility.
So, the moment you switch off the computer in the first data center, you can immediately switch it on in the new data center. It may not be changing the engines online, but at least near-online.
Gardner: Arnie, tell me about some past disasters that have given us insights into how this should go properly? Are there any stories that come to mind about how not to do this properly?
McKinnis: There are all sorts of stories around not doing it properly. In most cases, you start doing the decompose of what went wrong during a project. Usually, what you find out is that you did not do a good enough job of assessing the current situation, whether that was the assessment of a hardware platform, server platform, or the assessment of a facility.
It may even be as simple as looking at a changeover process that is currently in place seeing how that affects what is going to be the new changeover process. Potentially, there is some confusion. But it usually all goes back to not doing a proper assessment of the current mode of operations, or the current mode of that operating platform as it exists today.
Gardner: Now, Arnie, this must provide to you a unique opportunity -- as organizations are going to be moving from one data center to another -- to take a hard look at what they have got. I'm going to assume that not everything is going to go to the new data center.
Perhaps you're going to take an opportunity to sunset some apps, replace some with commodity services, or outsource others. So, this isn't just a one-directional migration. We're probably talking about a multi-headed dragon going in multiple directions. Is that the case?
Thinking it throughMcKinnis: It's always the case. That's why, from Enterprise Services' standpoint, we look at it
from who is going to manage it, if the client hasn't completely thought that out? In other words, potentially they haven't thought out the full future mode of what they want their operating environment to look like.
We're not necessarily talking about starting from a complete greenfield, but people have come to us in the past and said, "We want to outsource our data centers." Our next logical question is, "What do you mean by that?"
So, you start the dialog that goes down that path. And, on that path you may find out that what they really want to do is outsource to you, maybe not only their mission-critical applications, but also the backup and the disaster recovery of those applications.
When they first thought about it, maybe they didn't think through all of that. From an outsourcing perspective, companies don't always do 100 percent outsourcing of that data-center environment or that shared computing environment. It may be part of it. Part of it they keep in-house. Part of it they host with another service provider.
What becomes important is how to manage all the multiple moving parts and the multiple service providers that are going to be involved in that future mode of operation. It's accessing what we currently have, but it's also designing what that future mode needs to look like.
What becomes important is how to manage all the multiple moving parts and the multiple service providers that are going to be involved in that future mode of operation.
Gardner: Back to you, Peter. You mentioned the importance of data, and I imagine that when we go from traditional storage to new modes of storage,
storage area networks (SANs) for example, we've got a lot of configuration and connection issues with how storage and data are used in conjunction with applications and processes. How do you manage that sort of connection and transformation of configuration issues?
Gilis: Well, there's not that much difference between local storage, SAN storage, or
network attached storage (NAS) and what you designed. The only thing that you design or architect today is that basically every server or every single machine,
virtual or physical, gets connected to a shared storage, and that shared storage should be replicated to a disaster recovery site.
That's basically the way you transfer the data from the current data centers to the new data centers, where you make sure that you build in disaster recovery capabilities from the moment you do the architecture of the new data center.
Gardner: Again, this must come back to a function of proper planning to do that well?
Know where you're going Gilis: That's correct. If you don't do the planning, if you don't know where you're starting from and where you're going to, then it's like being on the ocean. Going in any direction will lead you anywhere, but it's probably not giving you the path to where you want to go. If you don't know where to go to, then don't start the journey.
Gardner: John Bennett, another tricky issue here is that when you transition from one organizational facility to another, or one sourcing set to another larger set, we're also dealing here with ownership trust. I guess that boils down to politics -- who controls what. We're not just managing technology, but we're managing people. How do we get a handle on that to make that move smoothly?
Bennett: Politics, in this case, is just the interaction and the interrelationship between the organizations and the enterprise. They're a fact of life. Of course, they would have already come into play, because getting approval to execute a project of this nature would almost of necessity involve senior executive reviews, if not board of director approval, especially if you're building your own data center.
But, the elements of trust come in, whether you're building a new data center or outsourcing, because people want to know that, after the event takes place, things will be better. "Better" can be defined as: a lot cheaper, better quality of service, and better meeting the needs of the organization.
This has to be addressed in the same way any other substantial effort is addressed -- in the personal relationships of the CIO and his or her senior staff with the other executives in the organization, and with a business case. You need measurement before and afterward in order to demonstrate success. Of course, good, if not flawless, execution of the data center strategy and transformation are in play here.
Be aware of where people view their ownership rights and make sure you are working hand-in-hand with them instead of stepping over them.
The ownership issue may be affected in other ways. In many organizations it's not unusual for individual business units to have ownership of individual assets in the data center. If modernization is at play in the data center strategy, there may be some hand-holding necessary to work with the business units in making that happen. This happens whether you are doing modernization and virtualization in the context of existing data centers or in a migration. By the way, it's not different.
Be aware of where people view their ownership rights and make sure you are working hand-in-hand with them instead of stepping over them. It's not rocket science, but it can be very painful sometimes.
Gardner: Again, it makes sense to be doing that early rather than later in the process.
Bennett: Oh, you have to do a lot of this before you even get approval to execute the project. By the time you get to the migration, if you don't have that in hand, people have to pray for it to go flawlessly.
Gardner: People don't like these sorts of surprises when it comes to their near and dear responsibilities?
Bennett: We can ask both Peter and Arnie to talk to this. Organizational engagement is very much a key part of our planning process in these activities.
Gardner: Arnie, tell us a little bit more about that process. The planning has to be inclusive, as we have discussed. We're talking about physical assets. We're talking about data, applications, organizational issues, people, and process. We haven’t talked about virtualization, but moving from physical to virtualized instances is also there. Give us a bit of a rundown of what HP brings to the table in trying to manage such a complex process.
It's an element of timeMcKinnis: First of all, we have to realize that one of the things that happens in this whole process is that it's time. A client, at least when they start working with us from an outsourcing perspective, has come to the conclusion that they believe that a service provider can probably do it more efficiently and effectively and at a better price point than they can internally.
There are all sorts of decisions that go around that from a client perspective to get to that decision. In many cases, if you look at it from a technology standpoint, the point of decision is something around getting to an end of life on a platform or an application. Or, there is a new licensing cycle, either from a support standpoint or an operating system standpoint.
There is usually something that happens from a technology standpoint that says, "Hey look, we've got to make a big decision anyway. Do we want to invest going this way, that we have gone previously, or do we want to try a new direction?"
Once they make that decision, we look at outside providers. It can take anywhere from 12 to 18 months to go through the full cycle of working through all the proposals and all the due diligence to build that trust between the service provider and the client. Then, you get to the point, where you can actually make the decision of, "Yes, this is what we are going to do. This is the contract we are going to put in place." At that point, we start all the plans to get it done.
. . . There are times when deals just fall apart, sometimes in the middle, and they never even get to the contracting phase.
As you can see, it's not a trivial deal. We've seen some of these deals get half way through the process, and then the client decides, perhaps through personnel changes on the client side, or the service providers may decide that this isn't going quite the way that they feel it can be most successful. So, there are times when deals just fall apart, sometimes in the middle, and they never even get to the contracting phase.
There are lots of moving parts, and these things are usually very large. That's why, even though outsourcing contracts have changed, they are still large, are still multi-year, and there are still lots of moving parts.
When we look at the data center world, it just is one of those things where all of us take steps to make sure that we're always looking at the best case. We're always looking at what is the real case. We're always building toward what can happen and trying not to get too far ahead of ourselves.
This is little bit different than when you're just doing consulting and pure transformation and building that to the future environment. You can be a little bit more greenfield in your environment and the way you do things.
Gardner: I suppose the tendency is to get caught up in planning all about where you're ending up, your destination, and not focusing as much as you should on that all-important interim journey of getting there?
Keeping it togetherMcKinnis: From an outsourcing perspective, our organization takes it mostly from that state, probably more so than you could do in that future mode. For us, it's all about making sure that things do not fall apart while we are moving you forward. There are a lot of dual systems that get put in place. There are a lot of things that have to be kept running, while we are actually building that next environment.
Gilis: But, Arnie, that's exactly the same case when you don't do outsourcing. When you work with your client, and that's what it all comes down to, it should be a real partnership. If you don't work together, you will never do a good migration, whether it's outsourcing or non-outsourcing. At the end, the new data center must receive all of the assets or all of the data -- and it must work.
Most of the time, the people that know best how it used to work are the customers. If you don't work with and don't partner directly with the customer, then migration will be very, very difficult. Then, you'll hit the difficult parts that people know will fail, and if they don't inform you, you will have to solve the problem.
Gardner: Peter, as an architect, you must see that these customers you're dealing with are not all equal. There are going to be some in a position to do this better than others. I wonder whether there's something that they've done or put in place. Is it
governance,
change management,
portfolio management, or
configuration databases with a common repository of record? Are there certain things that help this naturally?
You have small migration and huge migrations. The best thing is to cut things into small projects that you can handle easily.
Gilis: As you said, there are different customers. You have small migration and huge migrations. The best thing is to cut things into small projects that you can handle easily. As we say, "Cut the elephant in pieces, because otherwise you can't swallow it."
Gardner: But, even the elephant itself might differ. How about you, John Bennett? Do you see some issues where there is some tendency toward some customers to have adopted certain practices, maybe
ITIL, maybe
service-oriented architecture (SOA), that make migration a bit smoother?
Bennett: There are many ways to approach this. Cutting up the elephant so you can eat it is a more interesting way of advising customers to build out their own roadmap of projects and activities, but, in the end, implement their own transformation.
In an ideal data center project, because it's such a significant effort, it's always very useful to take into consideration other modernization and technology initiatives, before and during, in order to make the migration effective.
For example, if you're going to do modernization of the infrastructure, have the new infrastructure housed in the new data center, and now you are just migrating data and applications instead of physical devices, then you have much better odds of it happening successfully.
Cleaning up internallyIf you can do work with your applications or your business processes before you initiate the move, what you are doing is cleaning up the operations internally. Along the way, it's a discovery process, which Peter articulated as the very first step in the migration project. But, you're making the discovery process easier, because there are other activities you have to do.
Gardner: A lot of attention is being given to
cloud computing at almost abstract level, but not too far-fetched. Taking advantage of cloud computing means being able to migrate a data center; large chunks of that elephant moving around. Is this something people are going to be doing more often?
Bennett: It's certainly a possibility. Adopting a cloud strategy for specific business services would let you take advantage of that, but in many of these environments today cloud isn't a practical solution yet for the broad diversity of business services they're providing.
We see that for many customers it's the move from dedicated islands of infrastructure, to a shared infrastructure model, a converged infrastructure, or an
adaptive infrastructure. Those are significant steps forward with a great deal of value for them, even without getting all the way to cloud, but cloud is definitely on the horizon.
What we're moving toward, if done properly, is a breaking off, especially in the enterprise, of the security and compliance issues around data.
Gardner: Can we safely say, though, that we're seeing more frequent migrations and perhaps larger migrations?
McKinnis: In general, what we've seen is the hockey stick that's getting ready to happen with shared compute. I'll just throw it out there as what this stuff is in the data centers, kind of a shared-compute environment. What we're moving toward, if done properly, is a breaking off, especially in the enterprise, of the security and compliance issues around data.
There is this breaking off of what can be done, what should be done at the desktop or user level, what should be kept locally, and then what should be kept at a shared compute or a shared-services level.
Gardner: Perhaps we're moving toward an inflection point, where we're going to see a dramatic uptake in the need for doing migration activities?
McKinnis: I think we will. Cloud has put things back in people's heads around what can be put out there in that shared environment. I don't know that we've quite gotten through the process of whether it should be at a service provider location, my location, or within a very secure location at an outsourced environment.
Where to hold dataI don't think they've gotten to that at the enterprise level. But, they're not quite so convinced about giving users the ability to retain data and do that processing, have that application right there, held within that confinement of that laptop, or whatever it happens to be that they are interacting with. They're starting to see that it potentially should be held someplace else, so that the risk of that data isn't held at the local level. Do you understand where I am going with that?
Gardner: I do. I think we are seeing greater responsibility now being driven toward the data center, which is going to then force the re-architecting and the capacity issues, which will ultimately then require choices about sourcing, which will then of course require a variety of different migration activities.
McKinnis: Right. It's not just about a new server or a new application. Sometimes it's as much about, "How do I stay within compliance? Am I a public company or am I am a large government entity? How do I stay within my compliance and my regulations? How do I hold data? How do I have to process it?"
Even in the world of global service delivery, there are a lot of rules and regulations around where data can be stored. In that leveraged environment that a service provider provides, potentially storage is in somewhere in Eastern Europe, India, or in South America. There are plenty of compliance issues around where data can actually be held within certain governmental regulations, depending on where you are -- in country or out of country.
Planning is key -- not only planning the migration itself, but also doing "plan B" -- what if it doesn't work -- because then you have to go back to the old rule as soon as possible and within the time frame given.
Gardner: Let's move to Peter. Tell me a bit about some examples. Moving back to the migration itself, can you give us a sense of how this is done well, and if there are some metrics of success, when it is done well?
Gilis: As we already said in the beginning, it all depends on planning. Planning is key -- not only planning the migration itself, but also doing "plan B" -- what if it doesn't work -- because then you have to go back to the old rule as soon as possible and within the time frame given.
First, you need to plan, "Is my application suitable for a migration?" Sometimes, if you migrate your data centers from place A to place B -- as we've done in
EMEA, from Czech Republic to Austria -- the distance of 350 kilometers gives an extra latency. If your programs, and we have tested them for the customer, already have performance problems, the little extra latency can just kill your program when you migrate.
One of the things we have done in that case is that we've tested it using a network simulator on a real-life machine. We found that the application was not adaptive, or the server was not adaptive for migration. If you know this beforehand, then you remove a risk by just migrating it on its own.
In another customer I saw that people had divided the whole migration process into multiple streams, but there was a lack of coordination between the streams. This means that if you have a shared application related to more than one stream, the planning of the one stream was totally in conflict with the planning of another stream. This means that the application and the data moved without informing the other streams, causing huge delays in real life, because the other applications were not synchronized anymore in the same way they used to be, assuming they were synchronized before.
So, if you don't plan and work together, you will definitely have failures.
Gardner: You mentioned something that was interesting about trying to do this on a test basis. I suppose that for that application development process, you'd want to have a test and dev and use some sort of a testbed, something that's up before you go into full production. Perhaps we also want to put some of these servers, data sets, and applications through some sort of a test to see if they are migration ready. Is that an important and essential part of this overall process?
Directly to the siteGilis: If you can do it, it's excellent, but sometimes we still see in real life that not all customers have a complete test and dev environment, or not even an acceptance environment. Then, the only way to do it is to move the real-life machine directly to the new site.
I've actually seen it. It wasn't really a migration, but an upgrade of an
SAP machine. Because of performance problems, the customer needed to migrate to a new, larger server. And, because of the pressure of the business, they didn't have time to move from test and dev, to acceptance, and to production. They started immediately with production.
At two o'clock in the morning we found that there was a bug in the new version and we had to roll back the whole migration and the whole upgrade. That's not the best time in the middle of the weekend.
Gardner: John Bennett, we've heard again and again today about how important it is to do this planning, to get it done upfront, and to get that cooperation as early as possible. So the big question for me now is how do you get started?
Bennett: How you get started depends on what your own capabilities and expertise are. If these are projects that you've undertaken before, there's no reason not to implement them in a similar manner. If they are not, it starts with the identification of the business services and the sequencing of how you want them to be moved into the new data center and provisioned over there.
We have successfully undertaken customer data center migration projects, which had minimal or zero operational disruption, by making clever use of short-term leases to ensure that business services continue to run, while they are transitioned to a new data center.
In order to plan that level of detail, you need to have, as Peter highlighted earlier, a really good understanding of everything you have. You need to fully build out a model of the assets you have, what they are doing, and what they are connected to, in order to figure out the right way to move them. You can do this manually, or you can make use of software like HP's
Discovery and Dependency Mapping software.
If the size of this project is a little daunting to you, then of course the next step is to take advantage of someone like HP. We have
Discovery Services, and, of course, we have a full suite of migration services available, with people trained and experienced in doing this to help customers move and migrate data centers, whether it's to their own or to an outsourced data center.
Peter talked about planning this with a disaster in mind to understand what downtime you can plan for. We have successfully undertaken customer data center migration projects, which had minimal or zero operational disruption, by making clever use of short-term leases to ensure that business services continue to run, while they are transitioned to a new data center. So, you can realize that too.
But, I'd also ask both Peter and Arnie here, who are much more experienced in this, to highlight the next level of detail. Just what goes into that effective planning, and how do you get started?
Gardner: I'd also like to hear that, Peter. In the future, I expect that, as always, new technologies will be developed to help on these complex issues. Looking forward, are there some hopeful signs that there is going to be a more automated way to undertake this?
Migration factoryGilis: If you do a lot of migrations, and that's actually what most of the service companies like HP are doing, we know how to do migrations and how to treat some of the applications migrated as part of a "migration factory."
We actually built something like a migration factory, where teams are doing the same over and over all the time. So, if we have to move
Oracle, we know exactly how to do this. If we have to move SAP, we know exactly how to do this.
That's like building a car in a factory. It's the same thing day in and day out, everyday. That's why customers are coming to service providers. Whether you go to an outsourcing or non-outsourcing, you should use a service provider that builds new data centers, transforms data centers, and does migration of data centers nearly every day.
Gardner: I'm afraid we're just about out of time and we're going to have to leave it there. I want to thank our guests for an insightful set of discussion points around data center migration.
As we said earlier, major setups and changes with data-center facilities often involve a lot of planning and expense, but sometimes not quite enough planning goes into the migration itself. Here to help us better understand and look towards better solutions around data center migration, we have been joined by Peter Gilis, data center transformation architect for HP Technology Services. Thanks so much, Peter.
Gilis: Thank you.
Gardner: Also John Bennett, worldwide director, Data Center Transformation Solutions at HP. Thanks, John.
Bennett: You're most welcome, Dana.
Gardner: And lastly, Arnie McKinnis, worldwide product marketing manager for Data Center Modernization in HP Enterprise Services. Thanks for your input, Arnie.
McKinnis: Thank you, Dana. I've enjoyed being included here.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening and come back next time.
Listen to the
podcast. Find it on
iTunes/iPod and
Podcast.com.
Download the transcript.
Learn more. Sponsor:
Hewlett-Packard.
Transcript of a sponsored BriefingsDirect podcast on proper planning for data-center transformation and migration. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.
m the HP Discover 2011 conference in Las Vegas. We're here on the Discover show floor the week of June 6 to explore some major enterprise IT solutions, trends, and innovations making news across HP’s ecosystem of customers, partners, and developers.
processes into ITIL v3. We focused heavily on change management, event management, and configuration management. At the same time, in parallel, we introduced the HP Tool Suite, for monitoring and configuration management, asset management, and automation.
