A smarter approach to SAP S/4HANA: Modernise with Selective Data Transition (SDT)

Thank you to everyone for joining in such big numbers. Really good to see. I should start off by saying this session is being recorded. The recording and a copy of the presentation will be made available on the SAUG website shortly, and we'll notify everyone when it's ready. This series has been created, of course, for our consultant members to showcase their solutions and show how they can assist with optimizing your SAP systems continuing long term support of SAG and for making this session possible. Today, we're looking at a smarter path to S4HANA with selective data transition. Obviously, it it's touched the note with a lot of people. It's, a lot of people interested in and a lot of deadlines coming up, so very sort of, topical at the moment. Everyone is on mute, but you can ask questions at any time using the question function on the screen, and we'll go through questions at the end. There'll also be contact details on the slide, so if you'd like to ask any questions in the future, you can email the presenters directly or you can contact us. And if, you think of any other topics that you'd like to hear around this area, please let us know in the, question section as well. Now I'd like to introduce our presenter for today, an expert in this area, and his involvement with SAG goes back many, many years. Pleased to see again Daniel Parker, who's a senior SAP solution architect at FU Slabs. Thanks, Daniel. Thank you. Thanks, Michael. Welcome, everyone. So I'll just, kick off initially just a little bit about FU Slabs. So if you're not familiar with us, we're a organization that we've been working with, SAP solutions for well over, thirty years. So, forty two years, it says down there. In the bottom left, we've been working in the SAP space in some, make or manner. So today, I'm gonna talk a little bit about what we call our our prism, methodology and our prism solution sets, which are around migrating people to s four or cloud or carving out systems. But that's by no means the only thing we do. So we're very much an R and D focused business, so spread across the world, you know, focusing around activities and solutions and tool sets that help people manage, SAP systems and SAP data. And if you're not aware as well, we're part of what we call, GroupElephant. So it's a great greater group of businesses around, thirty odd brands, that cover SAP and other parts of, the IT ecosystem doing similar types of help. And we channel one percent of our global revenue from those group of businesses into what we call ERP. So it's our, our program for elephants, rhinos, people to help alleviate, people out of poverty and help save elephants and rhinos across Africa. So that's one way that we give back in terms of, an organization. Another key point is, and I mentioned as well, so we're spread globally. So for the type of work that I'll talk about today, we definitely have local based teams, but it's very much leveraging global teams and global, development teams, consulting teams, and solution delivery teams. So very much, local present, global footprint as well for how we deliver and drive the types of work that I'll talk about today. Alright. So today's session is a little bit of a continuation of, some other, content that's, that we've run through Sorg or our partners have run through Sorg. So you may have seen about a month ago, I talked on, some things around s four and rise pain points. So they're the first three items on the left there. So about saving cost, reducing risk, and helping you manage, your landscape and your systems in the contract once you're with, with RISE. So if you have a look back on the SOR website about a month ago, you'll see a webinar based around that. So that was kind of talking about how we, manage nonproduction, manage the support of the systems once you're in RISE, so that some of the topics I'll touch on today are covered in a bit more detail in that session. The optimized costs there, that was, our partner, Soterian. They ran a session recently as well through Sork, so you can find that on the website. That is around, what's called full user equivalent and the changing of, SAP licensing for users and cost and risk management. So go have a look at that as well. So there's sort of four topic areas that are covered already, which, sort of help, fit in with today's discussion. So today, we're gonna talk more about the production side. So, how can we selectively move the production system and data from it into s four or into RISE, and what kind of transformation options or transformation approaches do we have available to us? So I'll talk a little bit about how we approach that work, and tool sets and products and things that we use to help deliver those styles of projects. So, yeah, key things we'll talk about. So, you know, what while it's time now to sort of rethink your Estee Hammers strategy, a little bit on greenfield, brownfield, just a reminder of what they are, those transition approaches, then we'll dig a bit into what we call selected data transition. So that is selectively taking some of the data to s four or to the target, why it's different, how we approach it. And I'll give you an idea as well in terms of our software solutions that we bring from our, group of businesses that we apply to what we call a Prism project. So Prism is our methodology and our branding around selective data transition projects. So, so we'll talk about how we approach those Prism style works. And I've got a few, examples as well and some scenarios for projects we've run around the world just to give you a little bit of context in terms of how we can apply that. And then we'll talk a little bit about how we can begin to look at your environment and understand options available if you're looking for this kind of selective, transition approach. Alright. So I'll start with the standard, scam message around ECC. So I'm probably so you're all familiar with this and you've heard it many times that, you know, support is coming to an end for ECC. You know, there's options available in terms of, you know, increasing your maintenance cost and pushing that support date out a little bit longer. There's also some offerings that have come around this year around, taking ECC into RISE and then later on converting to s four. So that might be a path as well to help with extending some of your maintenance, and support for ECC. But the key point is that SAP, are very much focusing to S4HANA as the replacement. It's the new solution. It's not the upgrade. It's the replacement to ECC. That's where people want to move. That's where they're spending their time creating innovation and new features and new functionality. And you'll see that in the partner ecosystem as well. So more and more partners like us and other vendors are focusing solutions and development and our development, plans and roadmaps to Estahana more than we would to ECC. So it's very much a stable working, piece of software, but it's very much, getting towards end of life and aging. So, what we see from that is essentially, you know, investment or money you're spending around ECC is becoming more and more a sunk cost. So we're starting to reach the age of the solution where time and money that you're putting into it is gonna give you potentially less benefit, less return on investment. So very much, we're looking at the age and the state of where we are with ECC that's, modernizing is, to s four is where you need to be thinking from an SAP point of view plus from a general business perspective point of view. So something we often talk about and we've sort of been articulating a little bit is, hidden cost of inaction around this. So maybe five, six years ago, we saw a lot of people saying, okay. You know, s four, it's obviously where SAP are going. That's the target state, but I'm happy to delay for a period of time. I'll keep running ECC. I can still patch it. I can upgrade it. My OS hardware database vendors are still giving me regular updates from my patch levels. Things are fine. But very much now that, cost of inaction is becoming more of a risk, and it's the inaction is a cost. So what we're seeing is, more risk. So delaying the move at this point, you're pushing closer and closer to twenty seven. It's probably a little bit more competitive to get resources and get hold of people to help with an s four conversion. You may have a regretful spend. So if you need to bring in something at the moment that helps, innovate within your business, that may, may not, you know, maybe custom code in ECC or it might be a custom interface out to another off the shelf product. Whereas if you're in s four, that could be standard functionality or it could be some BTP extension or BTP product, and an easier path to bring that in. So you're also leaving yourself open to potentially rewriting and rebuilding that when you move to s four. As mentioned as well, maintenance costs, SAP, they're going to start to move up the maintenance cost, on you. But underlying infrastructure, if you've got on premise hardware that may be reaching end of life to rebuy into hardware or do a cloud migration of current state becomes a little bit of a sunk cost as well. So it tends to be aware of those kind of things. You're potentially missing innovation, as mentioned. So things like JUUL, Datasphere, those kind of directions are all very much, assuming that you are in s four, potentially in RISE, potentially in the cloud type structure. And if you're not there, it's harder to access that inundation, harder to drive, your system in that direction. So all of these things sort of spiral into bottlenecks. So, you know, more complexity to move from current state to target as s four moves further and further ahead, potentially contention in the market getting hold of resources that can work on an s four project, people that still, have the knowledge of ECC as well, that part of the market, those people will start to fade off, fade off over time, retire and so forth. So it becomes more competitive. So, so what we're beginning to see effectively is at this stage of the SCC cycle, the cost of it of inaction is becoming more and more. So we're faced with a situation when we begin to need to look at moving to Esteehanna, how are we going to achieve that and what can we do. Alright. So in terms of getting to, s four, so in the market, there's always been two standard approaches effectively that SAP provides you. So one is greenfield. So this is a complete reveal. So you say, well, where I am now is not appropriate. I don't wanna bring anything forward. I'm going to reimplement from scratch a larger project, higher costs, longer time right timeline. You get the benefits of a clean slate, which might help in terms of realigning business process and setting things up, but potentially it's more destructive on your business because you're gonna have to lean on business teams for, you know, being part of the project, helping direct how the change is gonna occur. And we do see a little bit that sometimes that, falls in the overkill basket for most companies. So I do have an example of that later on, in this discussion where we had someone thinking that they need to go greenfield, but they didn't end up going in that direction after some analysis. The other side is brownfield. So this is what you would have always done, I suppose, moving between enhancement packs on ECC. If you went from an enhancement pack two to four to six, that's effectively a brownfield upgrade. So we can do the same effect, with s four. We can take the system as it is, convert it into S4HANA. So this becomes a technical driven upgrade more so than a business driven upgrade. The downside is we'll bring over legacy issues, you know, little bad business processes. We're not really having the opportunity to fit to standard or readjust business process. But the upside as well is I might wanna bring that stuff. I think because that's what makes my business, the way I configured and customized the solution. That does minimize, transformation, which can be good or bad, and then it can also bring across all of the data, potentially the wrong type of data or the wrong feature of data that you want in the target. So these are both valid options, but they sort of have the good and bad, that go with them. So, selective value transition. So you might hear this referred to in the market as well as hybrid. Often comes up as BlueField as well, which some other, vendors in the market use as a term. So, I mean, they're all interchangeable. So, effectively, what we're looking at is a strategy to go from ECC to s four, which is bringing a subset of data. So we're selectively bringing across what we want between the, the source and the target state. So with that kind of approach, we can then begin to make choices on what I wanna bring, and what I wanna accept in terms of the style of the project. So classic kind of triangle. So I've got risk, cost, disruption, planning my project. I can have two of those three. What would I like? So I might want less disruption, you know, but that has lower risk, so forth. So I can make choices in terms of how I wanna approach things to drive it forward. So with selective data transition, the types of things we can do is, just bring the data we want. So a good example of that might be, you your current system has multiple company codes. Only one of those company codes is relevant to your current business. The others relate to sold or divested business units, which no longer operate. So we can just bring that one item forward into S4HANA and leave behind the legacy data as part of that process. The, another opportunity that comes up as well is migration in phases. So you might roll out by function or region or business unit. It does make a little bit more of a complex, project, but it can be, achieved as well. A very simple example of that or probably the most, common example is taking HR and payroll first and moving that, to the target. So we'll quite often see people take HR and payroll out of the ECC system, move it to something like SuccessFactors employee central payroll, and then take the remainder of the ECC system and convert that to S4HANA, but we've dropped out the HR data as we do it. So we've separated the two components to the two directions that SAP is driving in terms of innovation, but, you know, not had to move the whole lot at once and giving you the best outcome. And then other goals as well, just simply reducing data footprint. So that'll help cut costs of contracts or hand the storage costs on the target state. So it helps you manage the cost of your RISE contract, manage the cost of your private cloud hosting if you're not going with RISE. And around that as well, we have, archiving solutions. So just being aware that all of these approaches don't take all the data to the target state. So we need somewhere to put the legacy data that remains behind, which is where we can help with an archiving solution. That we can also add things like transformation to it, so realign and restructure entities, consolidate parts of the entity and systems and modernise processes. So there's a way all different ways we can bring stuff in, and typically, we see a better time to value. So we're getting two s four in a quicker time frame than something like a greenfield, or in a better state than something like a brownfield. So that's where we kind of sit with this style and approach. And all of that, we brand up and we call our prism methodology, which is where that term comes in. Alright. So, another key point here as well is that even if I'm staking on brownfield or I'm taking on greenfield, some of the approaches and the technology we have around, around prism are still applicable. So I might have a stated goal on brownfield conversion, but I'm gonna do that in such a way that I create leaner and scrambled and anonymized, nonproduction systems. So that's using, methodology and approaches of the Prism toolset to help us achieve that. We can also do, a brownfield shell creation, copy of the bulk of the data, but we might just thin out things a little bit. So, drop some of the older data, maybe drop some of the logging temporary trans, type data from the system just to help slim it down, but I'm still taking on essentially a brownfield conversion. So there's light ways of bringing it into the approach, if you like. On the greenfield side as well, we can, extract data to file or extract data in formats that help with load into something like a private cloud, deployments of s four or also into, the migration workbench, concept for loading into a RISE s four system if even if it's not private cloud. So that tool sets that understand the SAP system, the SAP stack can help us get subsets of data for out of the greenfield approach or greenfield load. Another couple of important points as well when we talk about, prism as a methodology is we have two, main approaches or two main categories, and we'll talk about prism for technology and prism for business. So if you go and have a look around our, website, after this, you'll see some references to those two styles of project. So underpinning this is the same kind of project methodology, same kind of tool sets, same consultants, but it's how we're approaching the move. So it's it comes down to what your goals are. So prison for business, the goal, they're very much aligned with, transformation or change in the system to align with some kind of business need. It's the name. So typically, they're driven by mergers and acquisitions. So we might be carving out a company code or removing data to align with a new business that's sold or divested or merged. That can be quite common in that space. Other ones are like plant reallocations, managing master data comes up a little bit as well, just extracting data to send elsewhere. So it's very much driven by a business need. On the technology side, which is where we position the S4HANA style projects, these are more about helping create lean, secure target landscapes. And so we're more looking at ways to reduce legacy data, reduce the footprint, align the footprint to the target state, but taking it on more as, more fit to standard style if you like. Rather than transforming the data, we're just slicing along, typical lines within the system to make that occur. And then just another little last point in terms of, that transitional, that line between Greenfield and Brownfield. So it very much is a spectrum. So when we talk about a hybrid or a selective data transition project, it's not one size fits all. It can fit anywhere between almost brownfield or almost greenfield, and it's about bringing in the right technology and the right approach to help align with that goals. So as mentioned before, we could be simply helping extract a small set of data for load to a greenfield system, or we could be helping just clear down technical debt technical data, aligning more to a brownfield conversion. But it's the way we can bring the solution sets and the people to help with that style of project. Okay. So, what I'll talk a little bit more about now is the actual, solutions that we bring under the prism methodology. So this is a collection of different products, within Fuse Labs and also within our group of businesses. So depending on the style of project and what we're trying to achieve, we'll bring all of these or some of these, of these solutions to help achieve the goals. So if I start off the top there, we've got, around eleven o'clock, we got, system builder and shell sync. So this is part of our data sync manager, solution set. This is often the first point we start in these styles of projects because we wanna build, a target shell system that we can then begin to, load data in and create for the target state. So system builder shell sync lets us stand up, essentially an empty SAP system that has all of the, cross client repository data of your source, and then you can take that forward, for the project. The next up is client sync. So this is doing most of the work in these styles of projects. So this is client level copy. So we can copy client dependent customizing, master data, and transactional data. But importantly, this is where we can begin to apply the slicing and selective, nature to the data. So we can pick by a company code. We can do time slicing on transactional data. We can pick subsets of master data as well based around a company code or other enterprise structures. So this is the main part of the engine where we're helping, optimize and slice and reduce the volume of data, that comes across. The next couple of components, object sync, object extractor, also part of the data sync manager, solution set. This, allows us to selectively copy bits of data. So maybe a greenfield scenario, I might use, or very for a minimal brownfield scenario, I might use, object sync to copy across sets of master data, you know, customers, vendors, employees, and so forth. So I can do that in a very targeted manner. We can also extract to file. So object extractor lets us take the data out to flat file. So this is where I can bring things out to, like a migration work workbook, file structure to help load into a public cloud, or a greenfield solution for on the target side. So it gives us granularity and control over the objects that we're going to copy. And then leading into that is we have what we call archive central. So this is our platform where we can take the legacy data. So, again, that could be driven by the data sync manager engine, so the same technology that's doing object sync and object extractor. We can pull data selectively, into the archive, and we would typically use this at the end of the project. So once we've taken the selected dataset, moved it to s four, we can go back to the legacy ECC system and extract all the data out to this archive. And this is a SaaS solution, which we will host, and look after for you, but means you can turn off and decommission the legacy EC system and move forward on the S4HANA, but you still have a reference set of the data, in the archive solution, going forward. The next couple of areas, variance model and query manager. These begin to help into the data validation and testing space. So query manager is a reporting solution, so typically sold to customers of ours that are running HR and payroll for BAU HR, payroll reporting needs. But we can also bring it to this style of project to help with data validation, data listing, and checks of data between source and target. So it's quite innovative how the teams might use that sometimes to help give some review and validation, a check of data to then pass to a testing team or pass to a validation team who will then go on and do, deeper testing on the target. And in similar, vein to that, we have variance monitor. This one is more targeted specifically just to HR and payroll, and it's about variance around the payroll solution. So, again, if you're, you have payroll in the system, you're moving to s four, we would use variance monitor to do period to period comparison or data comparison between source and target just to ensure, everything's working. So there are two ways that we can help surface and bring data and information to testing and validation teams on this style of project. Next up is what we call data transform. So, underpinned by data sync manager, but this is essentially the engine where we can begin to do, things like, plant renumberings, you know, helping transform data to align to single company codes, chart of account changes, all sorts of different things. So there's a wide variety of ways that the team use that solution, but it's very much around the transformation of the data to align to a new business fit as part of, this one of these projects. And then it will, also call and execute S4HANA conversion functions. So if we're bringing data into the s four system, we'll then transform it and then call the standard routines to prepare the data for the s four target. Next up is another HR specific one. So APUs Australia is the team that have built this. So this is data orchestration. So they use it mostly around SuccessFactors projects, so helping to bring data into, the SuccessFactors environment. So, again, if we're in a situation where you've got on premise ECC payroll, you might be looking to go to ECP with SuccessFactors or maybe s four with SuccessFactors. This is, the type of engine that team can bring to these projects to help populate and build out the SuccessFactors, side of the solution. I also learned this week as well that they're starting to make use of this a little bit more around, if they have a public cloud, projects as well, which is, quite interesting and quite exciting. So, yeah, I'm looking forward to learning a bit more how they're making use of that for the data on take into public cloud. And then last area we have is a partner solution called LT Posting Engine. So this comes up more in the complex transformation projects or projects where we're staging the go live and rolling things together. So the teams will use this to automate postings. So we might be changing chart of accounts or assets or some kind of, financial area, which I often understand. And this helps them, do the posting and do the update, do the change in an automated manner as part of that cut over and as part of that build of the solution. So it kinda rolls out the picture of bringing in the targeted data, transforming it to align to a new structure, preparing it for S4, and then using the posting engine to top up and build, the last of it for the cutover. Alright. So that's kind of a constellation of the products that our teams would bring for these styles of projects. So if you're looking at any kind of, transformation carve out selective move, we bring this under what we call a prism project, and these are the solution sets that the teams would make use, within that style of project. Cool. Alright. So I'll just talk a little bit on the technical side in terms of, migration. So when we are talking about moving to s four, the most common thing that happens is we're as I alluded to a little bit earlier on the last slide, we're creating a shell system and selectively bringing data in. So what that means is, we're building the target initially. So that's where the system builder or the shell sync components come in. So that means we can take a copy of the r three system, but just the, you know, cross client config repository data, client triple zero, and then creating a new shell system. You would then go through an s four conversion on that, and then we would populate the active working clients. So we bring across client dependent customizing, subsets of master data, subsets of transactional data to build out the system. So this is the basic building blocks. So we're creating the target shell, converting it, and loading in, this subset of data that you need to make use of, running the standard s four, post conversion routines, and then users and roles are available as well. So around the users and roles, of course, there may be some work in terms of re, you know, updating, role design, updating access, but again, that just becomes part of the project. So that's kind of the basic building blocks of how we technically bring the data in. So what we're slicing, what we're bringing, how we're approaching the reduction is going to be different for every customer, but that's the standard kind of look at it. Another question that comes up a lot as well is about downtime minimization. So at some point in all of these style of projects, you do need to cut over productions systems. So the downtime or the outage time of that always becomes an important component, early in the project. So we're trying to fit to some downtime or outage window. So the standard, direct migration options that SAP provides to go from, Brownfield from ECC to s four do have some downtime minimization. So they'll do post processing, the main conversion, and post. So they do what they can to help prevent, maximum downtime of the systems during that cutover. They also have a near zero downtime offering. So this is, I haven't checked lately. Well, there's always an additional cost option and a special style of project so they can dramatically reduce the downtime. Specifically, that's only appropriate to customers that are incredibly sensitive to a cut over period or a downtime, duration. So what we've done is we've sorta found something in the middle, which we call optimized downtime. So this is how we approach the build of the target and the move across of the data, so that we are basically staging and aligning things and minimizing the data the amount of time when we need to do the final copy. So much like spoken on the last slide, we're preparing the shell ahead of time. So there's a blackout period where you're not making, repository changes or configuration changes. So we create the shell of the system, have it prepared as SyscoHANA, ready to go. We do the bulk of the load in, in a series of batches, extracting different sets of data from the source, with Client Sync, and then we do final, finish off runs during the actual downtime period. So we don't, you know, don't try to replace or, detract or better SAP's near zero downtime, but we find this is kind of a happy medium between the standard migration approach and, the extra cost and the very minimized approach to the near zero downtime. So it's just ways we think about that cut over to help reduce and bring down that impact of the final go live. And last thing I'll talk a little bit about for Prism is how we wrap that up as a methodology, and what we bring into that style of project. So we have our kinetic methodology that our project management teams, will drive, in terms of these types of projects. This is based on SAPS activate. So if you're familiar with that, the names and the layout of this is will be familiar to you. But, essentially, there's two broad phases. There's an engineering and pilot phase, and then there's the main project execution phase. So in the engineering and pilot phase, we do some assessments, workshops, maybe, an initial pilot or engineering run, which might be a sandbox conversion or a very rough build. So that allows us to just understand and validate what we've done from a workshop point of view and give you visibility of what the target environment is, going to look like. If everything's good, you kick into the main project phase, then realize and breathe. Other two areas we'll probably cycle through. So there's usually three to four cycles depending on the size of the project. So there might be that initial engineering run, build a dev system, build a test system, then a dress rehearsal, which is a trial of the go live and then the actual final go live. So, there's multiple opportunities to roll through the cycle of, building and testing and validating the target system and then adjust outage times and downtimes and durations as part of that. Yeah. So that's all how we approach the style of project. So as mentioned, there's usually three to four cycles to reshape and test. These projects will vary depending on complexity. You know, we've had, some in the range of four months. You know, maybe, like, a five to six months is typical, but it does depend on how much transformation, how much reduction, how many testing cycles, are required, to fit to that. Okay. I'll finish up here with just a few, case studies. So these are, other organizations, that we've helped, around the world in terms of some kind of, selective transition or move to S4HANA, style process. Just give you an idea of the types of projects that the team have run. Okay. So first one up is, this is a European based company, so working with one of our partners in Europe. So we came in as a data expert technical, type partner on the project. So the challenge here was they had a single ECC system. They're looking to do, a move to S4HANA, but they had, around two hundred, two hundred and fifty business units or sub companies within the organization spread across fifty odd company codes. And, a large most of those then had, their own controlling area, their own, chart of accounts, multiple currencies, different currencies under each of those. So it was quite a complex structure, and their main goal was basically just to merge everything to one controlling area, one chart of accounts, and convert everything to common currencies. So this is based in Europe, so they were looking to, you know, standardize things around European dollar or US dollar as the target, as well as have support of other currencies. So the end outcome of this is a single step migration, but helping them transform the data. So merging all those company codes, merging the controlling areas and managing the data, so that they lined up and then made sense in the target. So this is, an example of quite a complex business driven transformation. So very much about transforming the data to align the target system with the structure of their business. So the styles of choices they're making in this project are the conversion and cut over time is less important than the target state I want to be. So that my business benefit is I'm happy with a slightly longer cut over time because I get so much business benefit out of, the restructure and realignment of the system. So that's a quite a complex end of how the solution can be used and how we can achieve that kind of goal. Well, another example here, again, showing different capabilities within our, group of businesses. So this is, obviously, California based Judicial Council. In this case, they're moving to s four on Azure, hosting and managing themselves, so not part of a RISE contract. So what we can bring to that is our technical operation teams. So they're, infrastructure basis, you know, database style experts within that team. So we're building up the entire, Azure layer infrastructure as a service and platform as a service for them, and then using our, s four conversion teams to subset of the conversion into s four on that target. So it's, the way we can bring technology teams within the business to take care of the bottom layer as well as, teams that can take care of the complexities of the data within the S4HANA system. So it just shows some of the styles or the breadth of, support that we can do within the group of, businesses. This one here is first group, so UK based, trains, transport based, business. In this case, they would I made a choice to go to, a greenfield deployment of S4HANA private cloud, and they're working with another system integrator around that build and prepare of that system. And it became apparent that they were gonna need help in terms of moving the data from their source ECC to the target greenfield. So we came in as a data management, expert in terms of the project. So we're not replacing the other SI. We're not taking over the whole project. We're just simply working in with them and bringing our expertise around the SAP data management. So we were able to extract and transform the data into a format that they can then take forward and load into the target, greenfield system. So it was very much about being able to understand the source data model, extract the data, apply transformations in a repeatable, consistent manner to help with, with that project. So that's just another way that we can bring different styles of technologies to different, types of projects. Last one I'll mention is a local one. So this is a Australian based, Powerlink. This one is a little bit different. It was a brownfield conversion, but sort of the message here for this is that they initially started believing they were gonna have to do a greenfield conversion. So, that was where they would position themselves. They thought there was no way they could take their current system forward, straight to s four. So we got involved, did a sandbox conversion. Excuse me. Did it initially did a basic sandbox conversion for them to show their system as s four, and then go involved to help with the remainder of the conversion. So, the lesson there for them was by doing some initial analysis, visualizing things in a rough sandbox, they were able to say, well, I don't really need to go down a full greenfield path. They were quite happy to do the brownfield conversion and then take on an innovation program afterwards to change business processes and update things. What we did bring to this project was, reduction and scrambling of nonproduction systems. So as part of it, we were able to build out additional lean dev systems, add lean clients to test systems to help support test cycles, and things like that as part of the process as well as do that final, conversion for them to s four. Okay. So, I mean, if you all this stuff is of interest and you're looking to understand a little bit more about how we can apply, these styles of concepts into your landscape, basic first step is what we call a preflight assessment. So this is a small transport, that you can get from us, load into your system, and you get a free report. And we're gonna have a talk about what it means in terms of potentially transforming to s four where legacy data is or legacy issues might be in your system. So there's a QR code on the screen there that'll take you to the site where you can, have a look at the registration page to, go and grab that and have a look at, how it works. But, yeah. So this is the thing that helped Powerlink. Initially, by looking at this and then doing a sandbox, they were able to change their ideas from a greenfield end of the spectrum down to a brownfield end of the spectrum. So this we feel this is quite important as an initial way to get an idea of what's happening. It'll give us insights around technical code, you know, data volumes, breadth of the functionality you've got, third party add ons, that type of stuff. It's by no means a replacement for SAP's tool sets or something like Signavo, but it's a very easy way to get an initial appreciation of what you might wanna consider and what what you might wanna look at in terms of, target state. Alright. Yeah. So I'll wind it up there. So just a quick recap. So in terms of this style or this approach, these are some of the, yeah, the common ideas to choose. So you can pick and choose. You can, migrate without rebuilding the entire system. You know, you can split or consolidate landscapes, de risk the process with automation, anonymizing nonproduction data. These are the kind of ideas, that we can bring to help with a conversion project around SDA Ana. Alright. We'll pass to questions in just a moment, but I'll just leave this slide up. So, we are running some, user group events or Inspire events, at Fuse Labs. So if you happen to be in Sydney or Brisbane on those dates, if you just grab those links or those QR codes, you can go have a look at the event, and, welcome to reach out and register if you're interested in attending. So it'll be more people like myself talking about interesting topics like this. So it's a user group event if you would like to come. But, I'll hand back to Michael. I think we might have a fraction of time for questions because I run a bit long, but, all good. No. That's fine. Thanks, Daniel. Yeah. We do have a few questions, and we might not get to them. But if we don't, we'll, we'll pass I'll send them to you, Daniel, and, you know, you can have a you know, and some of them, you know, might probably need a bit of a considered approach. But, look, this first one is more, I think, just a, you know, in a comment. So SAP rename renames RISE to SAP cloud, the app, the private. I mean, if you got any comments, that's it. They seem to have done it fairly quietly. So Yeah. They did that a few, months ago. Yeah. So I'm still struggling with it. I talk about Ryze a lot. So much time in my cheese trainer. But, essentially, so that they've got Grow and Ryze, those sort of names are a little bit different to what they were. But the technology and where it sits and how it works is all still the same. It's just them cleaning up or changing terminology. That's all. Yeah. And sort of similarly, like, there's still a lot of confusion around what's the official end date of, end, official end of life date for ECC. Is it two thousand thirty? The so twenty thirty is if you pay some extra maintenance. So the twenty seven is standard maintenance. As I mentioned, there is you can take on a RISE. You can take ECP into RISE now. That's another offering that's out there if you have a look around on the SOP websites. I think that might help you get a little bit of extra maintenance, you know, maintenance time as well. Yeah. But, I mean, from a planning point of view, twenty seven is probably the date to focus on if you're willing to pay more twenty thirties there. Yeah. Yeah. And look, the final one, I think the other questions are probably you know, we've gone over time. They're more sort of detailed. But there's one, do you have any, client references or credentials for selected data transitioning in the Australian and federal government? Federal government, I'll have to check. We might have something around HR specifics in federal government, but, yeah, I'll have to go. So we'll check that one. I don't know any off the top of my head. Yeah. Not a problem. Look. Thanks everyone for your interest here. We've gone just a little bit over time, but really, you know, a lot of, interesting questions. And we will, hopefully get those questions answered, and then we'll pass them around. Just a quick announcement. This is the last webinar before our biggest event, the, national summit. Very only less than two weeks away, second of September. Fantastic customer speakers, transforming and modernizing post RISE business cases, S4HANA, cloud, LP, Teluf stuff, AI, everything. Make sure you check that out. And there's also events happening after that, so don't forget about those. Check the SAG website. And also, if you're in Perth, WA, eight eighth of October at WA Connect. So have a look. Make sure you, register for those. Thanks again to FU Slabs, Daniel and Kat behind the scenes. I hope to see you at another event soon. Thank you.