UNFILTERED & hands-on: The cost of not moving to the cloud

Hi, everyone. Welcome to today's webinar, the next in our unfiltered series. We're so glad that you're here joining us for a hands on real world look at the cost of standing still and what you can achieve with SAP, whether you're staying on prem, considering the cloud, or already there. This session is all about helping you make smart, future focused decisions no matter where you are on your cloud journey. You'll hear expert insights from Yani Kotzia, Andrew Barison, and Bradley Jackson as they unpack how to modernize smartly and why transformation doesn't always mean a migration to the cloud. G three g and f u slabs, both members of group elephant, offer over four decades of combined SAP expertise. Our close collaboration means we can deliver comprehensive end to end solutions to clients across industries, whether you're staying on ECC, planning for S4HANA, or fine tuning your cloud landscape. Just a quick note before we get started. This session is being recorded, so by staying on the call, you do consent to being part of the recording. After the webinar, you'll receive a link to the session replay and the full presentation deck for your reference. Please feel free to pop any questions into the Q and A box at any time. If we don't get to your question live, you'll have a chance to ask any questions in our follow-up comms with the recording link. So, Andrew, we can get started with our first poll. We definitely want to know before we get started, in your opinion, what are the most important benefits of the cloud? Is it faster consumption of innovations to remain competitive? Administration and upgrades are outsourced. Standardization, reduction in technical debt, and customization. Single vendor and s r a SLA across apps, connectivity, and security, or is it new gen AI capability? We'll just give everyone a few seconds to answer that before we end the poll. Great. We see a few poll results coming through. Very interesting results there. So well, the consumption innovation seeing is the top priority there. So thanks, everybody, for that one. Amy, do you wanna spin up the next poll as well? We also want to know, in your opinion, what are the disadvantages of moving to the cloud? Is it cost of brainorship, relinquishing IT responsibility and control, reduced flexibility to change apps to fit our business, or is it I'm worried about data protection, or is it system connectivity issues? So let's just give everyone a few seconds to give their opinion on that. Great. Look. An spread there, I think. So reduced flexibility and data protection top of the pops. All right. Thanks, Amy. Thanks, everybody, for contributing to those polls. Really helpful to get that insight. So what I'm going to do is just run through the agenda for the day. So I'm going to start by looking at some cloud principles, specifically in the context of your ECC system because obviously that's a hot topic for many SAP clients at the moment. And then what I'd like to do is look at some SAP use cases, specifically in the context of considering how do you consume innovations, how does the cloud help you with consuming innovations. On the first poll, that was obviously a top item for many of you, so we'll explore that in a bit more detail. And as we go through things, as panellists, we're going to ask each other just a couple of questions, questions we think will be on your mind as well, just to get the conversation started. Right, so once I've finished going through that, I'm then going to hand over to Jani, who's going to focus a bit more on AI and specifically how you might modernise in the context of whatever your landscape is looking like at the time. And then we're going to hand over to Brad, who's going to look at some of the realities around the timing of migration, when is the best time to do it, and what are some of the implications once you're actually running on the other side. All right, so we're just introducing a segment in our unfiltered brief, unfiltered lens. And the intention behind this is just to highlight some key, let's say, terminology changes, hot topics around the SAP side of things as we set a bit of context for what we're doing. So what I want to just highlight on this slide is the change in terminology around the SAP ERP suite. So on the right hand side, we've got an overarching concept of the SAP business suite, in a sense we're going back to the terminology that was used in the late'90s, early 2000s. And under that business suite, we've got our line of business cloud solutions, things like SuccessFactors, Concur, Service Cloud, etcetera. And then we've got the two ERP systems, which were formerly referred to as SAP S4HANA Cloud Public Edition and S4HANA Cloud Private Edition. Those have recently been rebadged SAP Cloud ERP for public and SAP Cloud ERP Private for the private edition. And furthermore, many of you would be familiar with these terms rise with SAP and grow with SAP. And often these are being considered synonymous with products, but they actually aren't. They're actually journeys. They're transformation methods and tools associated with the journey. So RISE with SAP packages up a transformation methodology for clients that are on SAP already and are moving into SAP's cloud. It could be the private or the public edition of the cloud. And then Grow with SAP, specifically focusing on non SAP clients that might be moving into the SAP arena, Appsbury, growing businesses and so on and moving to the SAP Cloud ERP. We will share these slides with you, but I just wanted to set a bit of context around some of the change in terminology that we've seen. So let's look at some of the different options from an S4HANA perspective when it comes to cloud versus on prem because it's very important to understand how SAP defines this as well in their strategy. So first of all, we've got on premises, which many of you will be familiar with and on at the moment where you're running your own servers or you have your own data centres. And in this particular context, you will be on a perpetual license and paying annual maintenance. As we start moving over to what you would typically term the private cloud or infrastructure as a service, you've now taken your environment, you've taken out a separate contract with Terico or AWS or Azure and you've moved your solution in there. The solution is technically still the same and you remain on perpetual license and annual maintenance. Now from SAP's perspective, both those options are on premises. So when they talk about the cloud, they're talking about the two options which I alluded to on the previous slide that fall under the SAP Cloud ERP private and SAP Cloud ERP, which is essentially the public edition. Both of those are software as a service offerings, private, where you get to choose the hyperscaler of your choice, and the public, which is either hosted in SAP's data centres. But in some regions, like the Americas, for example, they are now building out relationships with the hyperscalers as well for the public edition. And the key thing from SAP's standpoint is that these are subscription models. Therefore, that commercial model is determining that they are cloud in their definition of cloud and then also the fact that they have, if you like, control over those environments. I just want to highlight one other thing on this slide under the underlying code base, where on the far right you will see I've got SAP S4HANA plus And the reason I've done that is we're starting to see some elements of the code line change where features are being developed first and foremost in public cloud edition of the solution. I think there's still going to be quite a journey on that side. Right. So we'd be very interested to know, as we kick off another poll, where you see your strategy. Some of you, I know, may have already moved to one of those options, but others might be going through that process at the moment. So we'll give you just a few moments to respond to that poll. Okay. Interesting. So a lot undecided and quite a few infrastructure as a service and private. Okay, super. Thank you for that. Very interesting. All right, so if we just press on a little bit further, let's look at those options from the point of view of how do I consume innovations. What are the constraints and advantages that I might have? So in the on premises option, which, if we use the term a traditional mindset, we're moving to the latest ERP, we're keeping things on premise, we're not making massive changes. We've still got potentially lots of legacy code we want to take across and that does mean that the system, let's say, is a bit fragile to making significant changes quickly because there might be implications on that side. So with this option, it still takes a while to do those sorts of projects and typically we're not bringing in a lot of business value and new processes. When we start to move up the curve to the infrastructure as a service, which we note from that poll quite a few of you have moved into, what you're doing at this stage is you're starting to adopt some cloud principles, specifically around TCO reduction of scaling up and scaling down resources. But you still have quite a few of the constraints around custom codes you might have taken across the legacy of an environment that's been working in a particular way for a long time. So your system in that sense is not necessarily that standardised yet. And then if we go to the opposite end of the continuum, where we move to the full cloud ERP, that's where we're embracing the cloud principles to the greatest extent. So a key differentiator here is the fact that your system is very standard. It doesn't mean to say it's not flexible, but you change it in a controlled way so that you can get regular updates. With the public cloud, for example, you're getting two updates a year. You want to be able to receive those new innovations as quickly as possible without having a huge impact on your business. So it allows you to get the benefits quickly, but also at a lower risk. And I think as your competitors might be moving off into this space innovating quickly, you need to be able to keep up. So that's you know, if you're in a fast moving industry, you know, you've got more opportunities to embrace, you know, innovations in that particular example. Andrew, just a question from my side. Having been involved in basis and migrations for quite a few years, we have a lot of clients asking us questions around, you know, we're thinking of just staying on premises for the interim, at least for the short to medium term, because a lot of the really amazing stuff that you've displayed so far on the screens is stuff that doesn't really sync with the client too much, or they're just concerned about the total cost of the migration. Is there any way you would recommend these clients maybe a path for them to dip their toe into some of this modernisation, some of this AI, some of this cloud where they can do that without having to jump right in just to kind of feel what it's all about? Yeah. Absolutely, Brad. And I think, you know, yes, there are, you know, I'm sure a number of clients on the call where sometimes you feel like, you know, you're just trying to keep your head above water, you know, and the idea of adopting innovation at a rapid rate, you know, can feel quite daunting. But maybe the way I can answer the question is just to give a few examples of, you know, even if you're on prem, how can you start to adopt agility and cloud principles in some of the solutions that sit around the edge of your ERP, for example, perhaps where there's less risk of making rapid changes over a short space of time. So if I look at an example of something like SAP Analytics Cloud, and I know there's people on the call that are exploring it, some that are already using it. In the past, if I wanted to implement, let's say, an analytics cloud or sorry, a planning solution, I would have something like the on premise business planning and consolidation solution. Great solution, but in many ways very flexible. You build it from scratch, long costly projects to get where you need to be. If you adopt this in the cloud, the benefit you have is of a lot of standard content that's already been produced by SAP and by partners and it's available to you be able to adopt those innovations more quickly. So in this particular example, in Analytics Cloud, it's called the content network. So I might want to do some financial planning on my cost centres, projects and so on. I can go in here. I can search. I can find some appropriate content for Analytics Cloud. And we're also finding a lot of content for the Business Data Cloud is starting to be incorporated in this as well. I can literally import it, redo the plumbing and the connections to my back end system, ECC or Sfour, and then I can start to benefit from the content that's already been built. So that's one of the ways you can do it. Here's another example, Cloud ALM, which is the successor to SAP Solution Manager, which of course everybody on this call, if they're an SAP client, will be running. So with this solution, you can, for example, set up the connections to start doing business process monitoring very, very quickly. In the space of a few days, you can have this up and running and start to pull in some of that data. If you're on an ECC environment and thinking about Sfour and perhaps you haven't gone to the full blown business process analytics with something like Signavio, you can use this to start to interrogate and identify areas where you might want to build your business case. So again, I highly recommend looking at this solution. If you are paying enterprise maintenance, the good news is you already have a licence for this. So if you haven't looked at it yet, I would recommend that you do that. And then just a final example, and one which Jani will touch on in more detail, if we look at AI, right, what can we do on prem versus what can we do in the cloud? So the top half of the screen is just trying to highlight the fact that in an on prem scenario, I can do embedded AI scenarios in my ERP environment, but I'm restricted in terms of what's available for generative AI. So I can benefit from AI and cloud principles without going to the full extreme, but there are some limitations and restrictions where we have to consider alternatives. But again, I think what I'm trying to highlight here is there are some options. So in essence, you're saying that even for the client that wants to kinda hang around for the moment, doing that and embracing some of the modernization that you've listed out here, maybe not the Gen AI stuff, but there's certainly not a mutual exclusivity between those two topics. You can still stay where you are for the moment, but still look at certain things that might benefit the business and that might kind of generate a lot more sort of interest in some of these things that could help justify a modernization journey. Absolutely, Brad. So I'm going to hand over to Jani now, and she's going to continue to look at AI and how you can modernize any landscape. Jani? Thanks, Andrew. Great. So we're gonna have a look in a bit now from how SAP went from just being BTP centric in their clean core move to the cloud to going AI first. Now we all know BTP by now and the pillars in on all of those things. So what SAP said is go clean, poor, use BTP to modernize. There's low code and broker solutions to develop apps. There's great analytics, DataSphere, SAP Analytics Cloud so that you can inspect your data, get great insights into your data, and then create integrations because every business we know now has at least I think it was actually sad that says at least, in the small to medium businesses, like five to seven different applications, and you need to integrate those. And the integration suite is perfect for something like that, especially if you are you know, your core is happy. You want to get the data in there. So this was what BTP was. And initially, they had AI as a separate pillar, but I think they realized that AI runs through each of these pillars. So if you have a clean core and you have BTP, you want to modernize on top of that, AI can be embedded in that. So for instance, you can create an app. You can add AI in there through document information extraction, and that is great. But then SAP went and they said, okay. But now we have the Kleen Core, and I think when they suggested, you know, clean core so that you can innovate fast, they never knew the impact of generative AI just being around the corner. You know? And that was quite a game changer. But when Gingerf AI came along, they had this clean core that they can now work with, and they could build models on top of this, the semantic models, that describes the SAP data because it can be quite confusing. But now you have this semantic layer on top of your SAP core team core data there that describes the models and the knowledge graph on top of that describes the relationship between these, you know, models that is there. And having all of this at the core and without anything else in there, they could innovate really fast. And that is how they came to an AI first approach, to really embed and augment that core with AI. So now you have AI agents that can go and perform tasks for you and complex tasks inside of your core. So they said the finance module, that was the first kind of core there or lot of business that they took, and they said, let's create agents for this, for instance. And they could the agents can understand the data. They can they understand how the data relates to one another, and that's why you can toss that agent to go and do work for you, to go and pull data, to go and update something. You know? That agent can actively go and do something. And because the core is clean and because they already have this technology, SAP will build out each of these line of businesses, and they've started that already, with agents and different forms of generative AI. And that makes it extremely powerful to have that at your core. So you don't just have KineCore anymore. You don't just have BTP anymore. You have that AI embedded in there that can go and actively do work for you. But the question is now like, why? I mean, it's great and it's nice. Will probably come at a cost, but why is that so powerful? And you can just go to a vague slide there, Andrew, please. And that is because if you don't have that, but your competitor has that, They have agents that can go and do self or, you know, change information or update information or recon something at four o'clock on a Saturday morning where you don't want employees there to do that necessarily. And this can go and, you know, manage your data for you, clean up your data for you. All of those tasks can be performed. And it might sound like a lot of small little things, but if you add it up, that means your competitor can have you know, they can have their employees spend time on much more important tasks, but they can innovate on those important tasks somewhere else, and the mundane tasks gets done by an AI. And that means they don't have to appoint more people to go do that mundane work. They have AIs doing that for them, and that can make their margin shrink. You know? So, you know, that means they're spending less to get the same things done and putting them at quite a competitive advantage. So it went from nice to have to a must have, because otherwise somebody else will outpace you in this thing. And that is why it gets so important. The times changed dramatically. We had Kinku. We had modernization with BTP, and it was nice, but you could do a lot of similar things with your on prem system exactly as it was. You know, you could do apps and all of those things, but having that AI at the core is quite a significant change, with the significant change that generative AI has introduced into the world as we know it today. So okay. Just the next slide, please. Alright. So we spoke a lot about King Core, SAP, Cloud ERP, what advantage you have there. But let's say you are still on prem. What now? Your plan is to move to the cloud ERP, move there eventually. But for the time being, you're on prem. So what now? Are you just stuck here? Can't you move forward? And the answer is no. So you can luckily our suggestion at least is that you start, and you start with BTP because BTP is still that foundation that all these new fancy AI things are running off. You know? So even if you are on prem, you will start you should start using BTP to derisk and transform your systems. So if you look at where you are now, if you start moving some of your things out, you know, you start with small migrations. That might be that you take your PIPO and you move that to the integration suite, for instance. It means that when you get to your full migration, the task of moving will be much smaller. Your whole landscape will be much more simplified. There's going to be a lot less clutter in there because you're going to have, for instance, no PIPO things that you need to move over because they're already sitting on the integration suite. You might have apps that's running on their, you know, Fiori apps that has OData services. Those ones you can already move to BTP, maybe using low code solutions because it might be simple enough apps to do that with. And then your your move would be much easier and much lighter. And then also you'll be able to see the value of modernized systems and how quickly you can innovate on that. So all of that would be available for you if you start moving some of those things over to BTP. And then we get to AI as well. I mean, then you can start with some AI things even on your on prem system using BTP and SAP AI Core, even though it's not baked into your system already. So Yoni, you know, it's all good and well. But, you know, from an AI perspective, SAP talk a lot about business context, and you alluded to it earlier that they've trained certain modules. You know, FICO, I think procurement was one of the modules they've trained as well. And of course, these agents understand the data. You can ask them something and they can interpret it with natural language and so on. So talk to me about the specifics of that in an on prem context. What are my limitations when it comes to, I suppose, involving the ERP data within the context of possible. You can have generative AI solutions and modernizations, innovations. All of those things you can have on prem. It's just more cumbersome. So if you look at the complexity, SAP, you know, has this core. They have the knowledge graph. They have the semantic layer. All of the data is described in there, and it's managed by them. So the complexity for you as the customer is quite low. Where on prem, when you have to do all those things yourself, the complexity is quite high. There's a lot of things to consider. If you have to consider that you need to go and train a model on that SAP data, maybe on your custom data as well, it's gonna be very time consuming. So your time to innovate is gonna or time to value is gonna be slower than it is out of the box. It's you know, you SAP uses the word activate. You just activate AI capabilities in your cloud ERP system. But on your on prem system, you're going have to train models or get models to use and then custom do custom development on top of that. So time to value is also going be slower. Maintenance as well, newer data, newer models, newer things coming up. SAP does that once for a lot of customers where you have to do it for yourself, and that's also, you know, a lot of main incidents that you need to keep in mind. So overall, your innovation pace will be slower. It's gonna be rapid if you're on a call, ERP, and all of those things are there already for you to use. But it might be slower in the innovation phase or your innovation phase will be slower if you're on prem. But it still does not mean it's impossible. Luckily, you have, you know, capabilities to do that. And it also does not mean that SAP has all of the AI capabilities that you want. You want to do some customizations on top of what you know, even if you are on Cloud ERP, you want to customize the AI stuff there. And but still, in that case, SAP has made it possible for you also with a BTP solution, called Dual Studio so that you can create your own agents and then also your own Dual skills if SAP does not have what you need. But that is already easier than doing your own agents and your own customizations. Still not impossible. And if you wanna start now with some of those innovations, that's also recommended if you are on prem. Start trying it out. Start seeing what works with you because those innovations, you could very easily port over to your cloud ERP system then at the end. So it doesn't mean it's impossible, but it is just a little bit more tricky to do that. Great. Okay. I think now we are going over to and to maybe just before that, Bradley, something that I've been often wondering about is I talk to a lot of CIOs or c level, and a lot of the discussions there are why I'm well, I've fixed something that's not broken. You know? I'm already on something. We spend a lot of money. We hear everything works. If we're gonna move stuff now, it's gonna be a lot of trouble. If can't I just wait for another five years, see what SAP comes up with next, and they make the move? What do I tell them? Because my opinion is, from what you've seen, is it's easier if you move and then modernize on top of that even though it's not impossible to modernize now. So what's your opinion on that? Yeah. Awesome, Jani. I think that's a really good question. And we have this similar conversations. You know, there's a lot of drive, and that's the question I asked Andrew earlier is how do you balance the drive towards modernization with sort of tempering enthusiasm right now for pushing business in a specific direction where that might not be the final destination. I mean, we've had a lot of history around the very tired word of cloud, you know, going from it being a huge buzzword, everybody going from on premises to what was considered then cloud, which was your hyperscalers, which Andrew has already defined as now effectively on premises according to SAP. And now if people have pulled that pin, now there's another SAP cloud that people have to move to. So you might find that clients have really been burnt with this whole, I've just gone through this massive migration, and now everybody's telling you, oh, these. So, you know, what I wanna do from my little section from a technical sort of basis perspective is just making sure you're doing these things for the right reason and where the cloud is good or not. Now I'm not an advocate for either. I'm happy with any direction a client wants to go in because there's always a way we can assist. There's not we lose out on this and we gain on this, and we're gonna push people in this direction. We're not trying to do that at all. But, doing it for the right reason is what's important for me. So I think, Andrew and Yani have really spoken quite a lot around innovation, AI, and cloud tools. If you're doing that, if you're doing the sort of move to the SAP cloud for those kind of reasons, understand that, yes, you're gonna get massive benefits, but some of them might not suit your business or some of them might. And then that would be a great justification to have. In terms of cost, you know, there are varying opinions from various CIOs, CTOs, CFOs around that moving to the cloud is gonna be cheaper, or it's gonna be drastically more expensive. And it's just understanding the cost thereof because you might look at the hosting cost or the licensing cost that is that Key provides and think, okay. Well, that's gonna be my cost. But you need to look at things like data ingress and egress and potentially tokens or things that you'd need to buy in order to have some of this AI actually work. And those are those kind of hidden costs that you really do need to understand. Another good reason to move, is obviously an aging source landscape. You know, there's a lot of and when I say source landscape, I'm not specifically talking about the ten, but I'm talking about, you know, the a drive where your data is becoming so cluttered and things are becoming far too complex. And there's a big drive in your organization towards simplicity where you then kind of follow that clean call that Jani spoke about and say, we need to kinda do this with our landscape now because we are kinda being painted into a corner with our own technology, and we need to take a step forward and move into the SAP cloud. The next point is, obviously, don't move because everybody else is doing it. You know? There's a lot of, drive from everyone, from SAP, from partners, from everyone that you need to do this. It's gotta happen, and everybody else is doing it and everything. And if you look at the numbers of clients that are actually moving to SAP Cloud, it is definitely picking up year on year, but there is still quite a over fifty percent somewhere around there. I don't wanna be caught out on quotes, but there is a significant portion of people that are sticking around to see what's gonna happen over the next few years. And, you know, in addition to that, you need to understand what the implication of the target environment is. I mean, a lot of people will know already, but some people might not. But if you do go to the SAP cloud, there's a lot of sort of control that you give over to SAP. You give away the keys to the kingdom from your infrastructure stack pretty much. And, you know, there's probably a lot of people out there that are running businesses that actually sounds wonderful too because they don't want to have to worry about what version of database they're running or what OS they're running or why their systems are performing slow. That's someone else's job. It's I'm paying for an as a service model here, and I don't wanna care about any of that kind of stuff. But you find there are other people that run businesses that want to understand why that is happening and why certain things are occurring and what versions we're running and everything like that. So just be sure you understand that when you do engage with the SAP cloud, there's a lot of stuff that kind of becomes black box, and that's it. You know? And that might be good for you, but it might not. There's there is a massive opportunity. Last sort of point I have on this slide is around your source landscape. Don't wait until you make a decision to do the SAP cloud kind of journey before you decide to start working on your source environment to sort of clean it up. You know, once again, referring to Yani's mention of the sort of clean core, and I see there are some people on the call that do have sort of strong app backgrounds. And, you know, I'm not only speaking about code in terms of a team call, but making sure that your data, your systems are in the right space to move across into a SAP cloud. Because as with any cloud, if you kinda just do a simple lift and shift, I very much dislike those three words together. You end up getting that whole garbage in, garbage out kind of scenario with the target environment, and that's not something you want. So you need to view prepare preparing your source landscape as part of the journey that you're going to use to get to SAP cloud. Thanks, Andrew. So last couple of points for me. I think it's important that you need to speak to the people that have joined this call, the people that are looking for more information, which is so great to see, that you need to understand what those SAP dates that are going around means. The twenty five, twenty seven, twenty thirty, and twenty forty, what they actually mean to your business going forward. And not, a, not to be sort of pushed into a corner and felt like you have no other option but going to the SAP Cloud or making a change. And b, also understanding that some of those dates might be very pertinent to you right now. There are specific versions of SAP BCC, which sitting at that twenty five date might not be supported past the end of this year. So you need to understand what that means. But looking at further dates on that are kind of being run around the social media and LinkedIn and wherever you kinda get your information from, and people are a bit confused what these dates mean because I'm not too sure. Does twenty thirty mean I can't have my Sfour HANA system on premises, or is that twenty forty? What does twenty seven mean in terms of extended maintenance and all that kind of stuff? So I just strongly advise that you speak to a partner, whether it's us, whether it's someone else that you trust, just to understand what those dates mean. Because I know most people at that kinda c level that you already mentioned already are not very big fans of being pushed around, being dictated by vendors and stuff like that. So most of the time, you're actually not being dictated to. It's just that the messaging needs to come across properly, and you understand that better. So definitely focus on that. In terms of the migration itself, big bang, which I've got there, is not probably a good idea because as Andrew listed out, a lot of the kind of peripheral systems, you know, you have a lot of change sitting in your environment at the same time if you decide to just jump into SAP Cloud and let all of those sort of a rebar and everything else replace certain technologies that you have on premise. So consider phasing things in because if you do big bang and you have a massive issue in your environment, it becomes incredibly difficult to try and figure out where in the environment this issue has come from. And I'm not saying be super risk averse. I mean, a migration into any kind of cloud or any kind of move of data is inherently risk. Well, riskful. Riskful. But what you do wanna do is you want to try and limit it without trying to sort of strangle yourself instead of in terms of the migration itself. So have a look at breaking things down to tiers. Maybe try and move your dev and your QA systems across or try and do your ECC stack into the SAP cloud first and look at some of the other things afterwards. Hybridization is a very good idea at this point in time, especially if you're looking at, let me leave some of these things that work behind, kinda connect everything up. And then once everything is stabilized and the SAP part start to move other things across. In terms of reliance on SAP partners and maybe things that you guys have developed in house in your companies as well, use those accelerators. There's a lot of stuff out there, things provided by g three g, by APUs, by Entire Group, by other partners that you work with that will make the migration of data simpler, less risky, and everything. And you would be remiss not to use those things in this situation. All of everybody that's in the sort of SAP Tech world right now are working tirelessly to try and find ways to take clients' data and move them around and do conversions on the fly and everything like that. So do your homework around those kind of accelerators so that you're doing the best you can for your business and for your users. Last two points for me is, obviously, the cost of the migration. I know I touched on that earlier. But if you're looking at what an entire migration is gonna cost you, always focus in, like, you might just look at my endpoint right now. This is how much can it's gonna cost me per month or per year or per five years when I'm sitting in SAP's account, but always make sure to factor in the cost of a migration into that entire cost to your company. Because these migrations, this the second and the last point kind of mix together here, the migrations are costly. They're time consuming and that complex. If you're sitting on an e c five sorry, a e c six enhancement package five system and you're non Unicode or something like that and you need to make a jump into the SAP cloud, sits on s four, that is a whole bunch of conversions and steps that need to happen all at the same time. And that can take a lot of time and a lot of money, and you need to factor that in. And when I'm saying in terms of time, just understand that if you're looking at a road map and you're looking to hit the twenty seven date or a twenty thirty date, bring your planning a lot earlier because there are things like what accelerators am I gonna use, you know, what conversions can I do ahead of time, what can I leave behind, what am I gonna hybridize? These discussions and decisions take a long time to kinda work out. So those are just a few things that I've kind of, you know, wanna put forward as kind of from a simple basis person's perspective, things to think about. And, yeah, as I mentioned, I am the boring basis guy, but we do have two very exciting people on the call, Andrew and Jani. And we've had sort of two different spectrums there where the these two people have been talking about the really interesting stuff, how to capitalize on it, you know, how to look at AI, BTP, the correct journey, how to dip your toe in, how to jump in feet first, whatever works for your organization. And from my side, just sort of balancing it while I just suggesting to be a little bit more circumspect with certain things and trying to do things the right way. And I think the sort of marriage of those two approach is gonna take your organization into the future in a sort of a low risk, high benefit way. And I hope you enjoy the journey that you take there. Thanks, Kylie. Great. I think we have a quick question in the chat. And as you can see, this image is AI generated, so don't look too closely at the bridge. You know? AI is very smart, but not that smart just yet. So I'm gonna talk to you, but it's Great. Alright. So the question that we have is that if you start moving some of your custom functions onto BTP while still on ECC and then eventually move to the cloud, will those functions be usable? Now this is something that we personally recommend, that if you go to if you make OData services and you create an app that runs on BTP, those OData services that sit on ECC, if you could make them mimic the ones that is made available by SAP on your cloud ERP system. That's your best bet for the least friction to move over because you will not be able to use exactly those OData services. They will be discarded. But if they look and work similar to the way that the APIs work on the cloud ERP, that's gonna be the least amount of friction you'll have so that you can reuse the app or whatever is outside of those OData services. Those things would be very easy to port over. But if you go do just your own thing with your own OData services and there's a little app that consumes it, once you move over, you can have the app that but there's gonna be a lot of rewiring to use the APIs there. And all of this information is available through the SAP Business Hub or the API Hub, name changes. But you can go and look at the documentation exactly how it works. And if you can mimic that, then you're you point it to another that are you know, you point it to another endpoint, and then just tweak it a little bit when necessary. And that would be your easiest and best way to do that. Thanks, Gianni, for that, answer. I really appreciate it. And, Andrew, Brad, any last comments from your side? I see we're almost out of time. Anything that you'd like to leave the audience with? I think for And I think, Mark, you need yeah. Really, just to say, off the back of our communications, if you've got other questions, you know, please do get in touch, and we look forward to seeing you on the next Unfiltered webinar. And thank you for taking the time. Thanks, everyone. So we hope you found the session insightful today and that it did give you a fresh perspective on modernizing your SAP landscape on your terms. Keep an eye out, on your inbox for the webinar recording and the accompanying presentation deck. Again, if you do have questions, we'd love to continue the conversation. So definitely have a look at our next unfiltered series. And until next time, take care and we'll chat to you all soon. Thanks, everyone.