Hi, everyone. Thank you for joining today's webinar. Key principles for cloud migration, modernization, and recovery. Before we kick off, I wanted to cover a couple of the housekeeping items. So at the bottom of your screen, you'll find a Q and A box. Please feel free to submit any questions you have during the webinar, and our presenters will answer them at the end of the session. This webinar is being recorded and will be shared with you our the session today. And with that, I will hand over to our presenters, Thomas Speelie and Kimberly Zach. Great. Thank you so much, Hannah. Hello, everyone. Thank you for joining us today. I'm Kimberly, a senior product marketing manager with Cutover. I've been at Cutover for about one year now, but I've been working in the B2B technology space for over fifteen years in marketing and product marketing capacities. And I've been working with products and engineering teams to help enhance our products and bring them and release them to our customers and the market. And I work with people like Thomas here. So, I will hand it over to Thomas across the pond. Hi, everyone. I'm Thomas Bealy. I'm a senior product manager here at Cutover. I joined Qatar over eight years ago, and during those early years, I spent a good amount of my time either working with or for the cloud ops team on our side, So I'm now really enjoying as a product manager working in this space and helping users to migrate and modernize in the cloud. We've tried to bring together some learning from clients that we've worked with, as well as our own experience of hosting applications on the cloud. So for our agenda today, I'm gonna open it up with kind of the state of cloud adoption. And cloud journey, some common pitfalls that enterprises should consider when migrating workloads to the cloud. Handed over to Thomas for tips to modernization or optimization in the cloud, some cloud recovery misconceptions and complexities. Some recommendations for cloud recovery, and then we will wrap it up and open it up for Q and A with a quick recap. So as you well know, cloud adoption is not a one step process and while all cloud journeys are unique in their timing and specific nuances, there are commonalities. And many businesses adopt cloud in a phased approach similar to this graphic that you're seeing on screen. So starting with a few projects and planning, understanding how to leverage the cloud, making some foundational investments so that when they actually start migration, they can really scale and benefit the entire organization. Then when they move to the migration stage, they're moving those IT assets to the cloud, of course. And typically an enterprise will use a phased, a way rather migration approach. So, grouping those workloads by dependencies, business name, type of technology. And then once the majority of workloads are in the cloud, it doesn't end there. So then it's on to the modernization or optimization stage. And this is where we're seeing kind of a hyperfocus for a lot of organizations right now. So they're looking to leverage the cloud services and really improve their ROI. But throughout the entire cloud adoption journey, cloud recovery is a critical name. That's why you see it underneath there throughout all And during this webinar, we're going to talk through some challenges, some kids' iterations, and then some tips for both cloud optimization. Or modernization and then adoption and recovery. So let's start today. I'm gonna talk with a quick recap of the state of cloud adoption right now. So Gartner predicts that public cloud spending will reach nearly six hundred billion dollars this year. That's a twenty one percent increase in annual growth over last year. And of that growth, one hundred and fifty billion of it will be spent on infrastructure as a service. Or IAS, which is the second fastest growing cloud spend, second to SaaS only. And IAAS is important because when companies are migrating workloads to the cloud, that typically falls into that infrastructure as a service category. And then forty-one point four percent of global tech and business leaders in a recent survey plan to increase their investment in cloud based services and products, and that's due to the current economic climate. So, despite the volatility in the market, despite what's going on worldwide in various regions. Global technology leaders are saying an investment in cloud based services, they anticipate that helping them. And then given that volatility, twenty twenty three marks the first time that managing cloud span has overtaken security as the top challenge facing organizations. And that was from a survey by Flexsera. So optimizing existing use of cloud for cost savings is a top initiative. And companies are still very much looking at that investment, that migration, that optimization stage. So, security is a huge concern, of course. That's not going anywhere, but it's interesting that given the volatility that managing cloud span has become more of a priority has surpassed that. And then once companies migrate their apps to the cloud, the investment isn't stopping. So a Gartner CIO and tech exec survey shows that forty six percent of organizations plan to increase their spend on application modernization. So, they're looking for scalability, flexibility of cloud native technology that can really help them go to the next level with innovation, drive faster more efficiently with their technology. And then again, we can't forget about recovery. Cloud recovery and resiliency, which is important throughout that entire adoption journey as I mentioned. So, in twenty twenty, Gardner estimated that the average cost of IT downtime was approximately five thousand six hundred dollars per minute. And given inflation, we can expect that that's probably increased. Now, a recent uptime Institute survey showed that outages are frequency is decreasing, but the cost when the outages happen especially if they're over one hundred thousand dollars is increasing. So, they're less frequent, but they're more expensive and they're taking longer to fix. And human error plays a huge role in outages. So, anywhere from two thirds to four fifths of outages, are caused by human error. And again, that's a stat that came from an uptime institute survey. So, in summary, businesses are continuing to invest in the cloud it's not slowing down, and it's more critical than ever for them to address those challenges, and then consider all the opportunities that the cloud journey has. So we'll start talking about the cloud migration stage. And there's often as enterprises are moving and accelerating that move to the cloud. Here's five common pitfalls that we've heard that we've come across when we talk with enterprises. Whether they're customers or those in the market and our peers. So the first is not having stakeholder buy in. Seem self explanatory, but really clearly defining that migration strategy, considering all the dependencies, timings, the budgets, and then getting buy in all the way up and down the chain from executives and c levels to managers who are going to be executing the project and the users. And then consistently communicating and maintaining alignment throughout the entire cloud journey and project. The second is scope creep. So, this really ties to the proper planning. And outlining which workloads will be migrated at what time and in what order. For example, if you plan to migrate five, but realize you need to migrate an additional ten fifty or one hundred based on the size of your organization. That has huge budgetary impacts, right? So how they're interconnected, the type of technology and creations that they have, that could put a huge delay in your cloud migration. The third is regulatory requirements, and this again, seems very straightforward, but if you're in a highly regulated industry, whether it's financial services, pharmaceuticals, health care, government contracting, whatever the case may be, there's a myriad of regulations in how and where your data can be hosted. And you need to consider those requirements upfront, especially when you're planning your failover strategy, so you know where your data is going to be regardless of your time. And then from a softer skills perspective, think about the cultural shift, right? So, to move to hybrid cloud approach, right, leaving some applications on premises, moving some to the public cloud, the multi cloud approach, right, using multiple cloud providers. There's oftentimes a skills gap and limited resources and people need to hire contractors, and which could increase the budget. So, there's also a change management respect and the willingness of your teams to embrace these new technologies. So, there's an inherent cultural shift with any large project like this. And understanding and planning for it, finding a champion, and making sure that your teams really embrace this move because it will be a new era for them. And then the fifth and final one is underestimating the complexity. So cloud architecture is different. Than on premises, and making sure to put in enough time and planning so that way the complexity doesn't surprise you throughout the migration process. So, and as I mentioned, the cloud journey doesn't end when you get to the cloud. Right? There's so many more benefits And Thomas is going to talk about some of them to realize when you enter the modernization stage or optimization stage of the journey. So, years ago, the focus was just moving, but now it's really that next level, that next phase of digital transformation. And as Chris NIMs of Capital One says, if you just move your applications to the cloud, you aren't getting the full benefit. So, the compute and storage are really just the start of your ROI and savings. There's so much more that you can capitalize on. So with that, I am gonna hand it over to Thomas to talk about some tips to modernize cloud workloads. Thanks, Kimberly. So the first thing we just want to talk about is is what often comes up as the headlines of modernization around these big refactoring projects that can be really impactful. So an example might be containerizing your applications and what the benefits we're thinking of here are taking advantage of the rapid deployment that can come with it. And also the portability across environments. Equally, you might consider embracing microservices architecture for some of your applications. You want to take advantage of independent, development, and deployment. And also from a resiliency perspective, if you want that system resilience and full isolation when one element goes wrong. Finally, you might look at it from a process perspective and want to implement devil's practices or maybe harden your existing ones. And all of these are really great things to be considering and doing and can have big impacts. So definitely recommend exploring them. And I think if everyone had infinite time and resources, then really would be going after all of these all of the time. But in reality, that's not always the case. You know, refactoring is expensive. It requires knowledge. And it's sometimes hard to get buy in. So what we've tried to focus, you know, our optimization tips around are actually things that are potentially more practical and more achievable, but that's not to deny that these are great things to do. The other just word of caution we'd have is These can be great things to do, but not every application should have microservices architecture. So absolutely explore all of these. And make sure whether it's the right fit for your application and go from there. So the first thing that we talk about in terms of modernization is actually making sure that you've got the end of the migration right. So the first thing is you really want to start with a really rock solid foundation, and part of that is doing the right amount of testing as part of your migration. So before you go on and do sort of anything extra, you just want to make sure that everything is running correctly and there won't be any issues. And then you can go on to the next thing that we're going to talk about, which is decommissioning. So decommissioning is an interesting one because for many people, one of the reasons that they do a cloud migration is in order to do some sort of cost optimization, but what sometimes happens is that perhaps because you haven't done the right amount of testing for a period of time both the on premises old infrastructure and the new cloud infrastructure are kind of running concurrently and you're running up costs as a result. So we would say absolutely, you know, do the the amount of testing, get comfortable with your new infrastructure, but absolutely make decommissioning part of the plan so it doesn't get forgotten and it happens at the right time so that you can can go on from there. Finally, we'd just say that we would hope that every migration, there would be an element of of validation and assessment before it's done in order to, as best as possible, right size the infrastructure that you're moving on to. But it's not always going to be correct, and you might find that you made a few mistakes there in the opening weeks. So put some time into the plan to do some rightsizing and get that cost optimization journey started already. The next thing that we'd want to talk about is about training your tech team and really making space and encouraging learning. I think that what we've seen with some of the people we've worked with is that especially kind of long running technology companies it can take a cultural shift in order to really make the most of being in the cloud. And there's a lot of great resources to help you do that. So there's really awesome prescriptive guidance available from the cloud providers, and we find that the more time you spend to understand how it's it and how to get from A to B, you'll really see the benefits of that. I've also done a few great courses that are available from cloud providers and they give you you know, tests at the end to to really test you. And and then finally, you can also get involved in in person workshops that that will give you that kind of experience by doing. And I think the key thing is that what I found here is that, you know, different engineers work in different ways and want to learn in different ways, and it's great if you can provide a number of different routes for them to get started. You know, finally and maybe, mostly importantly, sometimes you need to give people that time to learn. My experience of being in engineering companies has that, you know, there's always something really important to do and and finding time for that learning can sometimes be deprioritized. So really do what you can to make space for that because if you can get your teams to start thinking in a cloud way, you'll find incredible solutions to your problems that you haven't even seen coming. So I think our biggest piece of advice when it comes to practical tips in terms of modernization would be to leverage the managed services that are available from the cloud providers. What I mean by this is that the services that abstract away the underlying infrastructure that it takes to provide these integrated functionalities What that can mean is you can get amazing functionality without the need for manual setup and manual maintenance, and that's massively helpful. I'd also see that we've really benefited from these cloud providers are really trying to make their services as self-service possible. So it really is achievable with often some simple configuration to turn on some really massive things that make a huge difference. In terms of modernizing your infrastructure. So the first piece that I talk about on the slide here is high availability. It's something we've found particularly useful. From an end user perspective, why you care about higher ability, especially with applications when you want uptime all the time, which tends to be quite often and what high availability allows you to do, is in a couple of ways, you can ensure that if there's an issue and things are configured in the right way, then you'll still guarantee that uptime. So It's sometimes called sort of multi AZ failover, and this is when there's physically separate and isolated locations within the same data center but you can move your application from one to the other automatically and keep that uptime. Similarly, when properly configured, you can have multi region failover, which means that you can have applications across different geographic regions to protect against region wide failures. The next thing we'll talk about is autoscaling. And again, from an end user perspective, what this does is to ensure that they have the best possible performance when using your application. So how this works is that you can set up your application to scale the infrastructure dynamically according to the amount of demand that is happening within your application. And this is really cool because for the user, it means that even if many other people start using the service, it can scale up automatically and ensure that you can have exactly the same experience that you would otherwise. And from a, I guess, a startup perspective, this is a really exciting one because it means if you you know, if you manage your app design well, you really have limitless potential in terms of scaling your application as your users scale. Load balancing often has the same benefit for the end user. So what this does is that you can set it up so that if a single instance of your application is kind of getting a lot of attention, it can detect failures within that instance and root traffic to healthy instances, or sometimes it's not unhealthy, it's just that it thinks the experience would be optimum by moving that request to another instance, and that means that the end user is getting this great experience. I would say that, you know, with Auto Skating Adlow, balancing, I've focused on the benefits of the end user, but there's equally balanced benefits to the application owner from a cost optimization perspective, Both of these will ensure that you can have the right amount of infrastructure for the amount of demand you have at any time, meaning that you're not overpaying. Moving to the next set, automated backups to databases are as critical as they sound. So what these do is simplify the process of backing up your databases, having a scheduling list, so it's being that those databases are being backed up at the right times. A retention policy, so making sure that according to the rules that you have for your application, you're retaining the backups in the right order, and then finally providing a really easy way to restore those backups. This can be really helpful because all the processes I've mentioned can have really high manual effort in terms of set up and maintenance. It's also really important, especially in regulated industries that you can ensure data protection integrity and recoverability for your database instances. Another thing that we really advocate for is exploring and making use of all the monitoring services that are available when you get on the cloud. There's a few key uses for this using alerting and notifications. You can set up alerts that receive notifications when certain conditions are met. What this often means is that your support and engineering teams to move more to a system of working on exceptions and being proactive to things that are coming up rather than having to constantly monitor your applications. Secondly, we'd absolutely see monitoring as critical for optimization, So this is about collecting data about your application performance and seeing opportunities either for rightsizing or perhaps for refactoring in order to cost optimize or improve the end user experience. Finally, when things do go wrong, It's really critical that your support teams and engineering teams can access logs in an easy and permissioned way so that the right person is able access the right information in a really intuitive way. Now when things go wrong, this can mean that it's much easier for them to diagnose the issue. And move further forward. Finally, if you're like me, you're really struggling in twenty twenty three to keep up with all the technological advances that are going on. And as an application ID, you're really keen where possible to take advantage of these. And give your end user that benefit. What the cloud can provide is a low cost or low investment way to explore these technologies and really have a look and see whether you could provide massive benefits by exploring this technology. I'm now going to pass back to Kim to talk about some cloud recovery misconceptions. Great. Thank you so much, Thomas. So, five common misconceptions that we found in our conversations with people in the market, peers, customers, etcetera are listed here, and I'm going to talk through them briefly. The first is that outages won't happen, right? So, you know, the cloud is not immune to outages. Despite best efforts, architecture with resiliency built in, no provider can prevent them one hundred percent They still happen, it's inevitable. And as an enterprise, you need to make sure that you're prepared to understand when, not if an outage occurs. And that you're responsible to minimize downtime and recover quickly. So, the recent outage on April 25th in Paris is a good example. Right? So, Google Cloud Services went down due to a multicluster failure and led to an emergency shutdown of multiple zones and impacted ninety cloud services. And while that probably could not have been prevented, you can't avoid outages, But hopefully those customers were able to respond to them and have comprehensive DR. DR procedures and then get to a fully functioning state as quickly as possible. So, that leads to the next misconception, which is that documentation is required. And in reality, you still need to document the process for failover if an outage happens, whether on premises or even in the cloud. So you need well documented comprehensive procedures that work through task by task, including the people and make sure that the culture and work structure and executives and stakeholders are all bought in so that when that outage happens, you're prepared. And how do you ensure preparedness testing? So, again, testing is still important even if your architecture is in the cloud. So often enterprises aren't doing enough testing on cloud because it's complicated. In cloud providers like AWS, they do provide prescriptive guidance and scenarios But the conversations we had have had is that a lot of customers aren't doing it. And why is testing so complicated? Because these workloads aren't just in one data center now. They're spread across multiple servers, availability zones, or they're containerized, And not only is it complicated, it's also time consuming. So in a recent survey that cut over conducted, more than half of the respondents, fifty seven percent of them said that planning and testing, particular scenarios took them an average of three to six weeks. And often the length of time of it testing and planning is due to inefficiencies in really outdated manual processes. And then we come to our fourth one, fourth misconception, which is that cloud architecture is the same as on premises and that's not the truth. So there's a lot of differences. Right? So, on premises, it's fully managed by the customer and the environment's limited to what the customer has. The networking the type of servers and security, so the application design is within those existing parameters. But in the cloud, you know, Thomas talked about how there's some limitless opportunities and there's limitless benefits of scalability and all these advanced services, which are fantastic from an ROI and benefit perspective, but they do create some complexities. And you have the flexibility to choose from all of those services and tools, but that can cause some complexity that you need to consider as well. And then that brings to the fifth misconception, which is that recovery is covered by the cloud provider. And in reality, recovery is a shared responsibility between the cloud provider and the end customer. And this is a conversation that we're having more and more. And companies think that because they're in the cloud, SaaS recovery, resiliency is built in with their architecture and therefore SaaS recoveries handled. And they're okay. And in reality, if the cloud, if you're using infrastructure as a service that's second from the left, you're responsible for the workloads which includes your data, security, the middleware, and the guest operating systems. So, the responsibility means that you have to outline recovery time objectives. You have to test. You have to track the recovery time actuals when you do those tests. And you have true ownership over the availability and recovery of those four segments. So, as I mentioned, infrastructure as a service is a rapidly growing segment of cloud computing. And companies are going to continue to accelerate IT modernization, so it's really important that to minimize risk and optimize costs that everyone has a full and true understanding of what the responsibility they have from a recovery perspective is. So now I'm gonna hand it over to Thomas for some cloud recovery recommendations. Thanks, Kimberly. So the first piece of advice we give is always design your applications with failure in mind. So, whether that's building redundancy in, so backup systems, whether that's having graceful degradation, and what I mean by that is minimizing the impact of failures. Allowing users where possible to continue accessing and utilizing critical features. And this can be really important because what you don't want is you know, a bug happens in a small part of your application that really doesn't get usable that much, but it takes down all the golden journeys for everyone else. And so where possible design in that way? And then finally, in terms of designing your application, can you put circuit breakers in? And these can act as a safety mechanism when there are any workloads that are causing issues with this with your application. We'd also say when you're doing application design, make sure to consider the business requirements. So there will be some applications that have big requirements in terms of uptime and data recoverability, etcetera. And In that case, for instance, you might not want to use a spot instance because it wouldn't be appropriate, but there may be other apps where business requirements are different where it would be totally appropriate. So make sure that you're going through that process and selecting the right type of infrastructure and services based on those business requirements. And finally, sort of carrying on from that, ensure that data availability is planned for. So have a clear idea with each application, what amount data loss you can afford according to the business needs and then plan that way. A few more concepts, we'd say, you know, I I spent some time earlier talking about managed services and these can be absolutely critical to cloud recovery. Of the ones I mentioned pretty much all of them, I'd say monitoring high availability and failover, load balancing, auto scaling, automated backups. These are all things in which a relatively small change can have a big impact on your ability to recover from an incident, and I'd absolutely advocate those. The second thing I'd say is pay attention to other areas of weakness. So what the command does is fantastic as it gives you this really stable platform on which to operate your code and it can remove some of the distraction from engineers and support staff and business and allow them to focus on higher value activities, but what it won't do is remove some of the classic issues with software development. On this, I'm talking things like software bugs and errors, I've had this situation before where you have an application where the compute instance is bringing itself back up and back up again but each time there's a critical bug in the code that is causing an infinite loop that's causing it to go down. And so that's an example where even that planning, it won't help you. Another one is around third party service dependencies, you know, being careful with those and monitoring them and understanding that what is the impact of one of those going down? And is there the right way that you can recover from that? Kim talked earlier about the prevalence of human errors as part of incidents. And again, while humans are continuing to work on infrastructure, this is likely to remain the same. And finally, whitting an increase in security incidents and security attacks So what we're saying is these things will continue to be there. The hope is that As part of moving to the cloud, you've managed to free up some resources and time to perhaps spend even more time on these processes, these critical processes than you were before and you just don't want to take your eye off those because they can have a big impact on your your cloud recovery. Finally, where possible, you know, absolutely leverage complimentary resilient services that are available from our providers. So AWS, as an example, has a service called AWS Brazilian hub, And what this does is takes you on a journey to help you grow in terms of cloud recovery, and it will give you particular advice according to the cloud provider you're in, and so we really recommend that. Moving on to the next slide, At cutover, we'd say that an absolutely critical part of our cloud recovery and our clients is building automated recovery runbooks to support you with that. In order to start this, we'd really say just start by documenting all the steps it takes to recover both manual and automated for each application. The next thing we'd say is look for opportunities to automate. So depending on on you, you might start with automating some low complexity elements to get into the habit, or you might want to do some analysis, once you've done a few recoveries to understand which elements are taking the most time and are the biggest candidates for automation. One thing we'd say is just make sure you have a plan for each application and critically that you're maintaining it. Hopefully, one of the benefits of moving to the cloud is that it enables you to release more often to your application. And it's really critical that when you make changes, you also make sure that the recovery plan is up to date is still relevant and is approved. Secondly, you know, create scenario based plans. So this is an even further step that you can go on that Make a particular scenario can act as a trigger for a specific recovery plan, so this is an even more focused set of activities that will be even more efficient. And as part of this, we would recommend do consider the worst case scenario what would happen if there was a region, you know, region outage and what would you do to recover and have that as part of the plan? Finally, with this stuff, we found that practice makes perfect. So you know, rehearsing can really build muscle memory. It can give you confidence, and it can make sure that your teams will always reach to the recovery plan as soon as anything goes wrong. But as part of the rehearsal, as Kimberly touched on, make sure that you're acknowledging the recovery time objective for each application and measuring the RTA how long it actually took and then working towards getting to that recovery time so that you're really meeting your objectives. So hopefully those are useful. I'm just gonna pass back to Kim now. To talk about how Crossover can help with your cloud journey. Great. Thank you so much, Thomas. So why are we sharing these findings and learnings with you? It's because we wanna help, right? So regardless of where you are on your cloud journey, whether you're planning, your migration, actively in migration mode. You're moving on to the optimization or modernization stage. Or you're still on premises and thinking about it, but you still need to think about recovery. So, Cutover's automated recovery platform can help you across the entire cloud adoption journey. We were founded in twenty fifteen, and we focused on the operations of IT application estate for IT disaster recovery. Cloud migrations and complex releases primarily. And we built a framework for collaboration pulling together both the people side and the automation side. So, we've worked with some of the world leading financial institutions, which are highly highly regulated, including the top three largest U. S. Banks and three of the world's five largest investment banks. You know, we're innovative, so we consistently put time and money into our product to enhance it listen to our customers and really strive to pull that automation and bring those executable runbooks. And that technology to our customers. And it's, we provide a comprehensive platform, right? So, a new layer of capability that helps you deliver on the sequence of what happens when and in what order among all the teams of technology stacks whether you're looking at a recovery or migration or release. And then we're optimized. So, we have an open API and a wide ecosystem of example integrations across the entire technology stack. So, we help enterprises recover from and mitigate outages, and then our collaborative automation platform provides the visual representation of your executable runbooks. So, we have a node map functionality that outlines the human and automated workflow of activities from start to finish. And in our work with AWS, we find that that view, that pictorial view is especially helpful in a large cloud wave migration. Then we have automated communication paths, right? So you can always keep your teams informed. On what's going on. And these built in communications help the engineering teams, the cloud op teams, dev op teams, business teams, all of them collaborate with less friction, and there's also less time gaps during any of those types of projects. And we provide a visibility of execution analytics. So we talked about recovery time objectives, recovery time actuals. You can view those via a custom dashboard to have a really clear view of how the events are progressing, and then how long the events are taking versus what the expectation was on it. And then finally, regulatory compliance, right? So, we auto generate an audit trail, so you can prove or demonstrate that compliance testing events, and then the outcomes that happen. So how do you learn more? Visit cutover dot com. We have comprehensive resource library. We have example videos. We have example integrations and videos of those as well. And then if you're looking to calculate some ROI, we have a faster ROI calculator that you can go to. And then as always, I'll leave this information up while you think about Q and A. You can reach out to Thomas or myself. We're happy to have a conversation. Connect you some of our other experts in house on recovery resilience or migration, or with the application release, but wanted to thank you for your time, and I'm going to hand it back to Hannah. Our organizer to open it up for q and a.
