A smarter path to SAP S/4HANA: 
Modernizing with selective data transition

Alright. Hi, everyone. Thank you so much for joining us today, for our session, a smarter path to SAP S4HANA, modernizing with selective data transition. My name is Sarah Enders. I'm on the marketing team here at Epiuse. Labs, and I'm so happy you could join us today. We are recording the session today. So if you're not able to attend or you have colleagues that wanted to attend, we'll be sharing the recorded version with you later on. So today, we're gonna break down how a selective data transition approach can give you the flexibility and control you need for a smooth migration. We'll cover the risks of traditional greenfield and brownfield approaches and how SDT can help automate them. So we have a couple speakers with us today. First, we have Jamie Nielen. He's our SAP transformation global service line lead here at Epiuse. Labs. He specializes in Prism and SLO and leads the practice in those areas. He has over twenty years of experience in SAP and has deep expertise in s in SAP data projects and transformation strategies. Next, we have Joey Jollimore who recently joined us here at Epiuse. Labs to help North American clients with SAP data migrations, including s four migrations, transitions, m and a, and selective data transfers. Both Jamie and Joy bring deep expertise, and we're excited to have them join us today. So we'll take questions, but we'll take questions throughout the session, but we'll answer them at the end. So you can pop them into the GoToWebinar panel, and we'll do those at the end. So let me turn it over now to you, Joey. Thank you, Sarah, and welcome, everybody, from where you're joining us today. It's a real privilege to be in your company, the company of forward thinking professionals who are collective collectively navigating what's perhaps one of the most significant business transition SAP clients have faced since y two k, which is determining the right time and the right path to migrate to next generation SAP technology. Today, Jamie and I will explore the various paths to s four HANA and why now is a critical time to evaluate or even rethink your modernization journey. We'll discuss the pros and cons of greenfield and brownfield approaches, and introduce a compelling third option, which is the selective data transition, or SDT, which really offers a balanced path forward. Finally, we'll share how our technologies and methodologies here at labs, including Prism and Archive Central, can really help reduce the time, cost, and disruption associated with such a pivotal transformation. And so we're getting to that. So before we dive deeper, I really want to take a few minutes just to briefly introduce who we are here at Epiuse. Labs. Epiuse. Labs is one of SAP's ecosystems, probably one of the most quiet success stories I've ever heard of. Before joining Labs, I'd actually not heard of Epiuse. Epiuse originated in the labs in South Africa, and we've grown since then into a global organization with a presence in over fifty five countries. Our teams are embedded across Africa, the Middle East, Asia, Europe, and now a growing footprint all across North and South America. Our mission here at labs is simple yet very powerful, and it's really about delivering value through innovation. For over twenty years now, we've helped several organizations around the world transform their SAP landscapes with cutting edge technologies and deep technical expertise. Our deep expertise in the SAP data transformation combined with our industry leading Prism solutions has helped organizations around the world modernizing with confidence. Our solutions are s SAP certified, and we hold a trusted membership in the SAP APOS network. We consistently deliver measurable results, which includes reducing cloud migration and costs up to fifty percent in some cases. Our client renewal rate sits at over ninety seven percent, which is a true testament of our professionalism and hitting the mark on projects. We have a client central portal, which really ensures seamless communication while you work with Epiuse. Labs. And we all know throughout projects, as critical as these, that communication is everything. Finally, here at Group Elephant, we're backed by over forty two hundred consultants, and together, we've completed more than fifteen hundred SAP implementations worldwide. We proudly serve over two thousand of the world's largest corporations and public sector agencies, inclusive of seventy over seventy of the Fortune one hundred companies in the world. And while we are technology driven and love technology, we also never lose sight of our responsibility to the world. Through our one percent revenue commitment, we actively support conservation efforts for elephants, rhinos, and the people that coexist in those communities. We have a new spin on ERP. On the next slide, I'd like to introduce a little bit of a questionnaire or survey, early in our conversation. We'd really like to get a bit of a sense of where you are or your clients are on this journey to S4HANA. We'd like to know, are you really still running ECC, or are your clients still running ECC, not really planning to move, or are they really evaluating the greenfield, the brownfield, the STT approaches, and kinda have a bit of a path forward? Are you in the middle of execution, or are you actually finished? We'd love to know where you stand or where your clients stand. If you could please take a moment to vote. We see some of the numbers coming in. Not really surprising, to be honest. Still a lot of folks, steady state on ECC and pondering the future, and a couple are starting to chart a way forward. I don't think, Jamie, nothing much different than what we hear across the industry here. I think a lot of slow movement on getting to the s four HANA in the cloud. Yeah. It looks like what we expected, I think. Yep. No big surprises there. What we really want to talk about is the growing urgency around the transition. Right? So, obviously, there's the immediate driver is the end of May Street support for ECC in twenty seven. But further beyond that, ECC is really an aging, antiquated technology that was built for yesterday's business, completely a different business era. Today, the demands are agility, real time insights, digital integration, and continuing to invest in ECC is really becoming risky. Every dollar spent on enhancing ECC today should really be viewed with a critical lens. Will this investment deliver a return on an on a return on investment before the platform becomes obsolete? We really don't believe the runway is there. And the reality is that the longer you wait, the more you risk sinking more and more cost into a platform with a shrinking future. You have more mounting technical debt from outdated infrastructure, databases, middle tiers. Talent shortages are gonna become a bigger thing. Fewer professionals, know the ABAP and the platforms of twenty years ago, let alone your customizations. And then you're gonna have missed opportunities to leverage emerging innovations such as SAP DataSphere, embedded analytics, AI driven automation through Joel, and whatnot. Now is really the time to seriously consider modernizing your business foundation, not just to stay current, but to stay competitive. That's an important differentiator. Next, we wanna chat a little bit about the hidden costs of inaction. So we understand that transforming your core business system is a major undertaking, very disruptive, and may not be immediately aligned with your current business goals and priorities. However, it is important to look at both together because one can really support the other. The reality is there's a very high cost of standing still. Despite or sorry. Delaying your move to SAP HANA doesn't buy you time. It's actually deferring risk, inflating your future cost, and limiting your ability to innovate, and here's really why. Your technical debt continues to grow. Middleware, databases, unsupported infrastructure will all require increasingly expensive maintenance if you're even able to buy it at all in some cases, let alone having the resources to keep those antiquated technical components running. The talent scarcity is gonna intensify. As I talked about earlier, ECC professionals may be getting hard to find, but you can bet that the s four HANA talent is gonna be snapped up by the early movers, and, again, you'll be left behind. The customization really becomes a trap for you. As your business evolves, your integrations and your custom code deepening deepens your dependency on a platform that's nearing end of life. And I don't know that it's really where you wanna put your future. And then the innovations are left behind. So all things about DataSphere, Joule are not really you're not gonna get the value out of those being on ECC. In some cases, they're completely out of reach. So in a nutshell, the longer you wait, the more complex and costly your eventual migration becomes. And while you may feel safe standing still and just observing, your competitors are moving forward. They're gaining speed, agility, and insight. So the future is inevitable. It's not a question of if, it's when, but will you lead the change or be forced to catch up further down the road? If we flip to the next page, Jamie, let's get into a little bit of some of the migration paths. So, you know, we've heard a lot of talk about greenfield and brownfield, and we'd really like to zero in a bit more today on a third increasingly popular option, which is a selective data transition or SDT. So greenfield offers a fresh start, allows you to redesign your processes from the ground up, you're immediately closer to industry best practice, and you eliminate all your legacy baggage that, you know, was there for the right of the wrong reasons back in the day. However, it's a very costly endeavor. It's very time consuming and disruptive. The change management that comes with it is incredible because you're reengineer reengineering every single business process, which means all your procedures and ways of working have to get down to the individual contributors in your organization. They're all gonna be working differently to some degree. Brownfield, on the other hand, is more of a technical upgrade, if you will. It's faster. It's less disruptive, but it carries forward a lot of legacy issues, outdated customizations, a lot of unnecessary data, which drives your costs up, your go for your go forward environment. So this can really limit the business value of that transformation and make it really harder to justify that investment. The business case is not super good. It's more out of, you know, necessity than opportunity. So this brings us to our third option, which is the STT or the selective data transition. This approach, we believe, really offers a more balanced approach, allows you to migrate more on your terms at your pace. It enables you to retain key and valuable historical data while discarding what's no longer required or archiving it. We'll talk Jamie will talk a bit later about our archive central solution. You can preserve your key customization selectively and then modernize the rest and reduce the risk and disruption by phasing your transition. It's a strategic middle ground that really supports transformation without requiring a full reset, puts the customer in a little bit more control, if you will. With that, I'll hand it over to Jamie who is gonna talk a bit more about SDT and why it might be the right path forward for your organization. Jamie? Great. Thanks, Joey. Yeah. So selective data transition is, something that uses technology in a way we've been using it for a very, long time in the use labs to, use software to selectively migrate data between one application and another. In the s four HANA space, selected data transition is often also known as hybrid. There's several blocks of mix and match. There's a vendor that calls it Bluefield in the marketplace as well. And all of this is addressing the fact that a selected data transition does more than just move only what you need to reduce the cost of the platform you're moving to. It can also enable transformation by separating the setup technically of the system and the conversion to the s four hundred platform from the migration and conversion of data. And this enables you to also look at transforming your business in ways that bring big optimizations. And so we aren't talking about a business process change, although it's something you can also target precisely on ones that bring the most value in this kind of hybrid scenario, but can also be company code structure and financial reporting structure changes. So just sort of things that people would offer change in this space. We'll cover a few in further slides. And we use technology we originally built for test data in nineteen ninety seven and then took into the divestment space in two thousand and three to migrate data automatically from point to point, really using software rather than standard tools to ensure that people can take what data they want into the target environment, but also so they can transform and remap that data in flight So if they do wish to make configuration changes that can bring huge benefits to the business, they can do so. And that can be part of often setting up what is, often called an s one and a template, whether that's a global template for a multinational company or for another purpose. And so I often contend that it really is almost just as simple as taking more brownfield or greenfield approach to the conversion. It's really a question of business process and the code that runs those business processes you're talking about with the brownfield or greenfield approach from my point of view. Either, if you look at it that way, can be selective in the way of bringing data. People assume that for brownfield, it's in place conversion technically of the system, and therefore, there is no data migration. And that is true. You can take that approach. But you can also take an approach where brownfield conversion aims to utterly minimize business process change, and therefore, make it a faster and more cost effective project with less business interaction required. But you can still do that actually and take a selected data migration approach when you use a software technology because you can automate the movement and slice by company code or by year, or by other customized elements within that process. You can even do that and make simple changes to things like controlling areas or general ledger keys where there's a little bit of business interaction required, but not too much. And in the greenfield scenario, it is always a data migration that's required to move into a greenfield system. It is always a selective migration process as well in this case, but in both cases, we can use our Prism technology. And so we would say that Prism isn't separate, a separate approach to brownfield or greenfield. I would say to people rather that we would always, as a software specialist, look at selective options being natively and inherently included in any kind of migration approach to s four HANA. It is simply that in a more brand field conversion approach, you convert a shell of your existing system, and that's your baseline. And from there, we can automate point to point data migration for you. Whereas in a greenfield migration process, you're looking at a newly installed s one HANA system configured to be as vanilla as possible to your business. And in that case, you're going to load the data with a SAP Data Migration Cockpit, but you will still need a solution to populate that loading process with data selectively pulled from the source system, which is in itself quite a piece of work. So we provide software that helps in both of those types of migration, and therefore, we can use a prism approach whether you're taking a brownfield or greenfield system setup design architecture. And so we would say it's worth always being selective with your data unless the system is very small. And the way we present this, for those who go through our materials or website afterwards, is we use our Prism approach for these kinds of migrations in two modes. One, call Prism for business, and this is where we started with the technology we'll explain for selected data transition in the space of mergers and acquisitions, which is usually in the you're carving out a company code or merging a company code or maybe moving elements of company codes around like plants, and related pieces of master data, maybe posting and changing finances because of that need. And a lot of that mergers and acquisitions kinds of work, which we underpin with the same technology base, is relevant to many S4HANA projects. We would call an S4HANA project a Prism for Technology project. And in this space, we've been using our technology too to transition people to new platforms and new versions of SAP applications from s four HANA to payroll to SuccessFactors to DataSphere for many years now, including doing what wasn't called selective data transition at the time, but effectively data migrations directly to earlier versions of four point five and six c of SAP in earlier years. And the way we do this, we'll explain in the next slide, the way we use software to help enable this because data migration in either way can become a risk to the project, though it is also an enabler for a good TCO and ROI from that project. So many people call the hybrid approach mix and match. You'll see some slides where we do break it out from the greenfield and brownfield conversion. So we include both slides here today. It's valid to consider hybrid as a separate approach to a pure greenfield or pure brownfield approach. But if you go to the blogs that are out there, there's some very nice imagery that show that really it's kind of a rainbow from one end to the other. A hybrid approach can be very much in the greenfield mode or very much in the brownfield, brown shell mode where you're selectively taking data across. But either way, we would suggest that there is a great value in looking at your data in a lot of depth early on. And before you start the conversation with SAP and RISE about the sizing or if you're in that conversation already to consider what's possible from a specialist vendor to minimize the size of your production and nonproduction environments, which can be done with our both our Prism technologies and our DSM or cloud TDM test data migration solutions. And we'll come to Archive Central, which is mentioned on the top side. But effectively, as we're gonna talk about using software to split data and migrate it selectively, we can also stream data not migrated off into a industry standard file format or directly to our own archive central platform, which is hosted in the cloud, gives you transaction like access to your historical SAP data. So now I'm gonna run around the softwares that we use in our Prism solutions. And these are quite unique in the wealth of them that exist in the client base that uses them day to day in nonproduction environments and in the age. We're the oldest solutions provider in this space to SAP. As we said, the first version of data sync manager, which underpins with a landscape transformation license. These solutions was released in nineteen ninety seven originally in the HCM space and then expanded out to all other versions of SAP. We use a landscape transformation version of system builder from that data suite manager suite to build a new shell of your system. And this is how in an s four HANA project of, more the brown shell plus variety, how we get a copy of your system with no data. We then use DSMLT client sync to populate that with data sliced. Now this is a fantastic piece of technology, used at several thousand clients in the SAP world or I think about two thousand clients now maybe to be more accurate. And it's a way of automating a slicing of data across the entire SAP system. It's used broadly in the test data space as well as in transformation. I often tell our clients to test data space is far harder because you have no testing and a real need for a greater level of automation and accuracy. And it's a technology that's been rolled out, expanded, tested across every kind of SAP system from global trade and utilities and industry solutions to your CRMs and SRMs and VWs, and, of course, always in the core ECC and Sfour HANA environments. And we use this, to give you options for what data to take to S4HANA. The simplest three to boil them down being to take, time slice. You take always a fiscal year plus one or more so they have all your current data in there, and that simplifies the data migration process. You can take a company code slice with full history. That's probably the simplest way of taking data across. You can take custom selections within all of that, or you could take master data and open items, and it has a couple of extra complexities. The object sync solution then allows us to move objects around in groups and scenarios separate to the entire system slice, which gives us great flexibility for how we migrate a system and has an object extractor linked technology that lets us extract to file objects, which helps with the greenfield scenario for SAP s four HANA projects. Archive Central is a linked solution with its own subscription, but we use the same extraction engines that come from Data Sync Manager to populate, extract, and archive ready file. And like I said, this can go directly in our archive platform, or it can go into an XML CSV or text file format. We use our query manager and variance technology solutions then to query and report on data. Now this can be across HCM solutions, its original area, like SuccessFactors and Payroll, but can also be used and is compatible with S4HANA and ECC to provide things like reconciliation reporting on the finance or logistics areas. Whereas variance monitor is a pure payroll tool used for payroll variance. Our data transform engine is a in place transformation engine used for everything from logical separations for business transformations to transformations of test data for privacy. And in this scenario, we use it to remap data in place to allow transformations on data selectively moved to meet a new configuration of s four HANA. And that does mean if you do want to change your general ledger keys, change your controlling areas, maybe change documents within types or the currencies you have assigned to the company codes in the system, we cannot only enable you to make that change and power you to do it. We can remap the data that's imported to meet that configuration change. So you can still retain your history if you want to have it for that new configuration. And this is really quite a powerful, and unique offering. Data orchestration is a solution we've developed in our group through Epiuse Australia that allows us to also take the same kind of selected data migration approach to SuccessFactors data, something that can be tricky to automate the mapping to the configuration of SuccessFactors. So this has been developed to also allow us to handle that system as well as s four HANA and payroll. And finally, the LT posting engine. This is a finance posting engine so that if your move to s five HANA does include complex changes, so that to say you wish to, merge several company codes to represent one legal entity into a single company code, or maybe you want to merge two legal entities, in the process over a long s four HANA project, you're gonna then need to functionally post finances and move assets around and always stock inventory and other considerations. And this engine helps to automate that process. Between all these solutions, we have a way to address more green or more brownfields, s one HANA projects, and give you all the options you need for selective data and transformation in a way that is automated and derisked. So what might that look like? Just to briefly show you what kind of data we're addressing. Normally, we're looking at a shell built with repository and cross client configuration with clients, users, roles that could be selectively moved across as well. All client dependent customizing. This is something we would never slice, because it would put at risk the migration and the movement of data and does not generally take up a lot of space. It can be deleted afterwards as needed. And then the majority of your data sits in your master and transactional data, and that's where most slicing and selectivity of data will take place. In many cases, if a very complex system, is in place, you might want to also do archiving ahead of time, especially if you have archiving processes in place. But we don't have archiving in place. It may be possible to completely eradicate the need for even looking at that and rather take a selective approach to the migration and establish your archiving processes once you're on s four HANA. And the final question that often comes up with these kind of methods is, what about the outage to our business? How do you handle downtime minimization? Well, SAP in its own standard processes has something called near zero downtime, and we've developed something we use a different technology for them. So we don't use the same term as SAP. We call it optimized downtime. And the way we do this is by first creating a system that is technically integrated with this target network and infrastructure environment. So you have an s four HANA system stood up. Could be high availability tested. Your backup sort of technical level can be checked before we move the data, and this takes some time out of the go live weekend. We then use well established data splitting and copying technologies from the data sync management product, which is the hub of our two thousand plus clients that use our technologies now to move the data. Usually, in a single execution run, where it will be logically sliced and moved in a very efficient way. But on large systems, we can also split up execution runs by object types, and they can even be pre downtime copying, during downtime copying, post downtime copying if that's required. So, for example, items that can be easily split by chronology and have purely static data from earlier years that you do want to take, these could be run even after in the downtime as opposed downtime step. Now we'll go to just a couple of case studies before I hand back to Joey. So here's a couple of projects that I myself was involved in some way in the previous few years. This was one of our first s four HANA projects very early on, after s four HANA was released. It was a part of the Philips Group in the Netherlands, one of SAP's major clients in Europe, and they'd implemented or were implementing s four HANA, but had realized that they wanted to make quite a lot of changes. It was already a selective movement of data. There was only fifty company codes coming from about two hundred and fifty plus over into s four HANA. However, they realized there was a lot of inefficiencies in the way they set companies up from previous mergers and acquisitions and activities. And in this company example, we've sanitized the data effectively, the principles are the same. You had three companies at these fifty examples we had where each had a different controlling area, a different primary currency. You can see here two are US dollars, one's euros, and a different chart of accounts. Two of the companies have two currencies set up actively. The other just had pound sterling set up as a currency with no secondary currency. They wanted all of those companies to run on a single chart of accounts, a single controlling area, and with the same currency setup. One mixed, different currencies. The second always US dollars. So it's quite a lot of changes without actually merging legal entities or splitting them. A large amount of remapping of data to make the system a much more efficient setup. And we achieved this for this client in just under four months in the end. Many of these projects are much longer than that, but because the definition was so clear, the actual setup and automation of data migration process was relatively fast if complex. And with all as with all our solutions, by the time we got to go live, it was a automated improvement solution we could reexecute because it's baked into software. One more local to the North American market, the judicial council of California. Here, we not only provided our technologies and s four HANA experiences into running the s four HANA migration. We also took our experiences from our cloud business, to set up their Azure landscape and manage other systems in the migration process. M p s labs actually is part of a group with a wide number of SAP competencies that include certified SAP migration experts as your end AWS platform teams, private cloud team, and a large basis in tech ops team. So when it comes to SAP environments in the wider sense, this is a great example for the North American market of being able to handle a broader set of responsibilities in the migration space as well as offering the unique selling point of having our own software technology for SDT in the group. And final one is first group in the UK. This is one of the transportation businesses here, one of the major rail networks. Were moving to a greenfield in this case, instance of s four HANA. They already had a functional partner that often wouldn't be us that was doing the project, but they needed someone to help them with extracting data from their historical systems to populate loading process with SAP Data Migration Cockpit. So here, we used our technologies already used, at this company where we've done previous carve outs and nonproduction optimizations of their environments. We used our technologies further then to automate the process of providing data into the greenfield project. And so how would you engage us, if you're interested more in our technologies? And here, I'll hang hand over back to our man, in the time zone. Joey, do wanna take over from here? I'll Very good. Do you a slide when you're ready? Yep. Perfect. Thank you, Jamie, for sharing the capabilities that we have here at the p u s labs and how we really make these migrations a lot easier, with a lot more of a proven methodology that's repeatable and really auditable and reliable. So I hope that we were really able to pique your interest in that p u s labs today. As we wrap up our time together, we'd like to invite you to explore how you can engage with us a bit further. One of the things that we pride ourselves on is what we call the preflight assessment. The preflight assessment is really a lightweight application that we deploy on your ECC system or your client's ECC system via transport, and it generates a comprehensive report. You can see a snapshot here. But it really gives us a very detailed, structuring key characteristics of your environment. So the report's securely transmitted to our client central portal. At no point do we access your systems directly. We don't receive any confidential business, employer, or customer data. It's purely metadata insights that allows us to really get a good assessment of the scale, the complexity, or the simplicity of your environment. And then that, in turn, helps us determine the level of effort required for any potential engagement, including those with specific segmentation and customization needs, because not everybody is a pure lift and chip. The assessment is really a frictionless process. It's offered at no cost, no obligation, not a ton of paperwork and contracts. And the whole process typically runs within a day or two. We can get back to you pretty quickly with the results. I'll speak a bit here about how we work together as a team. So we have our proprietary kinetic methodology. That's really a derivative of the proven SAP Activate framework. It ensures that we really gather all the necessary insights to make your transition to s four HANA seamless, secure, and highly successful. The journey begins with the what we call the preflight phase. It's where we really conduct a rapid assessment of your environment. Again, allows us to generate a high level order of magnitude estimate and potential project scope. If we decide to go on together from there, we'd move into the prepare and the sharpen phases, and, you know, we're really doing blueprinting at that point, getting a bit, deeper on our understanding of your business, refining our estimates, and really laying out that detailed project plan that will guarantee success. Next, we move a bit more into the realization or the delivery phases, as we may call them, where we actually execute the migration, includes multiple rounds of testing to make sure that the integrity and the quality of the data is there in staging environments before we move it to the final targeted production. And we really make sure the data is business ready, you know, that in conjunction with any functional partners and certainly the client that we're doing the work for. We conduct a full blown dress rehearsal. SAP never exists on its own. It's always part of an ecosystem, so we gotta make sure that all the moving parts are ready to go and make sure that go live is very smooth. So once we go live, and as Jamie talked about, following a very brief planned outage, we provide hypercare to quickly resolve any issues that may come up just to make sure that things are all good and stable. But it's worth noting that because of our rigorous methodology and the experience that we have, that our goal lives are typically quite smooth and uneventful, thankfully. That's what we aim for. And this phased journey, really reduces risk, but also it builds confidence at every step. We're very deliberate on what we're doing, and we go down the road together. So to wrap up, I'll do just a really quick summary of, I think, what you've heard here today about, Prism technology, and it really simplifies and strengthens your journey to s four HANA. You can keep what works, leave the rest behind. Prism really helps you retain only the parts of your existing system continue to deliver value, and you can shed the rest. It really can help you preserve your differentiators. It's important not to throw everything away, where it makes sense because your customizations, that secret sauce that you've developed over the years, those things are critical to your competitive edge, and you wanna take those with you if you choose to do so. Prism makes that easy. We can easily lift and shift those elements to make sure that your future really builds on the strengths of your past. Smart data selection, our approach allows for surgical selection of only the most relevant business data and historical data. It ensures that your new Sfour environment in turn will be lean, business ready, and efficient, keeping the cost of your new environment, you know, to be optimized and not inflated. We optimize the lower environment, so again, with the cost efficiency because Prism can create a clean, cost effective snapshot of production data, subset of data. You can right size your lower environment, so again, you're not running that big unnecessary overhead. And then finally, we have a lot of data protection built in. Trust is everything today, whether it's your customer data, confidential business data, employee data. We have strong capabilities around scrambling, anonymization that you can certainly take advantage of. So with Prism, your migration is more than just a transition. It really enables transformation, which is changing your business processes for the better, and it's designed to be faster, safer, and more strategic. If we shift to the next page, Jamie, I just I really, hope that the brief conversation here, again, has sparked your interest in learning more about us here at FBUSlabs and how we really support your transformation journey, Not with an army of consultants, but with really cutting edge technology that does the heavy lifting, again, in a reliable and repeatable manner. So if you wanna know a bit more, there's a few different ways to reach out. We have the free transformation assessment that you can run through to get a tailored view of your landscape and opportunities as I talked about earlier. We have the cost savings calculator, which may give you a bit of a point of view of how much you could realize in savings on some of your environments. And then finally, we have the information sheets that gives you a bit more of a double click on some of the prism technology and methodologies that we employ here at labs. If you have any questions or would like to continue the conversation, please reach out to our team, connect with any of us who joined you here today on the webinar. We look forward really to helping you shape a smarter, faster path to s four HANA, not an easy journey. We really appreciate you joining us today. We really value your time. Thanks for listening. And I'll turn it back over to Sarah for any questions that we have from the audience. Thank you. Yeah. Thank you, Joey. Thanks, Jamie. We do have quite a few questions, so we'll take those. And if we run out of time, we can always reach out to you and get in touch afterwards. So first question, someone asked, what is the minimal downtime required in your experience? I would say the minimum downtime is probably something like twenty four hours, really. When you're considering that's not just technical downtime. I'm talking about afterwards testing the system, making sure it's okay, leaving time in there for a back out in case anything catastrophic goes wrong and you need to roll back. Really, I think that's twenty four hours that's needed. Most of these outages are running for anything from twenty four to forty eight hours. Okay. Another one for data migration. Will the exercise of mapping data still need to be done by the customer? And do your tools help to make this process faster? They help to make it a little bit faster. That report that you saw on the screen there will give actually quite a deep breakdown, including all the zed tables and all the tables in the system, all the customizations, the number of baddies, amount of code, the number of data elements that are customized in the system will all be there in our view as accounting history and a few more things as well. But it there is plenty of information still that needs to be looked at in the system depending on the dataset activity that you have. And depending how much transformation is needed depends on how much additional assessment is needed in the system. But, yeah, the software certainly helps to do that a bit faster. And when we turn up at a workshop, we turn up incredibly well informed. Thanks to those automated reports. Okay. Here's another one. How do clients compare their own customizations that have been developed over the years to the new processes developed by SAP? In other words, could custom code of older ECC systems be part of the standard s four code in SAP? Yeah. I mean, code assessment is something that we don't automate. We really stick to data. So we bring in help to look at the code and the simplification items reports that some provide. If you run the simplification reports, then that will actually show it in our automated assessment as well. If you have significant volumes of custom code that needs to be remediated for s four HANA, then we partner with companies like SmartShift that also focus on automation rather than bums on seats to go and get the work done. But where there is less number of customizations, we would simply bring our expertise into the room, and there's lots of nuances. If you're not on HANA yet, you need to do HANA optimization of the code. If you're on a HANA database already, we're moving to s four HANA. You need to look at compatibility of the code. And the number of functional areas you have live in SAP is something that also significantly affects that effort. Okay. Thanks, Jamie. Another one. How do you support business validation of data prior to moving into the new s four system that is normally the bottleneck? Prior to moving in. Yeah. It's a good question, actually. I mean, there's key parts of data that are always concerned before moving in. The standard CVI data, the customers and vendors integration, that always needs to be addressed. And although I've seen people promoting automation in there, the standard set process is fine. And there's a there's really a business conversation required a little bit there as well. It's not purely technical. Additionally, finance data quality tends to come up. If you have any lingering finance data quality issues, that can stop an s four migration from completing successfully. So we encourage clients to look at that data. We, labs, focus on being a technical software data transformation business. And so we work with our partners in our group or outside of it as the functional partners to work through business process designs. They might be using Celonis or Signavia or something to support data analysis. Our report will at least point them in the right direction. So if we see there are open items going back twenty years in the system, for example, we can point out where there are patterns in the data that should be looked at. Okay. We are out of time, but this hopefully is a quick question. Sort of off topic, but will q m three still operate in s four? I don't know if you know the answer to that, but we could get back to q m three. Q m three. I would say maybe no, but we'll have to read them. Some really good FEs, lambs, aficionados are on this call. Okay? I wonder if that's an internal question or actually, so I would assume not. One of our clients. Yep. I would assume not. A q m four has now been out for, I think, eight or nine years. I would say that I'm assuming you'd need to be on query manager four. Yeah. But I'm sure there's an account executive somewhere that can help you with that. Yeah. We'll reach out to you separately on that. But Yep. That's it. We're over time. I wanted to thank everyone for coming. Thank you to our speakers. And we'll be sharing the recording as well as the link to that transformation assessment and an information sheet so you can, you know, reach out with any questions. And then we're gonna have another webinar in September introducing the SAP Business Transformation Center and how Prism and Business Transformation Center work together on these, selective data transition projects. And, yeah, thanks again. I hope to see you on September tenth, and we appreciate it. Thanks, everyone. Yeah. Thanks, everybody, for joining. We appreciate it indeed.