Modernising SAP HCM:
SDT, Carve-outs & SaaS
without re-implementation

Everyone, thank you so much for attending today, as part of our de risking SAP, S4HANA webinar series. So today's webinar is on, modernizing SAP HCM, with STT carve outs and SaaS without re implementation. I have Daniel Parker here and Jessalur, Romigio, who are gonna be our expert, panelists today. Today is gonna be a little bit different than how we usually run our webinars. We have a few slides just to introduce today's topic, and then we are going to be running it as more of an open discussion and a bit of a chat. So it should be really engaging and quite an interesting session. As always, if you do have additional questions to those that are answered as part of today's session, there is a question box in the top right corner of your screen. You're welcome to jump in there at any time and pop a question in there, and we will answer it at the end of the session. There's also a chat widget if you are if you wanna have a chat in there with the other attendees as well. As always, this session will be recorded, and we will be sending out the slides and the recording after the event so you can share that or re rewatch it at your convenience. Other than that, I will hand over to Daniel to introduce our speakers and to get started. Thank you, Kat. Welcome, everyone. So today, we'll be myself and just Sella having a bit of discussion and taking on q and a around this topic. Cat mentioned we can answer questions at the end, but we're totally fine to grab questions as we go. So I've got the q and a box visible to me. So if you've got questions as we kick along, please ask, and we can fit them into the discussion. But, yeah, I'm the solution architect with EPI-USE Labs. So I've been working with the organization for some time now. So focusing around sort of, you know, technical management, installs, presales, like that off to the solution sets that we make use of around these styles of projects and to sell her as part of our transformation team. So she's been working with the product sets as well around migrations and, you know, carve outs. She's working on a few fairly large HCM migration projects at the moment going to S4HANA and also ECP, which is kind of the topic that we're digging into a bit today. Okay. So I'll start with a few slides, as Kat mentioned, just to sort of introduce what we'll talk around, and then we'll just sort of to and fro with a few talking points and questions. And as mentioned, call out if there's any questions along the way. So transformation of HCM is quite a complex piece. And as you're probably all finding out, it's really being driven at the moment in the SAP world by ECC support deadlines. So there's some urgency around making sure you're running on a supported platform and making sure you're moving to a platform that's supported in terms of your payroll solution. And because of that, people are facing a bit of a balancing act around operational continue continuity and transformation of the system. So looking to take advantage of moving forward from ECC and trying to find a line between fixing the old and not upsetting payroll. And that's usually driven by the fact that the risk tolerance for payroll is extremely low. It's generally not your core business, but it's core to your business. So you don't want to interrupt that in any manner. The other driver we see is around mergers and acquisition organizational change as always. That's always in the market. So people needing to split or maybe merge systems based on an organizational change or the sell or purchase of the business unit. And then the other thing adding into this is if you've been on ECC for some time, you may not have moved into a SaaS type arrangement for your the more HR side of the model. So you've got some HR functionality in ECC that's depreciated as you move to s four or you move to ECP, and you need to pick up something like SuccessFactors or a similar solution and run start to run a hybrid landscape, which may be different to the way you've done things in the past. So all these kind of complexities and these things that are driving urgency in the market. So people fully people trying to decide between lift and shift or forward reimplement. And often those two are not practical. There's too much risk with the full reimplement, and the lift and shift may not be appropriate in terms of what you're trying to achieve with data volumes and the like moving forward. So just to paint it in a slightly different picture, but again, yeah, it's about that sunsetting and ending of ECC, SAP moving us to a target state around what is effectively ECP and SuccessFactors. That's kind of where they want everyone to be from a HR payroll and HCM type functionality set. So it's finding your way there. So there's various options. Maybe if you are still on premise, you're probably on extended maintenance by now. Maybe you've transitioned to HANA and compatibility packs have run out or about to run out. So maybe you've gone h four s four. If it's still where SAP are wanting us to sit and where they're innovating, where they're developing is around ECP, around SuccessFactors. So that is the kind of a core driver. People finding a way down to some kind of host account cloud solution with SuccessFactors or Workday or something in front of it to give them the long term support for the payroll and the like. So how do we get there and what are the issues around that is what we'll chat on a bit today. And then lastly, so as mentioned, you know, sometimes it's a choice between just take everything as is and reimplement. So we'll talk about some concepts around selectively moving there, which is the work that just so is involved with at the moment around some projects. So taking subsets of HR data or taking just the HR data out of an existing system into the future state with that s four or ECP or something like that. So yeah. And ideas around testing, you know, looking after sensitive data, potentially transformation of some parts of the data as well. So there's other areas that we might touch on today. Okay. So what we'll try and do is we'll just talk through some key themes which are around the main phases of any style of project and especially these styles of project. So we usually start with some kind of preparation and planning phase. We'll talk a little bit about that. Then we'll talk on some ideas around execution and actually managing the separation or the copy of the data, a little bit around testing and validation, capitalizing on that, going into BAU, and then just sort of finishing up there. So, yeah, again, call out if you have questions as we go, but we'll keep a bit of a conversation going initially. So preparation and planning. Where I'll start this to seller is just, you know, once you sort of have the need that you have to make change, you gotta do something. So there's factors I was talking about around sunset of ECC and similar. So what when a company realizes they need to make change and carve out, so what is what are some of the critical factors during the assessment phase that can help avoid a full implementation later. Did you wanna have a couple of thoughts on that initially, Gisela? And then I can Yeah. I can add in. Sure. Yeah. I think the single most critical factor during the initial assessment of the migration is defining actually the future state scope and also the target operating model before any data migration begins. So we have to analyze and realize first where we are and where we are heading into. So if the business doesn't clearly, like, identify what the target organization will look like, such as which legal entity, which employees, or which organizational structures or payroll process will they be moving, then they are, having a huge risk in migrating unnecessary or incorrect, data. So that often leads to, redesign work later, which can turn into a selective migration, or turn a selective migration into what effectively is going to be a full migration. So for me, it's clearly defining where we want to be at do with this migration. Okay. I mean, how can that be impacted as well if they're picking up something like SuccessFactors or a hybrid landscape? So people might be coming from a situation where they don't have SuccessFactors. Have some of those ideas around getting the operating model relate to SAP in the planning stage. Yeah. So the planning stage will give us, like, a clear cut view of where we want it to be. So that also includes not only limiting ourselves with, let's say, s four or ECP, but there are various avenues out there where the customer can jump into from their ECC system. One of the most common right now is actually jumping into SuccessFactors. If they don't have any SuccessFactors yet, implemented on their system, then we can help them, during this migration. So we will also, help not only move historical data for them, but also related information with implementation of their SuccessFactors system or environment. Yeah. So it needs to be a key consideration upfront, basically. So you're looking to move the legacy payroll as well as define how you're gonna bill Yeah. The SF at the same time. The two parts of the same project. Yeah. Okay. I'll talk maybe I'll talk a little bit about the selective added transition. So how does that make more sense than a full reimplementation? So what we often see in the planning phase, people may think that they want to kind of throw everything out, redo, restart around the payroll. But usually, that comes down to may maybe there's legacy data sets in there. So you might have some old business units. You might have a lot of old data for those business units. Whereas if you can selectively pick what you want to take forward, then you're better off bringing the current setup to current configuration. So that's another one. So early in the process, trying to identify, you know, how to avoid reimplementation. So the idea of reimplementation because everything's old and no good, I've got a lot of legacy data, that may not apply as well. So thinking about selectively moving forward and bringing the config is another stuff that comes up. What about misconceptions about moving to the cloud in the planning phase? Do you have any thoughts on that? People might be coming from on premise. Is there still misconceptions around cloud use out there to consider? Yeah. Most of the time, the biggest misconceptions when we are hearing that organizations or customers are moving into cloud is that they think that it requires a complete greenfield implementation. So in reality, many organizations can achieve their cloud strategy without a selective the through, rather, a selective data transition rather than a greenfield implementation. So just for the context, the green field here means, like, a full reimplementation. So they don't need to do that. They could use FTT in order to do their migration strategy into the cloud. This would help them preserve their data processes and also, like, configurations that continue to provide business value while modern modernizing only the areas that may they need to change. Exports. Yes. Yeah. So that idea that just because it's a new system and it's cloud doesn't mean that you can't bring across a lot of the existing work and legacy that is good for you. Yeah. That's a common misconception. And just one last point on the preparation and planning is around, you know, initial analysis or automated analysis of the source system. So this is something that we make use of in our what we call a prism project. So making use of our tool sets and products to move HR to new systems. We have an automated analysis program, and that'll help with the very base level technical stuff as well as some ideas around the complexity of your payroll. So it's a Prism HCM report. It gives us the basics in terms of what country areas are implemented, are you unique code, your patch levels, volumes of data? And that's it's all very technical. It's not so much business process, but that can really help inform the preparation phase in terms of ideas around how you can be selective in terms of the copy if you know, potential easy means and easy fixes down to prepare for these kind of projects. So that's another thing to not under a very clear picture of your current data footprint and technical setup. Alright. Just a few ideas around that preparation and planning. Just thinking about getting into one of these projects. I'll jump into the sort of like the next major phase. So just for argument's sake, we've kicked off. We're into a project. So what ideas and what can we think about in terms of the execution and the data separation? So in this phase, we're looking to actually move data from what would be the legacy into the new. So how do we go about that? So maybe just so let's just have a chat around the mechanics of the data slicing. So, you know, what does that look like in practice? What kind of things can we do with a selected data transition and the types of projects you work with? Yes. So in the execution and data separation, this is how we play out what we have already planned and analyzed in the previous phase. So this will now be the actuality of what we have already defined in our scoping. So if you know where you are heading into, what you wanted to move into, then there are various avenues that we can try in order to, help you bridge or do the migration of your payroll. So first and foremost, I think we need to define what this data slicing is because, as you know, there are migrations out there that does pull and some does slice or, like, selective. So in terms of our migration strategy and methodology, the data slicing is the process of selecting only the payroll related data that needs to be migrated while preserving all of the business and technical relationships. So rather than copying the entire payroll database, you can just identify relevant, let's say, employees, population, and time period based on those agreed migration scope. So for complex structures of your payroll, so slicing process start by defining first the population. So we define first who you wanted to migrate. Do you only want to migrate active employees, inactive employees, certain company codes, and those stuff. Do you want to retain ten years worth of your payroll data, five years? Let's say, for example, your organization is already working or established forty years, so it already got forty years worth of data. Now you're going to move into a migration wherein it will be moved into the, let's say, cloud system. Do you still want to keep the forty years worth of data, or do you want to keep just the last ten or even five years of data? So this data slicing will help you, do exactly that depending on your migration strategy. And with data slicing, it also, enables you to save space in your system. So you're not going to move huge volumes of data. In relation to how the migration methodology works, since we know that HR has this interconnected dependency across different objects and tables, so our Prism methodology and Prism tool would be able to get all of these interdependencies with each other in relation to a data slicing. So most of the time, we get this data slicing from, let's say, mergers and acquisitions, carve out. So, you take, let's say, one enterprise from, one system, move it into another, or merge it to an existing system. So these are very good examples of when you can leverage the use of data slicing instead of full data copy. Excellent. Is there anything to consider around time slicing payroll results? So it's quite often that people may not wanna bring the full payroll legacy. So is there Things to think about, like retro calculations and ideas like that? So what are some stuff to consider? Yes. So retroactive calculation is, just part of everyday payroll. So it is something that is already in viewed in every payroll activities. And to have a successful, payroll migration considering future retro that might happen after we have migrated the master data is to analyze and reconcile the payroll itself first before the migration. If we are going to do a data slicing and we wanted to ensure that no retroactive inconsistencies or issues will arise in the future, then we have in the planning phase, we have to define until when the data needs to be sliced. So if your oldest active employee is, like, say, twenty years or thirty or fifteen years, then we could have the data slicing for only this selective employee. So we can transfer them separately with a full payroll data in order for them to do successful, like, retroactive, because we don't expect retros to go way, way over years. It's just a few pay periods. Yes. But over five years, that's really not something that we see in payroll anyway. So there are different, different ways wherein we can still copy and a slice data, which ensures that we can also do retroactive pay result calculation. Cool. Yeah. It really sounds like it's key to the business outcome. So if you are looking to reduce the volume of payroll result transactional history, then the initial question is what is my retro impact? What is my business process? And making sure that's driving how you go about it. But, yeah, that's good. But probably another thought I was just thinking is the data model is not just master data and transactional data. It's driven by configuration. So if we are moving, you know, from on premise to cloud, what can we do around configuration? Obviously, we can bring the subset Of config tables related to HR. But, you know, what does that look like, and what should be considered or what's important In terms of moving that config across? Yes. So for configuration standpoint or for from a configuration point of view, it is important that we have control and efficiency in moving all of these configuration tables and structures. So we first need to know what we will migrate over. For payroll migration, that would mainly involve your master data information, payroll information, seldom things related to the postings and stuff. And, accordingly, the migration that we will do in terms of configuration will have to be around or centered around that area. Also, we have to consider the system to where we are going to migrate over this data. So if it is a, a merger and acquisition, for example, so it the target system is already there, existing with some other entities involved, What we don't want in a configuration migration is we overwrite whatever is there on the target system in such cases. If it's a clean new system, such as moving into an ECP system wherein the system is only for payroll, then it is more manageable. But, just make sure that what you are copying over or migrating over into the target system will not disrupt the target system in itself. So the PRICEM methodology in itself already has this set of table, which we consider important and impacting in a migration. So oftentimes, we sit together with the customer in order to analyze what they want and what they don't want included into a configuration migration. Excellent. I suppose the last piece of the puzzle then is any workbench objects. So from a table structure point of view, you know, HR and payroll, you know, an ABAP system is pretty good. You might have custom info types. You don't often have a lot of Z tables, but there's still gonna be some need to take your custom table structures, maybe some ABAP programs and things like that. How is that usually come up and get managed around, these types of projects? Yeah. So, the first step is to always have these custom programs and custom objects, assessed. So that may mean having a separate code assessment to determine whether they should be retained, they should be modified, or replaced with standard functionality. So often, this custom code remediation is typically being handled in a parallel technical work stream. But in our precision methodology, the custom info types, custom tables that contains business critical data, so we can always extract them, transform, and load the data just as it, does for your standard SAP objects. So the mapping rules, are configured based on the target data model, which ensures that these custom fields and records are migrated with the correct relationships and dependencies. Okay. Excellent. So we can take the subset of zed content, if you like, repository content that's required and bring it across, which Yeah. Helps with the no reimplementation or the no greenfield approach, which can be handy. And lastly, so we've sort of been talking about concepts of moving the data as is, so selectively picking what we want, what's relevant, moving it without change. What about transformation of the data? Does that come up much? And what type of things do people do? I know I get asked from time to time about things like Maybe like a cost center reference within the master data. So, yeah, do you see much need to transform parts of the data as we move it from old to new? Yeah. So, it actually depends on the type of migration that we do. Seldom, if there's SuccessFactors involved, yes, they do. So the replication of data from your SuccessFactors down to your, let's say, ECP system may require some transformation in order for the go live data to actually flow, smooth in the system as well as the payroll. So we often see some transformation that needs to happen around that area. And, of course, as we know, HR is a very sensitive module of, SAP, especially payroll side because it is, it has very little tolerance for errors. So these transformations that we introduced during migration should be assessed of what their impact would be, especially during pay runs so that we don't encounter any redesign at this phase. Because at this phase, this is already execution and data separation. Excellent. Oh, yeah. That's certainly possible, but as you say, it adds to the verification and that kind of load. So it can be done, but we need to be conscious of what it means Yeah. As part of the process. Yeah. HR is interrelated. So it is a complex sensitive module that is interrelated with highly sensitive tables and its stuff. So planning is really important in order before we even do execution, of course. Yes. Excellent. Alright. Let's we've touched a little bit on testing and validation, so let's jump into that. So, again, arguing about our fictional project. We've moved some data. Now we wanna think about how we test that or how we validate that. So this can be often quite time consuming. So, you know, things I've been involved with in this style of project, we might often have, like, an initial engineering or development run, a test run, parallel payroll processing run Yeah. Maybe a mock conversion, and then a final production version. So you're gonna have quite a few repeating test cycles. So, yeah, that can lead to a lot of work for different teams. So some what are some concepts or some tool sets and ideas that you see helping around the testing and the validation phase for these style of projects, just so Yes. So it's very important in a migration that what we are migrating from should be still the same to where we are migrating it at. So it's the first validation that we need to settle first. In order to do that, of course, there's lots of things and lots of data around HR itself. So we have a tool that can effectively check line per line, record per record, field per field, whether what we have migrated is still intact in the target system. So within the Prisma methodology, data integrity is highly tied up to how payroll run. So if the data or the master data to where the payroll is getting its calculation from is incorrect, then the values it will calculate will also be incorrect. So the integrity of data is important in order for payroll testing to happen. And in these types of migration, we often do at least three cycles of run. So this will help us identify early on in this stage whether there are items that needs to be considered in, doing up sound and correct payroll testing. So it's not just one time that we do migration and then test it and that it's good. No. It's not one time. We do it in the phase. In a typical environment, you have your dev system, your test system, and then eventually your production system. So we often do these testings, validations, and developments if need be first in the lower environment. So this will help us cut whatever we may be missing because just to itinerate, the migration is a continuous process. It's not just something that it's done once and it's done. So it's a continuous process. There's improvements. There's development. But one of the biggest and most important is the migration of data itself. And how we do testing and validations to that data is highly dependent on these tools that will enable us to have confidence that the migration of this data actually work. Cool. Okay. So we can compare source and targets and look for variances and understand what those impacts might be, which then helps automate the testing, makes the testing about the functional outcome as opposed to reviewing the actual data move itself. Yeah. The another thing I was just thinking about is sort of dual transport maintenance or change maintenance during these types of projects. So a typical project like this might take, you know, four, five, six months depending on complexity. So during that time, the current payroll can't stand still. So there is still gonna be change occurring in configuration. Yeah. So what kind of things do you usually see happen to help keep the new environment aligned with the source and not impact testing or allow testing to verify the changes that are coming through from the legacy environment. How do you normally incorporate that kind of stuff into the projects? Yeah. Correct. So migration takes months to finish. The fastest, I think, is around four a month, three to four a month, depending on how big the organization is. But the key fact here is that it will take months. And within that month, the legacy system is still moving. So it's still functional. Payroll is still working there while we move or migrate their system into a newer one. So, of course, developments, changes, transports are still being done in the legacy system while we do our migration. In our approach, what we do is we keep tab of each of these changes transports that moves up till the production legacy system because these are changes that would need to also be moved over into the new or target system. So we keep a tracklist of all of the changes that happens in the legacy, align it with the target, and make sure that the code and all of the, let's say, workbench customizing changes are still intact when it comes into the target system. Of course, depending on the kind of configuration that happen, you can always see the result or impact of it when you run payroll. So let's say, for example, you are, already halfway through your migration, and then suddenly this new wage type for a leave has been implemented on your ECC or legacy system. So, of course, that needs to also be moved into the target system. So how can we know that once we move it to the target, it still works is we run a payroll, and we do a comparison. Oftentimes, a parallel run payroll to identify whether we are getting the same results in your source versus your target system. Okay. Excellent. There must be some point, though, in a project where we need to have a freeze. So does that occur quite late in the project as we're getting ready for the production move? Yeah. Oftentimes, the freeze is close to the production move. So often, it is in between one week to I've seen two weeks, of, change free. So during production, it is very critical since this is oftentimes the last, migration that we do. We move over things in a live production data. But in the phases wherein we are still doing parallel runs, UATs, and the unit testing, the BAU system or your legacy BAU system is still ongoing their usual change request. So we allow them to still do these changes, but we compile everything before we do the actual migration cutover plan. Okay. Excellent. Yeah. So when you consider some of things that might be a six month style project, we're actually looking at, like, a one, maybe two week freeze period. So it's certainly something Yeah. Even though we are doing quite a lot of surgery to move selected data between systems. We're not impacting the usual business process except for that small production cutover area. So it's quite an effective way of doing things. Cool. This last point around that as well. So something that comes up a lot in testing is, especially with HR, is sensitive data and the privacy of that data. So we often see a need to scramble or de identify. Did you have any thoughts about so as we're doing these trial migrations, then verifying, how often do you see customers wanting to scramble or de identify, say, change bank accounts, telephone numbers, things like that? Is that a common need? And how do you usually sort of fit that into these projects? Yes. Actually, there is a common need, this kind of data. More often, it depends on the industry to where your customer belongs to you. So if it's a banking, they are very or highly protective of their data. Though environment phases wherein we do migration first to, let's say, dev or tests, often, don't want members to see the live data of customer. So what we do is we help them or engage them in making sure that we are still performing the migration while the data is masked or scrambled for their security sake. So, of course, this scrambling or masking of data will not happen in a live production cutover, but oftentimes, it can be seen in lower environments such as dev and test. And most of the time, the data that is being masked would be employee related, personal identifiable information. So one of those can be your name itself, birth date, your government IDs. So these are the types of things that we can scramble during migration with our pre SIM methodology. Also, to add, that does not only limit the masking or scrambling at the legacy or ECC payroll side. We can also do masking, especially if the customer, has all, SuccessFactors, EC instances. So we can also do the same with SuccessFactors so that at least their EC or Employee Central instance as well as their, let's say, ECT or SAP instance has the same scrambled value. Excellent. Perfect then. So, yeah, keep the two aligned even though they're scrambled, which is which key this is Yeah. Which is often key for them. Cool. Alright. So I'll move on to our last sort of main topic area. So moving into BAU. So you've completed the migration and things we can then do to start to capitalize. I'll ask myself a question first. So at the end at this stage in the project, if we've selectively moved into the target, we're often left with a legacy dataset of some sort. So maybe we only took active business units or only took active employees. It's quite common to have a whole bunch of data in the ECC source, which is no which we want to keep, but we might don't necessarily wanna leave it in that system, or maybe that system's going to be decommissioned. So archiving comes in a lot. So we often help people at this point around like a non SAP legacy archive solution. So SAP has got standard archiving, which is more about data volume reduction in an active system. Whereas we have a what we call Arcup Central, which is an archiving solution to take a legacy dataset, put it into that archive. It's got its own front end. It's got its own secure storage. It's a SaaS solution, and then you can turn off the legacy. So that's often a big need, and that can actually help the ideas around being selective. So sometimes people don't want to be selective in a project because they don't want to lose that data in case they need it. But having somewhere safe you can archive too, like this archive central solution, decouples that risk and allows that to occur. Yes. So it's quite common for HR and employee data to be one of the main areas that we load to that. We've worked with a few customers recently that have done migrations into ECP, and we've taken legacy datasets into the archive. So for me, that's a really key way to capitalize in the BAU. So you've selectively moved, but you don't really capitalize unless you've freed up the old system and can turn it off. So there's one area. Maybe question for you, Justilla, around as people sort of move into the hybrid Environment. So pick up the new area. We've got ECP, maybe SuccessFactors, or something like that. So what are some things to think about in terms of managing that or being more efficient around that hybrid world that might be mean moving into as you go into BAU? Yeah. So oftentimes in many organizations, hybrid HR landscape is practically a reality. So for example, your SAP HCM payroll remaining on premise, while your talent management for and HR functions moved to cloud solutions, such as your SAP SuccessFactors. So the key to managing this successfully is having clear system ownership. Ownership. So we standardize your integration and strong data governance as well rather than trying to, duplicate data across these multiple systems. So during the migration itself, we help establish a clean and also reconcile data foundation, which reduces the number of integrations needed after go live. So the key factor here is that if you are handling or governing multiple hybrid HR landscape, it is important that data in one, system is the same to the other system. So it is important to standardize data models and then implement and then monitor, for these changes on, let's say, interface and then automate and validate so that we can make sure that the data you are governing across your different HR landscape are the same or aligned with each other. Excellent. Yeah. That's yeah. That's a key one as well. Yeah. Perfect. Alright. With that in mind, let's sort of move to wrap up a little bit. So what's if you had one sort of key lesson or key learning that you've picked up over your time supporting these kind of projects, what's one kind of sort of takeaway or one thought you would leave people with to help manage or think about this style of work? Yeah. I think based on the migration that I've handled so far, planning is the most crucial, thing yet to consider. Of course, execution, validation testing, stuff, those things comes along, but they are highly dependent on a sound planning. A sound target in mind where you wanted to move over your data. Because if you have an idea on where you wanted to move, the next questions will arrive. What I wanted to move, how I will move there. So all of the next phases, execution plan, execution, testing, and stuff will revolve now around that thought. So the lesson here is that as long as you have a clear cut plan and a clear cut, idea on where you wanted your system to be in, let's say, in the next five years and ten years, then the migration would be able to specify the scope and limitation to get you there. So the for me, that's the most crucial of them all. So the planning, the scoping, and what you wanted to migrate. Yeah. So that the long term vision. So what is my where do I wanna be with HR and payroll in five years? And then it helps lead back into that. Yeah. Because I've seen stuff wherein in the planning phase, if it's not clearly defined, the next phases would go, Aury. So Yeah. It might require more testing, redesign, and these things can add up into the timeline. So, of course, a migration is off forever. It has a time on when we need to finish the migration. Of course, it's a business need. So we plan around this thing and make sure that our migration journey is as smooth as possible for our customer. Well, I had similar ideas. I think planning is kinda key, yeah, understanding, you know, where you want to be, and then that leads into exactly as you're saying as to what's important. But since you stole my idea, will start. Another key one I see is around in that testing phase or the testing phases, being ready upfront in terms of infrastructure and clients and datasets, we often see projects getting into those that QA and the mock and the parallel run. And it's not clear exactly where you're going to do that bit of work or where the data sets coming from or should it be scrambled? Shouldn't it be? So early again, this is a planning thing, but thinking about early how many testing cycles, what data sets, you know, when will I need them, how will I need them, that style of stuff. I can see that I often see that taking up a bit of time sort of mid phase in a project because it hasn't been put through too properly as well. So again, it's a planning theme, but it's angling into coupling what is my landscape gonna look like to support my testing phases because that stuff can take a little bit of time to get in place sometimes. Alright. Excellent. Okay. Thank you to Sella. We'll wind it up there. Yeah. So, hopefully, that was useful. Just observe a talk through some ideas around high level phases for a, like, a Prism HR transformation style project. So we're selectively moving from maybe your ECC legacy into s four or ECP, that type of word world. So thoughts and ideas around how you can approach that, things we bring with our consultants and our product sets to help in that space. So hopefully, was helpful. If you wanted to learn a little bit more about what we do, so the type of work Gisela does day to day. So this is what we call prism for payroll type approach. So using our product sets and consultants like Gisela. So selected data transition. So you grab that link there or grab that QR code, and you can have a look at our bit more information about how we approach these projects and what type of things we do and some success stories and relevant cases around it. So grab that if you wish. And then lastly, up upfront, Kat mentioned this is part of an ongoing webinar series around transformations and derisking them. So from that code there or that link, you can go to the main page for all the webinars in series. So I think we're probably about halfway through them at the moment. There's a whole bunch lined up. There's a couple more coming in July. So something around what happens to the data left behind charting the S4HANA navigation. But I think that one's a little bit more on the, like, the business process side thinking about how you move forward in August analytics. So a bit more to what happens to BW style of data usage within your landscape as you move to S4HANA as you move to cloud and then something around data governance in the transformation coming in October. So there's a mix of technical things and a mix of business process and big picture type things. But, yeah, jump on that page there or that via that QR code link, and you'll see the long list of webinars that we're running on this series. And with that, I will wind it up. So thanks for your time, and thank you, Kat. I'll hand to you if you got any other things to state or mention, Kat, before we wind up. Yep. I just wanted to mention I hadn't seen any questions come through, so I hope that means you guys covered the topic really well. We do actually have two sessions coming up in July. One is I'm running the series, so one will be led by me, and I believe the other one is going to be led by my colleague in, in Asia. So two different topics on different dates with some different speakers, but both on the, de risking S4HANA, theme, which is good. As I said, this will be recorded. I'll send this, recording through early next week for you to share as needed. Please also, when I send an email, you can reply to it to get straight directly to me. If you have any other ideas for what sessions or formats that you'd like us to include in this series or future series that you'd love us to run, please let us know. We'd love to hear from you. Thanks again for attending, and we'll see you at the next one.