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

My name is Kat Haig. I'm the head of marketing, for EPI-USE Labs Australia and New Zealand. If you guys have ever done a webinar with us, you've probably, heard from Daniel before, but I will give him a bit of a formal introduction in a couple of minutes. We will just give, everyone a few minutes to join before jumping in just to make sure everyone can kinda get the content from the start. But just a bit of housekeeping for today. As always, today's session will be recorded. So if you wanna share it, if you need to drop off before, you know, we get to your question or something, we will share the recording post, the conclusion of the event probably early next week. There is the ability to ask questions. You won't be able to turn on your mic or camera, but, there should be a button top right of your screen, where you can populate a question in there. And once we get to the end of this webinar, we'll, we'll go through and answer those questions for you as well. That's pretty much it. So, yeah, Daniel Parker, he's got over twenty years of SAP experience, really strong base experience. He's been with Labs for a very long time. He does webinars like this all the time for us and is very, very knowledgeable. So, all of your detailed questions, I'll be very comfortable to answer. And, really, today, we're really just gonna be talking about that journey to s four HANA and the complexity and the risk and the challenges that sort of come along, with that. And in particular, I guess, how to think about your data as you plan for that move. So it's likely gonna be about half an hour of content, and then we'll do some, some q and a towards the end. But feel free to drop in those questions, anytime you want, as you think of them, and we'll, we'll answer them at the end. Without further ado, I think that's probably it, and I'll hand over to Daniel. Thanks, Kat. Welcome, everyone. So I'll start off first. I'll just mention a little bit about EPI-USE Labs and just a bit about our organization, and then we'll step into the content as Kat mentioned. So EPI-USE Labs, if you're not aware of this, we're a software based business. So very much into creating solutions predominantly around SAP, but not exclusively SAP. And we've been building and creating software for, you know, well over twenty odd years and running transformation projects, which I'll talk a little bit about today for over twenty years as well. So very much R and D focused creating solutions for our clients and then using those solutions on complex projects is what we're about and we're part of a bigger group of businesses called Group Elephant. So there's a range of other business names or business banners under that as well. And yeah. So one percent of the revenue from Group Elephant is channeled into a program we call Elephants, Rhinos and People, which is about helping alleviate elephants and rhinos in sort of an extinction and population issues by helping to get people out of poverty in Africa. So it's a good program where we take revenue from the group. So everything that we do with our customers contributes back to that program to help Africa, which is where the organization is from. We are oops. Too far. We're also a global business. So started out of Africa out of the University of Pretoria, but we were having very much a global footprint and then local teams and local delivery teams around the world. So we've got a good time zone coverage and good presence in the majority of areas where we do business. Okay. So I'll jump on now into today's content. So we're gonna talk, as Kat mentioned, around SAP HANA and systems and data and things related to that transition and move to s four. So this is kind of like part five. There's a bunch of content we've been doing. So that was happening last year. So you see the blocks on the left there, things we've done previously. If you have a look on our website under events and webinars, you might see some of these recordings or content related to them. But we've been talking a little bit about the move to s four and particularly the move to rise, but not exclusively. So things such as saving cost around your non production systems, making them smaller, making them more efficient which cuts down on infrastructure costs or rise contract costs because you've got small systems, small HANA appliances. That's one more area we've spoken a bit. We've also talked about reducing risk, so data privacy in the non production systems. So under a rise contract, you should not be storing production data or production PII directly in non production. That's part of the terms in some of the contract. So it's ways we can de identify and de risk that. It's another area we spoke on. We've talked about the nature of RISE, how SAP pick up a lot of the infrastructure support, some of the basis support. So you might have a gap or an area to fill and how our tech ops team can do bridge managed services around that. So helping harmonize the gap between your teams and SAP in terms of the management of the system and the contract. And then lastly, there was a really good session which is being repeated in or run out of Europe soon, which I'll mention later, around optimizing costs for licensing. So if you're not aware, when you go to an SAP HANA license, there's a concept of full user equivalent and the way they count and cost your user accounts and licenses change. So there can be a big cost impact. So that's a very good discussion point around that. But if you have a look on the website, you'll see those previous areas we've spoken on. And then today, we're gonna talk about the actual migration and things we can do around the ECC to s four HANA move for that ground or greenfield, depending on how you want to take it on. So that is today. Okay. So we sort of had a phase or a cycle with the move to s four where there's a reasonable number of businesses that have moved, but there's still others which aren't quite adopting or moving on. And we're seeing basically, hidden cost of inaction and risks around that. So if you think about it as maybe seven years ago, it was probably okay to say, well, I'm happy with ECC. I'm just gonna wait and see a little bit on S4. So you were gonna buy yourself some time. We don't really feel that's the case anymore. So three twenty seven is coming. Twenty thirty, if you extend maintenance. So the ways of staying in support and on ECC are getting more and more thin. So that is increasing your risk. So cost adds to that with things like regretful spend. So if you're enhancing, customizing, and working on your ECC system right now, when you go to s four, those are things you need to consider, you know, at least review, adjust, rework, change to support s four. You might be on premise legacy infrastructure for older database types, so that's not directly gonna s four support an s four database type or HANA database. So you don't want to change that infrastructure. You wanna make that change part of the Sfour move, so you got a rising risk and maintenance cost for that. You could be missing out on innovation, so no easy access to a AI. Some of the embedded concepts, CRMs, BW coming into the Sfour stack are not as easily available to you. So you might be piecing together a shoestring solutions to make innovation rather than adopting what is easy available under s four. So these kind of things can lead to a transformation bottleneck which impacts bottom line. So we certainly see the market in a costed in inaction phase at the moment. Those that haven't moved or aren't maturely thinking about how they're going to move, trying to buy time, may actually just be adding to cost and adding to risk. So what does it mean to move to s four from an ECC system? So there's typically pretty well discussed and well talked about two paths, greenfield or brownfield. So greenfield is basically starting from scratch. So you might be at a very well clear technical debt aligned to what the business wants to do, but you're probably gonna have a longer timeline, higher cost, more effort and time spent with the business to make it possible and probably more disruption. And we feel in a lot of the systems and a lot of the customers we talk to, that's probably overkill for most use cases. The other approach, which is certainly more common and more popular in the market, is just a brownfield conversion. So doing a technical upgrade or which is actually a conversion of the system into s four. Certainly, the technically easy approach, but it'll carry across technical debt. You know, there's minimal opportunity to transform or align the system to your business as part of that conversion, and you potentially bring a lot of the wrong or too much type of data. So technically, easier to go but has its downsides as well. So what we'll talk about today is sort of a path in the middle. So selected data transition and what we call Prism for SAP HANA. So Prism is our terminology around these styles of project where we're helping to selectively take data from ECC to s four or from a source to a target production system. So it's about a modern migration strategy somewhere between greenfield and brownfield. So it gives you the ability to modernize a little bit without as much cost or risk or disruption to the business. So you can bring the data you want, leave behind maybe, you know, outdated company codes that no longer relevant to the business, bring forward what actually makes sense for the s to hannon environment. You can potentially migrate in phases, so rollouts by function or region. So keep the two running in parallel, minimizing business disruption. It does change the nature of the project a little bit, so you need to be more aware of, like, the integration layer and how you're managing those two systems. But it can be a way to take on a softer longer rollout. A key one is about just reducing the footprint. So leaving behind legacy and old data and using a tool set like our Archive Central to put that legacy data into cut costs on the target, helping align the business better to the target so it helps with your transformation goals and just simply better time to value. So if we're taking on what is a simpler style of project, you're gonna be able to deliver that a little bit quicker than a more complex complete rebuild is the intention. So those ideas in terms of selectively taking data and with what we call Prism, we can apply that both to a greenfield and a brownfield approach. So if we're, say, pushing into private cloud or maybe rise or an on prem, we can bring that to a straight brownfield conversion. As I mentioned, make smaller non production systems as well as maybe time slice or drop data from the production system to give you a smaller target. So, basically, lean by design and also applying scrambling to the non production systems. So that's kind of the most simple way that we can help in that kind of approach in terms of leaving behind legacy data and aligning better to the target. On a greenfield implementation, so they're either gonna be a private cloud, maybe RISE, or the SAP HANA public cloud option. So with these, with our Prism approach, we can help with selected copy of small subsets of data. So maybe copying master data, maybe just building a lean private cloud edition system, which is, you know, Workbench configuration and then putting a small set of data into it, or maybe helping extract data from the source in a migration workbook format it's easier to load to the public cloud when you're seeding and building that public cloud solution. So there are ways we can fit directly into those two conversion types. And then when we think about Prism as a solution set that we apply into these types of projects, we class it into two areas. So we have what we call Prism for technology and then Prism for business. So the Prism both of them are driven by the same groups of consultants and the same software set, but it's just thinking about what we're trying to achieve with the system change and the business change. So on the technology side, it is very much about structural change to the system with it with minimal or no impact to business process. So we're gonna make smaller, leaner systems. We're gonna anonymize and de enter de identify data in test systems and but we're not impacting the structural nature or the business process in the system. On the prison for business side, this is where we're getting around a carve out or a reduction or a logical change to the system. So we're actually trying to align with where the business is now and where it not wants to be and then fitting that into an s four context. So it might be a split occurred many years ago, and you've got a legacy company code you no longer use. We'll take the active company codes only, leave the others behind. Plant renumbering, reallocations are common, you know, helping on master data management, those kind of areas are common as well. But this is very much thinking about my system doesn't match my business now, so how do I adjust my system to match my business and match my business in the future? We think of that as a prison for business concept. But, yeah, the selective data is part of each of those styles of work. And whether it's greenfield, brownfield, or something hybrid in between, we're always thinking about how we take forward the exact dataset we need, putting legacy datasets into archive, not into the ongoing production system, and trying to reduce the costs and better align to the business in the target. So we feel that selected data management very much has a role to play regardless of the S4HANA migration approach you're thinking to take, greenfield, hybrid, or brownfield. Alright. So I've spoken a lot about our terminology in terms of Prism and how that is the theme that we approach for these style of projects and this style of work. So but what is it? So Prism essentially is a solution set. It's a range of different products that are a mix of EPI-USE Labs and others from within the group elephant business that we bring to these style of projects. So each of these are something that we sell in a business as usual context, but we bring them to the transformation project context as well to help with reduction or slicing of a system. So if we work our way around the wheel starting up here just before midnight through to about two PM, we're looking at well, two AM. We're looking at parts of Data Sync Manager. So these are our test data management solution that we've had for many years, but we're also using that in a Prism context with our transformation teams to slice, build, create SAP systems. So this is sort of the core heart of what we're doing. So we can create shell systems. We can copy subsets or slice clients into the shell, and then we can bring individual objects. So, you know, business partners, customers, vendors, materials, accounting documents, purchase orders. So we have the ability to build up a system and bring subsets of data with this to fit the scope of what we're trying to achieve. Next up here, we've got what we call Archrock Central. So since we're selectively moving to a target, we're gonna have a legacy dataset left behind. You may not want to get rid of that. You probably don't want to continue to run a read only ECC system as well. So Archive Central is a SaaS solution where we take that data in a read only format. It's securely stored, and it's got a front end and a relational model, and we can display and dashboard and view that data without needing to maintain the legacy system running. So that is a common area that we're helping people going through selected transition to deal with the legacy data. Next up, we have two functional focused solutions, so Query Manager and Variance Monitor. These help us analyze the data in the built system comparing back to the source system. So Query Manager is a reporting solution based around HR, but it'll work across the whole ERP or s four stack. So the teams will be using this to review and check data that's copied into the target and make sure it's there down to a line level as to what they're expecting and helping analyze what's being built. Variance Monitor is doing a similar type role, but it's very specifically related to HR and payroll data. So in a project that includes HR and payroll, we bring Variance Monitor to do a period to period or system to system comparison around parallel pay runs to help verify that data. So these help ensure the integrity of the built solution. Next up, we have a transformation software. So I've talked about things like plants renumbering. So we may use that if we need to do structural change to, you know, helping realign company codes or merge company codes, renumber things, rename things, even down to very, very simple things like truncating a single field or clearing a single field on a table to meet what you want in the target. So that is essentially a transformation engine runs in the SAP system. It can be part of the data copy or it can be run post the data copy depending on what we're trying to achieve. That helps us align the data for a very specific reason to the business need. Next up, another sort of a HR specific space product. So this is from within Group Elephant. So data orchestration, BTP solution, focus to SuccessFactors. Again, if we've got a payroll related project or HR related project with Employee Central, this can be used to manage the data movement, transformation, conversion in and out of the SuccessFactors Employee Central component. And then very lastly is what we call a posting engine. So this allows us to manage open items and financial posting and transactions. So if we're doing some kind of rolling or staged conversion, this can be an engine the teams will use to keep things in alignment between different systems. It can play an important role depending on the style of cutover or style of project. So all of that is range of what are actually off the shelf BAU products, but it's our teams bringing them under the Prism banner and under a Prism transformation style project to drive more complex consulting needs and system change needs with you. Now what does a hybrid migration actually kinda look like? So if I have a little bit of a gentle technical look. So essentially, we're gonna start from an e c r three e c six style system, and we're gonna go to two s four, but we wanna bring a subset of data. So the way we can do that with some of those Prism solutions is we can create a lean target or empty shell system. So we basically have the table structures, code, client triple zero within the target, and that's it. And that can be built up on target infrastructure. So maybe it's on a HANA database type. It might be s four already or it might be converted as a second step. And then into that, we can selectively create or slice the target clients so we can bring all the customizing and subsets of master and transactional data depending on how you're trying to reduce or selectively transition into the target system. And then we might convert that to s four or depending on the cutover needs and cutover durations. It might be a one step where it's already an s four system and we're managing the conversions. So at a very high level, it's essentially creating a lean shell and putting into it the subsets of data we need, and then wrapping around that processes around verification, hosting, transformation, if required, with those other parts of the Prism solution set. I alluded quickly to cutover and downtime just then. So downtime minimization or a production cutover comes up a lot as a key need. And, yeah, a lot of projects will sort of live and die based on what is the cutover window for a production conversion. So the tool the standard tool sets SAP gives you if you're doing a brownfield conversion are actually quite good, and there's a lot in there at a very general level to help you minimize that cut over time and that downtime time when you're going ECC to s four. SAP run a very specialized team, which is a new zero downtime, but that's quite expensive and not many folk would be looking for that kind of cost or that time of that type of very, very minimized cut over time for a go live. So with Prism Solutions, we have what we call optimized downtime. So we're sort of finding a little bit of an in between. So for those customers that want a shorter period than the standard conversion might give them, but they don't want to go to the rolled voice solution that SAP provide with the new zero downtime. So optimized downtime, same kind of processes I was talking about on the last slide, but we're building the slide and building the shell system. And on the target, turning it into s four and then staging into that batches of copies of data with the at a client level. So when we reach the downtime period, we've already built the bulk of the system, and then we're finishing off final cutovers, maybe using something like the posting engine to keep things aligned. Then potentially, we start the downtime, then potentially, we do some transformations and we execute the standard logic around preparing data, you know, for s four, that's b w accounting and so forth. So the idea is that we're rather than starting downtime, putting the data in and moving forward, we're actually staging data in during the pre downtime phase. And we find this helps some customers if they're looking for a bit of a happy meeting between the brown brownfield conversion and the more expensive new zero downtime from SAP. And then all of this, we kinda wrap up in a project methodology, which is based on SAP's activate. So very loosely working through to the same style of projects that SAP would advocate with Activate, but we start with, you know, engineering pilots blueprint style phase. We have an automated assessment which we run on the source ECC system, and that allows us to understand technically what the system is, what the data footprint is about, where the complexity is, and the our transformation teams will use that to help scope the high level projects, provide costing guidance, provide guidance in terms of the ways that you could potentially optimize and how you could selectively reduce. We use that as well to then step into workshop blueprinting design type assessments and then define exactly what we're trying to do for the project and work out how we go forward. And then the first initial phase is what we call Sharpen. This is where we actually start work, and we'll do the initial conversion based on what we've decided from workshops. So we're creating the first target system, doing selective data transition on it, and understanding what the gaps are, how we need to optimize, how we need to establish a better process for the rest of the project. And then that gives you the first chance to then verify, test, understand gaps. Then we would kick into the main project execution phase, and this will begin to look pretty similar if you've done any type of upgrade or conversion style project with SAP and we just reiterate and repeat cycles. So typically, we'll do two initial cycles where we're building a dev system and a test system for you typically coming from production. So it's better aligned with what your reality is of coding configuration and creating smaller lean systems in the target. Then we do a breast dress rehearsal, which is just basically kicking through hour by hour as we would do production, making sure everything's gonna go to plan, and then the final go live conversion and a hypercare period. So all very, very standard. But the key point is what we can do up front in terms of assessment, preparing, and doing a pilot phase. It's kind of a some of the key stuff. Alright. I'll talk about a few quick case studies now, the customers we've helped. So this one here is a technology company. They were doing a direct conversion into SHANA, so one step. It's a few years back now, so they were going to s four twenty. The main thing they were trying to do was merge and migrate a whole bunch of company codes. So multiple company codes merged into one in the target system. There was a bit of work done around as well around single chart of accounts, you know, changing currencies, adding global currencies, and also fix takes out some issues with the GL. But the key thing there was coming from a quite a complex company code structure into a new enterprise structure, merged, renumbered, aligned, and cut over direct into SAP HANA. So that was quite a large and successful project. Another one, this one is more on the technical side. So rather than how we can manage the data within the system, this is more about how our technical operation teams can manage a landscape. So a fairly large complex landscape moving to Azure, converting to s four. So we're moving all the systems across using some of the concepts I was talking about in terms of selectively reducing systems to create smaller non production environments, supply scrambling, So cutting down the cost of non prod and then helping move platform. So changing OSDB, moving to HANA, and preparing for the future. So this is applying those product sets and teams for a larger enterprise or a larger infrastructure style move is the success there. And this last one is around a greenfield and very selective transition. So UK organization moving to private cloud with a new system and wanting to bring in just small subsets of data. So effectively, yeah, the sets of master data and a little bit of transactional data. So we're able to help them to selectively get those objects, move them across to the target as part of the cutter, as part of the conversion to s four. So it's a very selective top up of the new environment with only the data they wish to bring across. Alright. So I mentioned before, like, preflight assessment. So what does that mean? What is the first step? So if these ideas, these kind of concepts in terms of how to approach an s four conversion are interesting to you, the first thing we do is ask you to run what we call an analysis transport or a preflight assessment. So it's a small transport goes into your ECC source system, something with production like data footprints or maybe a sandbox that's a copy of production. This will collect essentially a whole set of metadata. There's no business data and no PII. We can't really tell anything about what your business is transacting or doing, but we can see quite good analysis in terms of the data location, the data volumes, the enterprise structure, those kind of ideas. And from this, we can look at so things like functional analysis. So this is a breakdown of known data objects within your system where we can manage or copy or control or do something within individually. So essentially, SAP standard table areas where we can see or manage data. We get a larger high level footprint. So in this example system, there's quite a lot of basis data. So there might be some large technical logging tables which aren't really needed. So this helps us understand what's happening. We get things like accounting document history by company code. So this can be really, really helpful to spot company codes that are no longer in use or if you've got a lot of legacy data that you might not want to bring to s four. So we get a bit of a timeline of document counts by company code to help sort of analyze what might be happening. And there's other things as well in there around the complexity of the enterprise structure, things like a very high level look at custom code, custom tables, third party components, and tables. So we bring up a very good technical view or technical footprint on the complexities of the system and how we can approach that from selected transition, production, privacy, scrambling, those kind of ideas, which helps lead into good discussions around how to approach the work with you. So why would this style of approach, this Prism approach be helpful rather than straight brownfield or starting again from greenfield? So it's gonna help you keep parts of the system that you want to hang on to or leave parts of the system on premise, take other parts of the cloud. So it's very common sometimes to pull HR out of an ECC, put it into Employee Central Payroll. So you leave behind the rest of the system on premise, but you take that to cloud. You customize what you can converting to s four, selectively bringing across subsets of data, then basic things around the non production landscape. So scrambling, reducing, de identifying stuff in non production, and helping to optimize or reduce technical cut over time and down line down downtime, as well as options around business process oh, sorry. Business harmonization of the system to where your business is now or will be. So, you know, changing company codes, plant renumbering, those styles of concepts can come into it as well. So if you're looking for a little bit more than just straight brownfield conversion, then doing the work later. If you wanna achieve some key goals as part of the conversion, this is where it can be helpful and a good approach to look into. Alright. I'm almost done there. I'll mention a couple of webinars that are coming up. So if you're interested, just scan that QR code link there. It'll take you to our website where you can learn a bit more and register. This one here coming up at the end of the month, so it's been being run out of Europe by a gentleman called Roy, part of our global privacy and security team. So this is around the licensing strategy under s four. So at the start, I mentioned full user equivalent and costs around an s to HANA license and use accounts changes that occur. So have a look at this. If the time zone's a little bit horrible, you can always watch the recording. But Roy is an expert in that team, so he can give you a good idea in terms of what to think about as you move to an explore license and how they can be quite large cost impacts if you don't get the user setup and the access setup correct because of full user equivalents. So that is very much a good one to have a look into if you're not aware of those licensing and user cost changes under in the ACE four licenses. And then early March, I'll be helping a little bit on this one, but my colleague, Giselle, is gonna present a session around integration monitoring. So this is using the Query Manager product set I mentioned very briefly before. So this is a way our customers would use Query Manager in BAU, business as usual. So they're keeping and monitoring between SAP and SuccessFactors. So it's a very HR specific use case, but it's quite a common one. So making sure the replication between e c or e c six, s four, ECP, and SuccessFactors Employee Central is working and behaving as correctly, and also being able to see data differences and understand why things are different. So that is quite an interesting one. And just so that we'll be presenting that in March. That one will definitely be during our daylight hours if you're interested in that. Alright. Excellent. I'll wind up there, and I'll open up for any questions. Just have a look in the questions box. There's a couple there for you. Cool. What have we got? A question around related systems like GTS, EWM, GBT. I can't see oh, there we go. I can see the rest of it. So what can you do if we're migrating them standalone or if they're embedded? Yes. So yeah. It's been present. So Daniel's for everyone. Might be worth reading the question out. That, this question is, also, if you, if you related systems like actually, I'll let you read it out, Daniel, because you'll have more context. Alright. No worries. It's basically asking, also, do we do around related systems like GTS, EWM, GBT, that might interface back into an ECC system? And if you're gonna migrate those standalone or if you're gonna potentially move to embedded versions for those. So, yeah, that is a good question. So the landscape is not just ECC. So we're talking very much about converting ECC to SPAL, but you will have other things around it, maybe CRMs, SRNs, EWM, that style of stuff. So the selective transition, the carving, those kind of concepts, we can apply to things like CRM, SRM, BW, EWM, SCM. That's a little bit less common for those. But, generally, we can apply it to most of the systems where there's a large data volume and some kind of inter enterprise structure or similar type approach to it. We don't usually work on moving or embedding the data so much back into the s four when it's on a stand alone, but we can certainly help reduce or slice them. Usually, the effort to, say, take a CRM or SRM and reimplement it in s four is a little bit more than just moving the data in so that they become a little bit of a different consideration. But, definitely, we can work across other parts of that style of landscape as well. Yep. And then there was another question there. On prem? Yeah. Sure. So, yeah, I mean, I'm talking a little bit about Rise and some of these concepts in a Rise situation, but they it very much applies to on prem. So if you're ECC on prem at the moment and you're gonna go to S4HANA and continue to be on prem, whether that's your own physical hardware or you running your own Azure or AWS instance. These concepts apply there and can all be applied in that style of hosting as well. Cool. Awesome. And there's just another one here. What is the minimal downtime required for production in your experience? Yes. Good question. So, I mean, usually, we look for, like, a weekend to perform the production cut over. So we're typically asking upfront for, you know, at least a forty eight hour period, so the Saturday, Sunday. Sometimes it might stretch to sixty hours, so, like, we close a business Friday to start a business Monday. And that's a safe place to start because the reality of what you might need or get negotiated back to could be a little bit less. But, typically, we're talking, like, twenty four hour cut over periods. And so we're looking for six to twelve hours either side of that for safety. But, yeah, twenty four hours is usually typical. Thanks, Daniel. And then I've got, so many businesses have requirements for retaining historical data for a number of years. Do we have solutions for that? Yes. Definitely. Yes. So we have a an archiving solution I mentioned, Archive Central. So if you're just taking a subset of data to s four, we can take the rest of the data from the legacy system, put it into Archive Central. It's SaaS hosted. You access it via a web browser. It's all secure. It's got its own front end. And then you can retire and decommission and turn off the legacy system. So that'll support SAP, supports any type of data. So if we can get CSV files from non SAP legacy systems, we can put them into there as well. That's quite a cost effective way to, retain access to the data for as long as you need without having to look after or manage a legacy system and legacy hosting needs. Awesome. I think at the moment, that is it with the question. Oh, sorry. There's a couple more here. Are you able to elaborate a little more capabilities related to S4HANA public? S4HANA public? Yeah. Cool. No worries. Yeah. So for the public cloud offering for s four, it's very much around helping get the data into migration workbook format so we can take data out of the source ECC system, small subsets of it, ready to load by migration workbooks into the public cloud and then archiving the legacy sets. So the reality of going to public cloud, if they had a public cloud, is you're not gonna bring all your data. You're gonna bring us, you know, the master data you want and a small subset of transactional data. So you're gonna be left with a large volume in the ECC system. So we can put that into our cloud central for ongoing storage and access. So they're the two key areas that we help around a public cloud. Awesome. Thanks, Dan. Then we've got another one. So if a business is taking the opportunity to transform and simplify, would you recommend develop developing business domain information architecture and then mapping that to s four? Transform and simplify. I'm not quite sure what. Would you recommend to y'all stumped me. I've been stumped. So well, I mean, the I suppose the intention is you're looking to transform and simplify. We're also accepting that we wanna take some of the legacy forward. So we're not necessarily going to re redevelop everything straight away on the go live stuff. I've got a whole bunch of custom code that I know might be better done in BTP or it might be better done in another style of app or brought into embedded CRM or something like that. We might not do that on go live. We might simply say, okay. That's gonna work under s four, and then that's part of my roadmap to move to BTP and decommission or make it part of an embedded CRM. So the goal of the transformation is to leave behind some legacy data, realign large structures like the enterprise structure and things like that to match where the business may be, and then set up a road map of that clean core and those kind of concepts. So, hopefully, that helps a little bit. But maybe reach out if needed. I can see your email details as, so maybe I can pop you an email. We can try and work it out. Yeah. Cool. He has said that he's done this all he has a lot of unnecessary legacy processes that are possibly redundant. Okay. Yeah. I think I was talking in that direction. Yeah. So maybe you choose to bring that into Sfour initially and run that. And once you're on that platform, then you iterate and retire those and move them to clinical concepts or move them to standard concepts. Yeah. And then there's another one here, and I think maybe we'll cut off questions after this one. And, any others, I'll send through an email, and you can send through an email with your questions. Does the archiving solution use classical approach, or is it ILM based? Okay. So for the archiving, when we are taking data from SAP to Archive Central, solution, we use components of Data Sync Manager. So it's our using our own technology to extract the data and send it directly into our archive. So we're not dependent on SAP Stara or SAP's ILN technologies, whatever they call it these days. So we had our own technology set to get the data out for that style of archiving. Awesome. That was some great questions. Great to see some engagement there. So that's it. We'll, we'll wrap it up there. I'm going to, send through the slides and the recording. I'll also send through links to those other webinars, in this series that Daniel, mentioned earlier, as well as the two ones that are coming up, the previous ones that we've run, on this series as well. I also just have a quick poll I'm just gonna share. So just to let us know if there was a lot of engagement here, a lot of questions, just mark in the poll if you would like us to reach out, and we can have Dan Daniel and our team can have a kind of one on one conversation and help, answer any additional questions you have and, and, you know, speak about your specific, use case and scenario. But if not, thank you again for joining us today. This year, we've got a lot of webinars coming up, so I will keep you posted on, on anything that is relevant, and, we'll hope to see you at one of the, the future ones. Thank you again so much for your time. I'll leave that poll up for a few minutes, but feel free to drop off if you like. Thanks again. Thanks, Daniel, for your time. Thanks, everyone. Bye.