Data Migration Process Video Transcripts

Andy Abbas:      Hello folks. My name is Andy Abbas. I'm with Data Agility Group. I am one of the co-founders of the company. We specialize in data center migrations and relocation services. We've been in business for well over 10 years and our expertise is around mitigating risk and minimizing downtime for our customers in data center migrations. What we'll be going over today is really our key learnings that we've had over the 10 years in doing this and what are the keys things that you need to look for. What are the best practices out there for doing a data center migration? Also, what are some of the pitfalls that could potentially have your migration fail?

Obviously we all want our efforts to be successful and I'll be sharing with you what key areas that you want to focus on to make sure that your migrations are successful. Lastly, we are also going to be discussing the overarching purpose of why organizations do data center migrations. In fact, I'll be discussing all these key areas at the upcoming Data Center World session in New Orleans on September 13, and we hope to see you there. If not, then we'll obviously visit you online.

Andy Abbas:      Hi folks. My name is Andy Abbas. I'm with Data Agility Group. We specialize in data center transitions and we've been servicing our clients for well over 10 years. I'd like to share some of that experience that we have had within those 10 years that we've been servicing.

There are key areas that we need to focus on in any data center migrations. These are best practices that we always employ when we're our doing our projects, and I'd like to share with you what those are. There are five key areas that we always focus on.

First is assessments. We need to be able to find out what your environment looks like today before we can plan on making changes to that environment and moving it to the target location.

Second is to design. Once we find out what your environment looks like, once we have done the assessment, now we want to do a design of how are we going to migrate that environment from where it is today to where you want it to go. That target location could be from on premise to on premise. It could be from on premise to cloud, or it could be from cloud to cloud. The underlying processes are all going to remain the same. The fundamentals are going to remain the same.

Third is implementation. Now that you've assessed your environment, you've designed how your migration is going to occur, you want to actually hit the ground running and make those changes. In the implementation discussion, we'll discuss what are some of the key areas that you need to pay attention to to make sure that you have a successful migration.

Fourth is testing. Very critical. Because when you're making changes which are critical to your business, from moving your environment from one location to the other, you want to be able to make sure that your target environment is functioning exactly the way that your source environment is functioning today. Testing will allow you to do that.

The last but of course not the least is management. We want to be able to have an over-arching project management approach of how do you manage such a large complex initiative like this. Not all migrations are going to be complex. Some of them may be quite simple. But, any time you're making changes within an environment, it brings some complexity to it. You need a project management approach which looks at all the risks that are involved; and that can actually address those risks in working with the subject matter experts before you make that change, during the changes happening, and of course after the change is made.

These are all the areas that we're going to be discussing. I hope you'll enjoy the talk.


Andy Abbas:      Hi folks. This is Andy Abbas with Data Agility Group. Data Agility Group, affectionately known as DAG, we specialize in data center transitions. We've been helping our customers for well over 10 years. What we're going to be discussing today, is the assessment phase of the best practices of data center transitions. There are a total of eight different areas that you could potentially perform an assessment on. Now, that doesn't mean that you have to do all eight assessments but, we're gonna be discussing key areas to kind of give you a taste of what those different assessments are.

First and foremost, is an application assessment. Now, I may spend the most amount of time in application assessment, discussing this with you, because that's probably the most critical. When you're making a transition from a one data center to another data center, you're not only moving hardware, you're actually moving your applications. The hardware is just the foundation of what runs your applications. So, when you're making an assessment of which applications to move, which wave groups to move them in, it's extremely critical.

Because, if you take an application, and let's say, "It has dependencies between different applications", and you move two of the three applications that have dependencies, and you haven't moved the third one, well guess what? Your target data center, where your environment is running with your two applications, it's going to look for the third on, and it will have to go across the wire, if you have that ability still, to your older data center to access your data.

Now, performance is going to be very poor and it may not even work because, you may not have the necessary bandwidth nor the ports opened up for you to access. So, assessments are extremely critical. Next is network and security assessment. When you're transitioning your entire data center, there are a lot of key areas within the network and security that you need to address. Are you going to be upgrading in your new data center? So, when you do the assessment at the source, what are some of the functionalities that you don't have, that you would like to have? What are some of the key things that you want to optimize? Is your security at your existing data center up to par with what your business requirements are, or your client requirements are? Or whatever other regulatory requirements you might have.

Third is an inventory assessment. That means exactly that. We are going to take an inventory of your physical environment. Very critical. Especially if you're not doing a greenfield build. Basically meaning, you're not deploying a brand new environment at your target data center. If you're going to be doing a brownfield, which basically means that you're going to be putting in some new equipment at the target, as well as moving some existing equipment, then you need to do a full inventory. You need to understand what your environment looks like today, before you move it.

That would mean, going on site, taking pictures of your equipment, labeling your existing labels that are there, drawing out a schematic on where your cables are connected, things of that nature. You can be as broad or as detailed, depending on what your requirements are.

The next one is configuration assessment. How are your equipment configured? How is your SAN switch configured? How is your network configured? How is your LAN or SAN configured? How are your servers configured? Are you using your management? Are you using an ILO or an IDRAC? So, those type of things, you need to have a very clear detailed design on what the environment you have in place, looks like today.

Next one is connectivity assessment. What are your connectivity between your external applications that you may have out, living in the DMZ? Or if you have customers that are accessing your applications in your data center? How about, your access to the new data center because, obviously we're going to need to migrate the data from one data center to another. We need to make sure we have that connectivity assessment done so that we can determine what our requirements are going to be, in the subsequent phases we'll be discussing.

Next one is a process assessment, very key. Right now, you're operating on a day to day business. You are looking at your day to day business with processes that you have in place, for normal SLAs. When you're doing a data center transition, you may not be in a position to follow the same SLAs. For example, you find out during a move that you need to purchase an HBA for a server. Well, your procurement process may be three weeks, maybe a month, or maybe only one week or two day. You need to make sure that you have provisions put in place so that during that timeframe, you can actually order the equipment that you need, in a lot more expedient manner, than what your standard SLAs are.

Next one is cabling assessment. We want to be able to look at your cabling that you have in your data center because of course, there are several factors that come into play. Number one is, you want to be able to document, so if you're moving your gear from your source data center to the target, that your cabling is indeed identical to what it is at the target data center. So, you need to be able to map out your cabling. You need to be able to do an elevation map of how your racking is going to be.

Now, no one wants to think about this but, what if you have to back out? Meaning, that "You fork lifted", let's say, and you've shifted your gear from your source to the target data center but, you have to back out for whatever reason. Well, if you don't have a cabling assessment done and document all your cabling, when you ship the hardware back, how are you going to connect all your cables? So, that's a critical path.

The last is, I think I've already gone through eight of them but, I can give you one high one, is you need to do a full data center assessment. You need to be able to look at, what are some of the key things that you may be missing, that need to be addressed when you're migrating. Most organizations don't even realize that they have servers out in there, that they may not have in their master server list, for example. But, when you do your assessment, where you look at every single component in your data center, you will be able to catch that and be ready for the design phase of this project.


Andy:                    Hi folks, I'm Andy Abbas with Data Agility Group. Now that we're complete with discussing the assessment phase, and I hope that was helpful to you, we'll be going into the design phase of it. The design phase is where you actually take the information that you've gotten during the assessment process and design your migration strategy.

How are you actually going to perform the migration? The first thing you want to look at is the application grouping. We referenced that briefly under the assessment phase of it, but it's very critical and I want to reiterate. Whenever you're doing a migration, your design should be around your applications. The hardware itself obviously is very critical. You may be virtualizing, you may be doing it physical to physical, you may be doing a physical to virtual, you may be doing a virtual to virtual. Regardless of what that is, that's still the foundation, but what runs on that environment are your applications. You need to be able to group those applications so that when you're performing the migration, it is not risking your day to day operations and your application work load.

Second is you want to develop a migration method. How are you going to migrate? If you're going from a physical to physical, are you actually going to take the image of the server and deploy it on the new server, or are you going to build a new server and only migrate the data. If you are doing a virtual to virtual, how are you going to do that? Are you going to do that over the wire. Are you going to do it where you capture it locally onto some swing storage, and then ship it to the target location and then replicate the deltas? Because a lot of these things have a very, very critical approach to what your requirements are going to be for your infrastructure. For example, if you're doing a swing approach, your bandwidth requirements are going to be a lot less than if you're doing a over the wire migration replication approach.

Then you want to prepare a risk analysis. There are different methodologies to do a transition. One is to shut down everything and move it. Obviously there are risks inherit to that. One risk for example is the server doesn't come up on the target location, but you've got data on there that you need to get. There are some things that we can do to even mitigate risks against that, which is to capture the data locally in the source data center before you shut it down. We call that the risk assessment or risk mitigation process.

Second is you want to be able to assess what the impact is going to be on your applications. How much downtime can your applications sustain? Do you have an application that is run 7/24? Healthcare is a critical area, because healthcare obviously never sleeps. If you are a hospital that's migrating your environment, how are you going to mitigate against risks. What kind of back ups are you going to have available in the event that something goes wrong with your application. How much downtime can you sustain? What are some of the timeframes that are least impacting to your environment? So a lot of those risk assessments will need to be done.

Then you also need to develop a migration plan. What's going to happen during wave one, wave two, wave three, what are some of the steps? Typically in a migration plan, you're going to document the tools that you're going to need. You're going to document what is the process flow. How are you going to actually migrate the date from your source environment to your target? Are you going to do a file level migration or are you going to do a block level migration? A lot of these things come into play quite a bit when you're doing these migrations because the design phase of it, is what's going to dictate how well your migration's going to go and often times, we have migrations where we may have multiple designs developed for different types of applications. Some applications can sustain a downtime and we may do a forklift. We shut the server down, we ship it to the target and we bring it back up, but obviously making sure that we mitigate risk by capturing the data before we do that.

Other migrations, we cannot afford any downtime, so we need to look at methodologies that we would migrate the data while the server is still, or the application is still in use. All these things are definite areas that you want to focus on when you're looking at, or when you're doing your design phase of the migration effort.


Andy Abbas:      Hi, folks. I'm Andy Abbas with Data Agility Group. Now we're on to the third topic. We've already talked about the assessment phase, the design phase, and now we're into the implementation phase. This is where the rubber meets the road. We are going to discuss two key areas that are going to be critical in any data center migration. One is the logical piece. The other one is the physical piece. The logical piece is important, because that's where we actually move the data in the applications. The physical piece is where we move the hardware from one location to the other.

Let's look at the logical piece first. What's required in the implementation? One is, we've already decided how we're going to move the data. We've decided what tools we're going to use and we've decided what methodologies we're going to use to migrate that data that we're looking to transfer. Now, in that you may have tools that need to be deployed. What does that mean? Infrastructure requirements. It means that you need to get your source environment and your target environment ready for those tools to be accepted. It may be servers that you deploy out there. It may be temporary storage that you deploy out there. It's very critical to do that.

You also are going to implement any tools that need to be applied to the hosts themselves. What if you're installing an agent on doing a host space migration? Well, when you're doing that, it requires you potentially to do a reboot. If that's the case, you need to plan that out. That's an implementation step. How are you going to replicate the data? Are you going to be using swing storage, as we discussed in the previous assessment phase as well as the design phase, or are you going to be doing it over the wire? A lot of these things will come into play in quite detail.

Are you going to quiesce your environment, meaning shut it down so that you can have a clean image for testing at the target before you cut over, or are you just going to get a crash-consistent image when you're replicating to the target? A lot of these things will determine what type of implementation steps you need to take.

Now, let's look at the physical aspect of it. The physical aspect is pretty straightforward. You need to figure out what you're going to move and how are you going to move it. We've already made a determination on what your waves are going to look like, what hardware is going to move in your different wave groups. You need to go onsite. You need to label that. You need to document everything to the T of exactly how things are going to move. Which movers are you going to use? What kind of insurance are you going to be using? Does it need to be climate-controlled? a lot of these things. How long is it going to take for the transition?

Do you have your target environment already prepped? If you're moving hardware from your source location to the target location, you want to make sure that your target environment has all the cabling done before your transition day, because of course, during your cutover  time, you want to be able to quickly unrack, pack, ship, rerack, and recable. You don't want to be running cable during that time; so, a lot of these things are going to be done prior to the cutover, and that's all during the implementation phase of this project.

I hope this was helpful to you. There are quite a few more things that go into the logical and the physical, but I just wanted to give you a very high level view of that, of what's involved during the implementation process.


Andy Abbas:      Hi, folks. Andy Abbas here with Data Agility Group. We've already discussed three areas, three phases that are critical in any data center migration so far. First was the assessment phase, the design phase, and the implementation phase. Now we're going to be discussing the testing phase, equally as important. We want to be able to make sure that the migrated environment is indeed working the way it's supposed to be working and it's signed off on by the respective parties, such as the application owners and the business owners. There are two types of tests that we typically see when we're doing a data center transition. First is the UAT test, which is user acceptance testing, and the second is a performance testing.

Let's discuss UAT testing first. The key areas that you want to focus on when you're doing a UAT test is, you analyze business. You analyze what their requirements are. What do their applications, what purpose do they serve? How are they being used? Who uses them? Second is we identify the UAT scenarios, what it is going to be involved during the actual testing process. What is the customer wanting to achieve? Is it that they want to press a button and a command happens at a certain timeframe, and it actually accomplishes whatever it's meant to accomplish? Those are some of the things that we want to discuss with the client and make sure that we're documenting those.

Then we want to define the test. We want to document each and every test scenario to know that which applications, if they're functioning the way they're supposed to be functioning. Now some customers may require ... Some organizations, excuse me, may require that all applications be tested, but many times most companies are looking at their critical applications, and if they are comfortable in knowing that those critical applications are functioning the way their function, that they're supposed to be, they're happy with the transition. They may find later on, as they're starting to use the other applications, that some applications may not be functioning as they're supposed to be, and if they're not critical, they'll address them as when they're starting to find out, but most of the times, the critical applications is what's typically looked at for the user acceptance testing.

The next one is performance testing. This is very key. Most organizations, when they're moving their data center from the source, the target, they're looking for improved performance. Where the performance testing really plays a key role is to make sure that you're actually not under-performance to what you were at the source after the migration. Now that could be because of many different things. It could be storage configuration. It could be bandwidth. It could be configuration that was potentially missed when you were doing your waves break down and you've left an application at your target data center, which should have moved with during that wave and because it has a dependency. A lot of those things. Are the database servers in the same data center that they're supposed to be in? A lot of things will be caught during the performance testing. Now how does that happen? Typically performance testing, you do a baseline testing and the baseline testing will give you what the performance is for that particular application at the source data center.

Again, same thing as UAT. You will actually be selecting a certain set of applications that you want to test. After you do the baseline, we do the migration. After the migration, we would do another benchmark test. You want to figure out that the performance that you were seeing at the source are indeed the same at the target, so in that scenario, it allows you to know that you're in a better state if not the state as you were at the source. Now most companies typically always have some level of testing done, either UAT or performance. They may not formally classify it as such. You may not actually say that it's a performance test, but then they start complaining, "Well, my application is responding slower than what it should be."

What that means is, you need to start investigating what some of the issues could potentially be. Now if you had actually done a baseline testing before, you can actually test that quite a bit more effectively because you have data from how your environment looked like from day one versus your target environment. I hope this was helpful. Next, we're going to be discussing the management phase which is, again, extremely critical to any data center migration.


Andy Abbas:      I'm Andy Abbas with Data Agility Group. Now, this is the fifth and last of the topics that we're going to be talking about during this data center transition best practices. First we talked about the assessment phase, then the design phase, then the implementation phase. We just completed the testing phase, and now we are on to the management phase. Now, the project management phase is one that holds everything together. Because your project manager there or program manager, has the responsibility of making sure that all the previous steps, all the previous phases that we spoke about are happening in an effective manner and they're actually happening the way they're supposed to be happening.

There are several steps that we believe are best practices in the project management aspect of, within a data center transition. First is you want to develop a project scope. You want to figure out what is the project going to entail. You want to do your due diligence. You also want to identify any risks and tracking of issues that may come up. Because a migration can be very complex, if you don't have a very, very sound project management behind it, it's only going to make things worse. You're not going to have a cohesive approach to doing a transition. You need that one person or that one group who is ultimately responsible for the entire transition. You will have different subject matter experts within the organization, but, the person who is going to have that responsibility for the entire transition is going to be either the project or the program manager.

Second, you want to develop a signed program charter. What does that mean? That means that you need to get buy-in from your management. Now, how many of you have actually done projects where you don't have a buy-in from your business owners, or your ... All the way to the C-level? You won't get the support. You won't get the flexibility that you need. One of the things that we talked about before was your procurement process where you need to, and during a transition you may be able to get something quickly rather than follow your process that may give you a three week SLA. You need to be able to get your buy-in from your management. Very important.

The other thing that within this realm of a charter is you need to be able to put together a communication plan. You need to be able to say if escalations need to be made, who are they going to go to? How are you going to be escalating? Who are the business owners? Who are the managers of the different SMEs that you're working with?

Next, you need to develop the good old project schedule. Everyone loves a schedule. Everyone loves to know exactly what's going to happen when. Very important. The only way projects can sustain on schedule, and on budget, is to have a formalized approach on how you're going to do things and have milestones documented. Also, timelines. We've been in situations in the past, and I'll share with you where the customer comes to us and say, "We've got to be out of a data center in three months," whereas the ideal situation in that scenario should have been six months earlier. But, we have to do what we have to do.

Now, in this scenario, we have to have a very aggressive schedule. So what does that mean? That means that the business owners have a lot at stake because they have to be out of a data center. The management have a lot at stake and also the subject matter experts have a lot at stake. So everyone has to have the buy-in. Everyone needs to understand what your deliverables need to be for you to be able to make that timeline, and then we initiate the project.

Initiating the project is where again the rubber meets the road because in that scenario, you're going to have to maintain your schedule. You're going to have weekly, maybe daily conference calls with the DBAs, with the systems administrators, with the application owners, with the storage team, the network team. Data center migrations are very complex, so you're going to have a lot of team members coming through, coming together to discuss what needs to be discussed.

Typically, most organizations approach it in two fashions. One is they meet as an application group and then within it, they will meet with the different IT groups because if you have several applications that are shared between different infrastructures, well you want to be able to concentrate on an application-centric approach and then also engage the underlying foundational or infrastructure IT departments that are responsible for that.

One of the things that I will share with you as my parting message on the management piece of it is lessons learned. Everyone is human. We all learn as we go through. We learn in every migration that we go through every day. So, you want to be able to take those lessons learned and you want to apply to subsequent phases or subsequent waves. That's the only way you're going to improve and every environment is extremely different, so you want to be able to look at your environment. Look at what actually needs to improve from the last time you did the migration. So if you're doing let's say five waves, how is wave one different than wave two, than three, four, five. You should definitely be improving and you may find different things within each wave, but the goal is that you always are continually improving and the project manager is the one who's really going to make sure that those lessons learned are included in every subsequent wave that goes on.

I hope you enjoyed this session and the discussions that we've shared with you on our lessons learned, and we hope to see you at the Data Center World which is scheduled in New Orleans this coming September, and if you do come by, please stop by at my session, or if you see me in the hallway or at the convention center, definitely come by and say hi. Thank you very much.