Transcript of a sponsored BriefingsDirect podcast on proper planning for data-center transformation and migration.

1. Careful Advance Planning Averts Costly Snafus in Data
Center Migration Projects
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?

2. New data centers
Bennett: 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

3. 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 phase
Gilis: 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. 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.

4. 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 through
McKinnis: 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.
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

5. 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.
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.

6. 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 time
McKinnis: 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.

7. 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 together
McKinnis: 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,

8. portfolio management, or configuration databases with a common repository of record? Are there
certain things that help this naturally?
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 internally
If 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.

9. 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 data
I 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.

10. 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 site
Gilis: 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.

11. 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.
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 factory
Gilis: 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."

12. 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.