“Good afternoon, everyone. I’m Brandon McCurchen, senior manager, sales engineering at LogicMonitor.
And I’ve got here today with me, Ron Ron Weddle. We’re here to talk today about, a few things. We’re gonna go through a quick introduction, and then talk about unified observability with my four migrations, as well as the VMware modernization, through observability, and then we’ll do a quick panel discussion.
Today, we’re gonna talk more specifically about how logic monitor can help during these, migrations, through your observability journey, whether that’s through VMware or from VMware to AWS or from on prem to, in the cloud or or a hybrid mix. LogicMonitor is the place to use, or the platform is the tool to use in this, endeavor in before, during, and after stages.
During your planning, stages, your informational collection and, is is complicated and time consuming. Things are missed, overlooked, and most importantly, debt tech debt is uncovered.
We utilize our features like NetScans and active discovery, to assist in these endeavors, allowing you to, discover your environments, new and old, while you go through these migrations.
During the migration execution, you can utilize logic monitors, out of the box alert thresholds for proactive call calling attention to known bad conditions, as well as utilizing service insights to detect and provide clues, to those root causes.
Obviously, the VMware migration will have a lot of moving parts that you wanna match, as you migrate. You wanna keep your eyes on both the before and after pictures so that you can get the get there fastest.
As you go through the planning phases, like I mentioned, active discovery is where you’re gonna be able to utilize and maintain that you’re you’re monitoring the same aspects of your infrastructure in the old and infrastructure in the old and in the new. So post migration, you have the prettier picture, and you can take action, accordingly.
As we mentioned, the bigger hybrid picture, this utilizing things like Resource Explorer and Resource Explorer and our cost utilization side of things with LogicMonitor, you can get the bigger picture of your hybrid observability, utilizing LogicMonitor’s excellent coverage with AWS services. And you can get a comparison between your AWS environment and your VMware environment. Side by side comparisons, both before and after and in new and and old technologies, is invaluable. Being able to detect that you have the same infrastructure running and is running better or if not, I mean, yeah, better than, hopefully, your previous, environment. You wanna make sure you utilize logic monitor to tell you that story and maintain both before and after stages.
And these are the several services linked into from or monitored from LogicMonitor, and we will be talking to, Ron here in a moment, asking him a few questions about his endeavors with customers on those migrations.
Alright, Ron. If you’re ready for the questions, we’re just gonna jump right in.
Sounds great.
Alright. In your in your experience, what are are some of the most common challenges, the customers encounter when they migrate workloads from VMware to AWS?
I I think one of the biggest, challenges is that it is a different platform or it’s a different technology. Right? So they’re they’re coming from an on premises workload where they’ve historically been using the same interface for years. And so in AWS, things are in different places.
And so one of the the challenges customers have is the lack of visibility. Right? They don’t know where to look. They don’t know what metrics to pull.
And so they they get lost or there’s opportunity for poor performance, oversized or undersized for, e c two instances or and by extension, cost. They, it can get very expensive if you aren’t rightsizing the workloads. And so without a a tool like logic monitor to help provide that visualization, it it can be it can be a very expensive endeavor for us.
Indeed. What are some of the common negative business impacts that customers can encounter, due to the migration?
Yeah. So, again, uptime and and and spend. Right? There there is a a change in technology. So when you’re oversized or, and spending too much money or undersized and not providing the the proper performance and, experience that customers were used to, in the on premises land, that can directly negative it’s a direct negative impact to the to the business and their by extension, their customers.
How how much of the new technology are are we uncovering as we as these customers migrate from VMware that they’re realizing that that tech debt, like I mentioned earlier in the in the beginning phases, they see, oh, we never touched this part of the platform, so it never improved. And then migrating over, they see it work a whole new way. Like, is there something like that you’ve witnessed?
I’ve actually witnessed, you know, with the way, you know, VMware environments work with the overcommitment. Sometimes there is a a performance hit that they’re not aware of. Right? You know, when they come over to e c two and everything is running as a separate e c two instance, we have seen folks, you know, be more performant, more stable, being able to scale up, scale down faster.
Awesome.
What are some of the most common solutions or methods, for easing the pain for those customers encountering during during and after migrations, actually?
Well, from a method standpoint, it it’s planning out the migration. Right? Generally speaking, at AWS, we do an assess, mobilize, and migrate. Right? The assessment being the discovery of all those on premises workloads, the environment, also assessing readiness, cloud readiness for the customer, making sure that they have executive buy in and all the teams are read ready to go. And if not, that’s where we really get into the mobilize. It’s mobilizing not just the technology, but the people in the process and then getting to the migrate.
So that really helps ease the actual migration itself. Right? Doing the work ahead of time. You get what you put in.
So doing a proper assessment, getting all the visibility, And then some of the pain is during migration is is not knowing where things are. Right? Not having visibility on both sides of that fence while a VM is coming from on premises into e c two. You know, what’s left behind?
How is that impacting the performance of what is in the cloud? And having to juggle between multiple tools to see it all.
Absolutely.
So tell me about the migration preparation process, documentation, requirements, dependencies. How much time do customers spend preparing for that migration?
You know, it’s, the the answer to this, is it depends. Right? It depends on the maturity of the customer in terms of, you know, are they already in the cloud and they they’re they have a hybrid approach? Or is this a complete net new migration?
So it’s unfortunate I can’t give a specific time. Right? Because every environment can be different. You know, there are customers with thousands of virtual machines that can move quickly, and there’s customers with hundreds of virtual machines that, for whatever reason, the way their applications are built or how it interacts with the rest of the business have to go slow.
So I I can say in all of that, it is there’s a lot of work to gather all of those requirements and dependencies. And depending on the customer, they may have it ready or they may need something to do all of the discovery for application dependency mapping or even just insights into their existing workloads.
You mean we can’t just go jump off the deep end and see what happens? That’s not the best plan?
You can. I I just don’t think that necessarily it’ll it’ll have the business outcomes that they’re expecting.
That’s what we’re looking for. It’s it’s a good the positive business outcomes. Right? So what what can you tell us about the differences between customer migration scenarios and, when it comes to, project timelines and technical details? I think this is your favorite question, if I remember correctly.
So the migration scenarios, again, it goes back to the it depends. Right? And when it comes to the project timelines and the technical details, you know, it it can be difficult to give a specific answer on this one because, again, every customer is going to be different, and they’re gonna have a various levels of insight and already knowledge of their existing workloads. And then the time line yeah. I know. I’m not sure I have a great answer for you on this one.
Yeah. The time line is always, you know, what if you know, it depends on how long you spend time doing the preparation or how well you know your systems. You know, like we mentioned before, I think it’s a lot of the like, a lot of depends on those variables and, you know, and then also how much you just wanna jump in.
There’s teams that target say.
Yeah, that the timeline can stretch if you don’t put the the work ahead at the time. Like, in I I discussed kind of the AWS methodology of assess and then mobilize. Right? If you don’t spend a lot of time in that portion of the project, then the migration is gonna take exponentially longer because you’re redoing work because you didn’t spend the time to do the assessment.
Yeah. I I think I liked your your comparison before. It was a smaller environment that took six months versus a larger environment that took, you know, three months. You know? And and the difference was totally based on how they were prepared.
Exactly. Yeah. You know, they they had already you know, they had a plan and attack, and they were actually already in the AWS in some respects. So, again, there was less time having to spend leveling up, folks to be comfortable with the technology.
Definitely. Definitely. Alright. So this other question, during the execution of migration, what typically happens when surprises are encountered?
Well, it it can be twofold. It’s, you can either power on through or fail back. Right?
Generally speaking, this is gonna be tied to the customer’s change window, what their migration timeline is, what is the backup plan.
So provided you’ve built in during that assess and mobilize phase, an understanding and a preplan of what what you’re gonna do if, say, something doesn’t come up when it gets migrated or there ends up being some IP address conflict that’s not DNS. How are you gonna resolve those? And having a plan ahead of time generally takes the risk out of a lot of those surprises. But if you don’t spend that time ahead of time, then you’re gonna be doing lots of fits, starts, and stops. Right?
Definitely. Alright. So how does the human variable factor into the organizational transitions from VMware to AWS services?
I would say it’s probably the the top factor. Right? There there’s it is a different way of thinking operating in the cloud. Right? You have capacity on demand whenever you need it. You’re detaching specific services from applications.
In addition to the fact that just VMware has been prolific. Right? They they are the market leader for an on premises hypervisor, and they have been for decade over decades. Right? Right. So there is a, human factor of just knowledge and training, and it is substantial.
It it definitely factors into the transition and can slow down a migration to AWS while those folks level up.
And then in addition, there’s So sorry.
Go.
Go ahead. No. You’re fine.
I was just gonna say, I think you mentioned something about, the the tenured the the tenured VMware engineers coming in. They you guys have a program for them to learn the link.
Yeah. We we have an entire learning path because we’ve realized that this is a problem. Right? How do you take someone who’s been working with vSphere for, you know, five, ten, fifteen years and and get them leveled up quickly in AWS. And so we’ve created some some enablement that is accessible to everybody, that goes into this is what it’s called on vSphere. This is what it’s called in AWS.
This is how you do this in vSphere. This is how you do it in AWS. And so it it takes the sting out of that and, hopefully, helps the customer move faster and have a better experience once in the AWS.
It’s very similar to monitoring. We we do this all the time, speaking the same lingo as another monitoring solution, having to translate, so giving them the onboarding process to do so. It’s really good to hear. So what are some key differences between VMware and AWS in regards to resource provisioning or cost optimization?
Yeah. So we’ve kinda touched upon this in terms of rightsizing, and, I mentioned, capacity on demand. One of the key things when you’re operating on premises is your capacity, if you were to chart it out, it looks like a staircase. Right? You’re going either over provisioned, under provisioned, over provisioned, under provisioned. And because you have to wait time for purchasing and getting physical hardware, whether it’s it’s computer storage or even networking. And so you’re always in this this seesaw between over and under provisioned.
Whereas when you’re in the cloud, you’re able to right size everything, and there’s capacity on demand. So the the chart actually starts shifting away from looking like a staircase and more into a soft curve. And so that’s one of the biggest differences that you see between an on premises and AWS infrastructure is just that you have more opportunity to use only what you need when you need it versus having capital expenditures that, you know, you have to age off. Are they you know, you have to wait for capacity when you need it, if it’s a performance issue, if you have hardware failures.
Right? Like, you have to factor in that cost when you’re architecting an on premises infrastructure of high availability. Whereas in AWS, we take care of that for you. So you can just focus on optimizing your workloads and not worrying about having all of this extra infrastructure just in case of a fail.
Alright. Just wanna thank everybody for their time.
Yeah. And thank you, for having me on here and having a great conversation.”