Secrets to Driving a Successful Cloud Migration [Cloud Series Podcast Part 1]

As cloud continues to be a high priority of those tasked with delivering technology solutions to their business, it comes with new and complex challenges. Many IT leaders and cloud architects are under immense pressure to get the business to the cloud quickly. We’re sharing some good advice on driving a successful cloud migration from experts at TDS, Microsoft and NetApp to help them steer clear of some pot holes and wrong turns along the way.

Eric Kraieski, VP of Software at TDS, recently participated in the first of this three-part podcast series focused on how to tackle “The Cloud Migration Conundrum,” hosted by Paul Stringfellow at TechStringy.

Experts from Microsoft and NetApp share their perspective on cloud architecture and migration in episodes 2 and 3.

In his conversation with Paul, Eric shared some important and cautionary tales about where organizations can go wrong in their efforts to migrate to the cloud – as well as some inside guidance on how to get the cloud journey on the right path from the start.

There is a multitude of reasons to migrate to the cloud: agility, flexibility, performance, cost, digital transformation, etc. Your business objectives must dictate your cloud strategy, which is inherently complex.

The discussion highlights the critical importance of good planning, building an understanding of how an organization would benefit from a move — and focusing on business outcomes and goals rather than getting caught up in the excitement of new technology for its own sake.

Finally, Eric shares some advice on how to plan the migration—from understanding your objectives, through to validation, preparation and documentation.

TDS has conducted many complex migrations over the years, and we have adapted a unique methodology to help ensure successful cloud migration projects. We built that experience and proven methodology into our SaaS tool, TransitionManager. The powerful platform was built to capture, aggregate and normalize all IT assets, then orchestrate both the human and automated tasks, using dynamic run books that allow for a standardized and repeatable approach.

It’s a 20-minute episode and easily downloadable on SoundCloud, Apple Podcasts, Stitcher.

Listen now!

Listen to Cloud Series Podcast Part 2: Microsoft’s Sarah Lean on Migrating to Azure

Listen to Cloud Series Podcast Part 3: TechStringy Podcast Part 3: NetApp’s Phoebe Goh on Tactical Use of the Cloud

Welcome to Tech interviews. On this week’s show, it’s a real conundrum to take a look at how you successfully plan and migration to the public cloud and enjoy the show.

Welcome to this week’s show, a three-part series where we will cover one of our hottest topics, the world of public cloud. In the shows I want to speak with a range of cloud architects and migration experts on how to design and build the right cloud platform and how it is finished out to develop a methodology appropriate plan to successfully transition keep on prem platforms to the public cloud. So, to help me look at our topic in this first show I’m joined by Eric Kraieski. Eric, how are you.

Hi, Paul, thanks for inviting me to your show.

You’re more than welcome, as I gotta give thanks for taking some time to join us this week to talk about this kind of, I think, a major issue that many of the businesses that we talked to on a regular basis and the people listen to this show. A problem that they are wrestling with all the time, but before we get into the detail of that why don’t you introduce yourself tell about who you are and what you do.

Sure. So I run the software business for Transitional Data Services (TDS), and more about them than me TDS was established in the early 2000s originally as an IT consulting company. I’ve been with them for about 10 years. We evolved from being a consulting company to really focus on complex hybrid IT migrations, application resiliency, and DR. We offer a SAAS based software platform called Transition Manager, which allows for the full modeling of your full environment and really manage and orchestrate the change from your current state to your future state.

And we spoke before we started recording it that in my day job my experience working with some your services previously in a slightly different way, but actually a lot of the things that I’d like to kind of pick through with you today, with lots of interesting things I think you guys kind of pick up the really good and helpful models for people to use has a lot to do with any kind of transition projects. Either way, we’ll talk a little bit about kind of transition to cloud and public cloud today but I think they’re really good cornerstones, good standard things for people to think about whatever project they’re looking to transition, whatever kind of services and things that can transition to a classical place. When we talk about transition mode you guys have a definition of what we mean by transition and when we talk about cloud transition or cloud migrations you guys have a definition of what that is and what some of the problems are that you see companies come across.

I was wondering to be, it would be appropriate but just give you two short stories or customer case studies that might illustrate some of the challenge. Okay, so in 2015 we created a data center consolidation project for a large Regional Hospital, that’s based on the East Coast, and that’s a hospital network, seven different facilities are full service hospital, and this was a really relocation project that included thousands of servers, thousands of hospital applications and software systems. And once we completed the project, we published a case study with them and prep for the case study we interviewed the migration project lead the CTO and the CIO and the difference in their perspective was kind of fascinating.

So one question that we asked each of them was how they saw the role of cloud in their organization’s future. And so you know these are separate interviews, they didn’t hear each other. So the migration lead went first he said, “What cloud? We’re a hospital! You know, we deal with personal data and we’re governed by HIPAA, we would never use cloud as way to risk.” So there’s the operational perspective. And then the CTO we interviewed next and he said, “Oh, good question. You know, we use the right tool for the right task at hand and so we do use SAAS based software to manage our elderly care facility, so there’s an example of how we’re using cloud today.”

So then we talked to the CIO, and the CIO said, “Let me tell you my vision and first I’ll tell you what we do today. Today we get a call that there is an emergency we dispatch an ambulance the paramedics get to their destination. They take vital signs and relate to the emergency room. And then we know the emergency room, we have the 50-year-old male on his way in he’s having a heart attack, it’s a second heart attack, and that way the ER team is prepared and ready to go.”

And he said, “That’s what we do today. My vision goes way much further. I believe the team should have all the information on the way to see the patient, they know they’re going to see if it’s year old male, he’s having a second heart attack. The premier medic should be able to see known allergies and medical file, and using things like 4g, they stream information back to the hospital. And so he had this vision of digital business transformation for ambulance care.” And, his biggest concern was really, how am I going to get the CTO to approve this from a security and compliance perspective?

So, those are an example where we asked the same question to three different levels of the organization and got completely different responses and it was kind of on their role and concerns.

I have another example; would you like to hear that one?

And again, you raised some really interesting points and it’s a conversation that I’m seeing increasingly in something that we’ve seen already throughout kind of towards the end of 2018, but at the same at least from the compensation fund in 2019, and I did the show started yeah I’m looking forward to 2019, one of the things that came out that was, this is real requirement to people within technology to focus on business outcomes, as opposed to focusing on technology in itself, you know, and even as a technologist inside an organization to be aware of this outcomes, I think that highlights up beautifully in the different focus of the different people you’re talking to and actually the last conversation, he was describing them about it to focus on an outcome not business outcome this case but certainly focus on it, and how technology can provide that. I mean, is that something you are seeing in general you know that you’re seeing this this real shift in focus on business outcomes as opposed to focusing on technology.

That’s exactly the point. We see a much greater focus on the business requirements because if you think about it, it is not sitting there waiting to just change: let’s adopt cloud let’s move to this technology let’s do hyper convergence, less that’s being driven by a top level business need, which could be, to improve profitability, through reduction of expenses or increase market opportunity to digital business transformation. It could be reduced risk to create higher availability systems, and sometimes that’s a reason to go to cloud. And sometimes that’s the reason not to go to cloud. And then the third area would be to achieve business agility, because what I would it knows is that whatever the businesses asking for today. They’re going to be asking for something different tomorrow. And they rather prepare a platform that can adapt to these evolving business needs.

And I think that’s hugely valuable points, you know, definitely play into the conversations I’ve been having this year already that you know this it and that actually we need to focus much more on the outcomes. It cannot be the department that is resistant to change resistance to transition. So we’ve talked before as well they got a good example of this. So, I’m going to share that as well.

Yeah. And actually this is an example of, if you don’t plan things out fully in advance and you think that it’s superficial if you think my green and cloud is pretty easy just move virtual images from point A to point B, and then your new environment, that’s not really the case so in the second example.

There was a fortune 50 company that was going to negotiate a multiyear volume agreement to host thousands of servers in the cloud.

And as they were primarily a Microsoft shop, it seemed like a logical choice to be signed the deal with Microsoft Azure. So now the surprise here is that it’s going to take them more time and more manpower to move to Azure then if they went to AWS or IBM cloud. And the reason is that most of their services were already running on a VMware virtualized environment.

So it would have been much quicker to simply migrate. Those easy to move workloads to AWS or IBM using technology like the MC or HCX from VMware. So at the time decision was made VMware and Azure was not even an option. And I’m not sure it is now, so they began the process of moving as you’re installing one app at a time. The moving the data for each. This was so more costly than if they would have just use the migration tools from AWS for IBM cloud. So that’s another example if you don’t plan things out. You may make some catastrophic mistakes. Being in a four year agreement for something that is the harder path, what seemed like a good decision to highlight that.

One of the questions I had in my head is that as we look at this kind of idea of cloud transition. You know to maybe for the listeners to try and put some perspective around the, what are some of the problems that you see as organizations take on some of these kind of transitioning migration projects that I think it that like example is probably actually my experiences is a great example of the number one thing that I think people come across is that one. It’s kind of almost falls into two parts, one that they think a successful cloud migration is really straightforward because they’re not just click a few buttons and it magically appears, and two is sometimes it’s either not fully understanding where they’re heading, or not fully understanding where they’re starting and the amount of projects and I started kind of the intro to this episode talking about that I think a lot of the things that you guys do things out of a previous experiments are you doing a valuable kind of malleable stage is invaluable strategies for people to any kind of project. And I think that idea of actually knowing where you’re headed fully understanding where you’re heading fully understanding where you’re starting a real good, you know, really crucial element to have any good successful project. I mean, but I’m kind of jumping in saying is that one of the things that you see as a, as a key issue when people are going through transition and migration project so maybe I should actually ask you is that the key thing that you that you see as people go through those projects?

They need a line around the business goals, that’s for sure. And then they and they need to really take a step back and not rush to we see too much like ready fire aim. So, they may do some research they find a tool. This tool can move a VM image from point A to point B, they go and they do a test run. And they don’t want to make the test too difficult, so they picked the easiest to move workloads it’s, it’s a self-contained application on a single server. There are no dependencies to external applications.

The storage is local, and they may say okay let’s see how long it takes for us to move five of these things and they move five of them, and they say wow okay that that was pretty quick and it was easy. We did a prototype. Let’s buy this tool.This transfer Transfer Tool and then we’ll move on.

And the reality is that if you focus on the easy things first you’re going to fail because success requires you to move up the stack and take an application view of things and if you don’t take an application view you’re just going for a crash landing on the migration that probably won’t work. So, so we try and get people to think more strategically and take a little bit more time on the front end. So we tell them to move up the stack and take this application approach.

The other thing is that they have these disparate tools and the enterprise that are required to make decisions and execute. They may have different ideas some systems like ServiceNow that has some information about their environment. They may have some auto discovery tools that they use to learn more, and to help make decisions.

None of these systems, by the way, auto discover any kind of business requirements. So if you have uptime requirements or contractual issues or data security requirements. They don’t even address that. And so you may get very far along the project and start over, or cancel login migrations. Because of the risk and compliance and security issues. So you really have to look at all of them the profitability impact the risk impact in the agility impact capital, evaluate on all three accesses be successful.

Maybe try and put it in a nutshell so he’s actually one of the biggest things that you see because I think probably as a technologist and maybe as much but listen to the show probably our technology side to produce it decision makers, is one of the biggest risks that actually they look at the technology, and I really liked that idea of don’t pick the simple things first because actually that doesn’t really give you a great example of the complexity of the problem coming but actually that the major issue they come across you say don’t look broadly enough they’re not talking to the business you talked before about aligning your migration and transitions to business goals now is probably lose one thing that people could take from the biggest mistake people make is it that that they don’t really look broad enough they don’t engage in not that their organization to kind of fully understand the impact of what they do.

Yes, they don’t look broad enough and also, they’re very siloed and I mean within IT, they’re very siloed. So if I need to move an application. And that application has external storage, and then maybe as an e commerce application will also talk to my warehouse system, check on availability of product names talk my earpiece system they have to talk to my payment processor system. So, so in this case an application. That’s it, a lot of different things. And there are many different stakeholders. And so this idea that you just move a virtual image, as opposed to, you actually look at your full end to end application. You’re, it really requires you move up like that to be able to factor out the risk. Make sense?

Yeah, it does. And it should probably think about so we talked about before we started recording. And I made, probably a week yeah we went to a little bit of a kind of a rough outline agenda, you know, for people listening we don’t script all of this stuff you know we we do have kind of an idea of some of the areas that we want to talk, and I’d said about the idea of companies migrating data, as you pointed out this guy I think if you willingly described there that this goes way beyond moving some data from on prem data center into a public cloud you know this goes well beyond that it’s looking at an application stack, looking at the impact of that application of applications and again maybe that’s question to you is that a common mistake as well we’ve been just focused on the data relevant and really think about all the other all the other aspects of what sits in from that data?

Yeah, but I think it’s just not knowing how to get what we see as a common, so if you look at all these different kinds of IT projects, whether it’s a data center migration. A resiliency er Dr. Whether it’s a migration to cloud. Every one of these should have a fairly similar roadmap. And that’s, you should first identify your objectives. What are you trying to achieve, is it that you’re trying to achieve, no unplanned downtime? Well that’s a lot different than cost reduction. As your, then you look at your goals, how are you going to achieve the objective. What are you doing, what initiatives, you need to do in order to achieve those goals. Then you have assumptions, what is your current environment, then you need to validate your environment because you can’t plan and execute unless you really validated, what do you really have, after validation get into planning and preparation. And then you have your go live whether it’s a fail over point for the DR, let’s move to the cloud. And then you have post processing. Maybe they go to decommission something or if it was a fail over you have to fail back.

So what we’ve tried to do this programize steps so that you don’t think out of sequence, what happens is people jump right into execution, and they haven’t taken the time to figure out what, what’s the best optimal path where they’re going. If they use the tool that’s focused on just the VM migrations that maybe that’s aligned with a business objective of lower hosting costs, reduce hosting costs, but it’s not doing anything to improve resiliency, because the application would have to be refactor.

So by looking at the application level maybe this is the key takeaway– by looking at the application level–you’re forced to work with the business, you’re forced to talk about what the business impact this by things not working. When we move a data center we don’t have the luxury of saying, we moved everything except your mainframes remove everything except for your virtualized environment. We have to move everything. Includes legacy stuff, the old stuff. And, and this is what companies have to face so they tend to look at the project when it goes off the rails it’s usually too low level too early, and not looking at their top level problem.

So, specifically what, obviously you know you’ve spoken a lot about some of the experiences and some of the challenges that you see.

You’ve got lots of experience in this place, if I’m listening to this and I’ve got a migration project that I’m planning I’m looking at some kind of service transition, what are, three, four top things that you would suggest that something they think about in that plan you know how they how they overcome some of the challenges that we spoke about. You kind of hinted a few of those already with planning and more broadly and kind of business objectives of this book is a kind of a set of rules that you might say to somebody that these are definitely the things that you will be talking about before you start any kind of transition to migration.

Sure. And then, in my way I mentioned one of the problems, was, they don’t take the application view and I’ll give you our advice, but I just want you to couple other challenges with another one is, they don’t know where to start. So they started in the wrong place. They don’t have a consolidated actionable view of their environment. Lots of points was caused by over simplification. And there’s too much reliance on slight little approaches and silo tools which are not oriented towards people working together. So, what we recommend is that you have to move up the stack to the application layer, and you have established visibility across all silos and users and tools that integrate your existing environment. There are hundreds of tools available for analyzing and moving workloads, they’re not the same products. Some people think they are but they all have different purpose. And the question is how do you get these different systems working together as a full system? So you have to establish visibility across all silos and users. We recommend you don’t boil the ocean you break things into manageable chunks, you leverage those existing information and tools wherever it’s available, you focus on your overall end to end orchestration everyone has to be involved with the migration process. And you have to create the news repeatable workstreams. If you have different people in your staff taking different approaches to migration, you’re going to get inconsistent results so you really need to drive standardization.

I think that last point is a fantastic one, I think we’ve probably all been part of projects were seven people are delivering their version of the project that you’re trying to deliver to actually I think standardization and how everybody been aware of their role is hugely important.

So, again, as I said I was interested in kind of some of those more generic tips, but I see you said in the introduction, come across traditional databases, while back in two different roles, different types of projects. And I was really impressed at the time with the kind of approach you guys talk about, but I’m sure not everyone listening to the show is kind of familiar with what it is you do so, you want to give us a little bit of an introduction of what you do and kind of how they help businesses to achieve some of the things that will do with what you’ve talked about so far and overcome some of the challenges?

Sure. So, so we’re, as I mentioned, we started out as a consulting company for complex migrations. In order for us to be able to compete with the big guys we had to take a different approach and so we developed a software tool called TransitionManager, that really allows us to do the things that I’ve been saying allows us to aggregate these various systems that have different ways of storing information.

We have ways of importing everything and normalizing the data so that’s actionable in TransactionManager. So you’re no longer working with the various sources for information, now you’re working within a single environment in TransitionManager as we connect to the downstream tools like VMware in Zerto and others that are doing scheme and others are doing the actual transport layer, and we can actually use our TransitionManager system that really provides the guard rails for customers to drive them along this process that along the lines of you’re saying, moving up the stack and integrating the silos and taking a manageable chunk approach and etc. So we developed this tools that we can compete against the big guys, we now offer that to customers that they can install our software or they can use it as SAAS, and they can manage their own migrations.

Or they can use our team help system with those migrations. And the proof of that. I think we got a right, is that now VMware and IBM have standardized on our tool for their complex for delivering their complex migration.

Yeah, as validation for kind of what you guys do, you don’t get much better than very big, tech giants deciding that your approach and your methodology is the right way to go for them as well. I just pick up on a couple of things you say in there there’s a couple of questions I guess for the TransitionManager is a kind of an orchestration tool so you talked about things like being the tools that you can integrate with it you then kind of take advantage of their capabilities and orchestrate them as part of a transition project, or is it just more about understanding the part they play in kind of building a plan to do the transition or maybe utilizes their capabilities?

Yeah so we are an orchestration system and one of the unique capabilities that we have is that we abstract the ability to create run books or the run books are your step by step sequence of what everyone has to do in the proper sequence to achieve your mission.

And what we’ve done is we created an abstraction layer where we can create these templates of for this type of asset for this type of migration. We basically build the full plan and assign it to the individuals. When it’s time to execute that stuff so that you do everything in the proper sequence. So, that’s how we really pull things together for the client.

I think one of the challenges that we see whenever we do kind of the migration project, is you need to build a documented understanding of existing systems. Is that the kind of thing that you also can do, you know, maybe as part of a runbook? A separate document stack as well as things that people can use long term as well? They can kind of reference back to the documentation and runbook to help them plan services in the future, that kind of thing?

Right, so you need to have a constant view of your environment and so the run the runbook execution, with the ability to create these runbooks at the click of a button. So your environment changed. Now, does your run book completely change? With just click a button it will regenerate. So that’s the unique capability. But what I said was if your environment change so really the first step is to make sure you got this consolidated view of your full environment, and TransitionManager allows that as well. So we can import from your ideas and systems and from your autodiscovery systems and from RV tools and things like that. We have importers that can take the raw output from those systems, and after doing quick importing of those things then you have a full view of your environment that shows what applications require what infrastructure. And the numbers, what infrastructure supporting what applications. So this gives you this kind of 360 view of everything, which I know is kind of a common phrase that people use the 360 view or single pane of glass but the reality is, the other people aren’t really offering that because you have to normalize the data, and may have a single pane of glass for everything storage, you may have a single pane of glass for everything VMware, but you don’t have this aggregate view so that’s very important to what we do is we take these sources on these valuable but disparate systems, and we aggregate into a common view.

You know, one may identify an asset by a name and only identified by IP address no identify it.

So we have to combine that information so that human beings involved are spending a lot of time sifting through data, to give you an example of that. So just go to discovery tool called Cloudscape. And one of our clients used that tool to figure out what’s involved with one of their applications when they found 4200 dependencies for a single application. Now if you’re a human being, which you are! You’re looking at 4200 dependencies, and you think, this is not actionable.

But if you think about it, the, the user got exactly what he wanted. He said, I’m moving this application I need to know everything that might have an impact. And when we actually loaded the information into TransitionManager, we saw what were really first level dependencies, which is really the important piece.

We found it had 2 dependencies. So, so 4200 minus two, was noise.

And that’s the problem that people face it’s just very too much information. They don’t know how the sift and digest that information, we make that for them.

And I think that TransitionManager provides an orchestration element to do help drive the migration services and data and application, you know, if even if it didn’t do that. The thing that you talked from my experience with working on kind of transition migration projects with a with a whole range of businesses over my 20 or so years doing this kind of role. The thing you just talked about, that’s so often, kind of grinds these projects to a stop is fully understanding where the starting point is, fully understanding the impact of what they’re about to do, and the kind of dependencies you’ve touched on you know who is dependent on this application will sort of applications would have the same.

And then something you touched on before as well about how you maintain that kind of documentation and maintain things like those workbooks, even if they have TransitionManager, it would be a hugely valuable tool and cause as we kind of come to the end of our time here and I you know I think the fascinating things towards problem.

Usually areas where people can trip over doing this on some of the good practices that you should be using a TransitionManager you’ve got a really smart tool that people might be able to use, somebody listening to this and nodding along with me they can actually get TransitionManager sounds really, really useful is a way to find out a little bit more about it. I want to look at it or find outf how it operates or try it out, do you guys offer that kind of capability?

Sure, I would suggest that they go to our website, TDSi.com and they should be able to find whatever information they need to get started,  understand what it does, where it fits and then we have the ability there for them to request contact with a specialist that can help them guide them through understanding their requirements.

And you mentioned as well that this is available as a software as a service platform as well so if somebody just has a single project where they’re looking for a little bit help or some, some useful tools and that kind of SAAS platform, perfect for them.

Yeah, we’ve kind of evolved to that, or legacy is these large complex migrations. But where we’re going is, you know, if you think so. Another example would be much simpler migration will be in office 365 migration. Can we currently run our office 365 in house, we want to move to the cloud. You moved it, Microsoft SAS service for that. We’ve, you may need to move thousands of users over multiple thousands of users 10s of thousands years, and you need to make sure they have all their emails and data and files and all that. So we’ve developed.

So we talked about micro use cases like that where it’s very specific that’s narrow.

So that’s one example but there are other ones like that that we’re rolling out.

Well, it’s been a real fascinating discussion for me this because I think it’s, it talks about some of a lot of the problems of it on a day to day basis in a kind of my, my real day to day job you know because much to everybody’s surprise I’m not a full time podcast host. I’ve been probably now having listened to this realize that I don’t do this for a living.

But, I mean, if people will be fascinated by the kind of things you talked about know is your way that people can get in touch with you can they find you online on Twitter or LinkedIn or drop us an email somehow it what’s a good way to get contact with you?

Sure, I can be found at Eric at TDSi.com, or via LinkedIn:

Okay, well I really appreciate time, a genuinely fascinating discussion listening to the show will of get as much from that as I have so we’re really appreciate your time. Thanks from tech interviews and look forward to speaking to you again in the near future. Thanks Eric.

Thank you very much.

I hope you enjoyed our show.