Hello everyone, and thank you for joining today's fireside chat. We are really excited to take you behind the scenes of two highly complex SAP carve-out that we recently delivered for one of our customers. My name is Ibrahim Kanalici, and I serve as Solutions Lead for M&A here at SNP in the Northern Europe, Middle East, and Africa region. In my role, I have shaped how our portfolio supports customers and partners across industries, guiding them through the complexities of data in mergers, acquisitions, and carve-out. I'll be your moderator for today's session. I'm joined on the stage by two fantastic guests: SNP's Project Manager on these projects, Matthias Wienerroither, and Sajith Sasidharan, Managing Partner at Tata Consultancy Services, who also played a leading role in this journey. Together in this session, we'll explore the challenges, rises, and lessons learned from two highly complex carve-out and how a collaborative transformation approach helped us reduce the risk, minimize disruption, and accelerate results. A bit of housekeeping before we dive in. In today's session, we'll run about 45 minutes, and obviously, we'd like to hear from you. Please pop your questions on the right-hand side into the Q&A box. I'll bring those to Matthias and Sajid at the end of the session. Don't worry, the session is recorded, so you'll receive a link afterwards as well. Without further ado, I will hand over to our guests for a short introduction about themselves. Matthias, could you please kick things off with a quick introduction? Yes, thanks a lot, Ibrahim. We have to start. My name is Matthias, as already presented by Ibrahim. I joined SNP five years ago, and I'm a Project Manager at SNP. In the past years, I've done several projects in the area of mergers, acquisitions, and of course, lately, a lot of S4 projects. I was the Project Leader in those two projects where we will have a back-to-back session now, and therefore, I will hand over to Sajid to introduce himself. Thank you, Matthias. Sajith Sasidharan is my name, and I have over 23 years of experience and 17 years with TCS, and I'm based out of Helsinki, Finland. I look after customer engagement based out of Finland and also part of TCS SAP Global Practice. Thank you for having me here, Ibrahim. Nice to be part of this fireside chat with SNP. Amazing, and thank you both as well for taking the time out of your busy schedules to be here on the stage with me. Let's jump right in. Sajid, can you start us off by describing the projects a little bit and the business context that set the stage for these carve-out, please? All right, so when looking at this context, the customer situation that Tata Consultancy Services has partnered with SNP Schneider-Neureither & Partner SE in the recently concluded two back-to-back carve-out that we did, and this is a Finland-based global customer wherein which they had three distinct business units under one umbrella. Sometime in spring 2023, the owners of the board have decided to split these three companies. That means one of the companies will be divested because the rationale behind this is the company wanted to focus on the core businesses. One of the business units will be divested, and the other two will become standalone stock-listed companies. We are talking about a remerger and a divestiture scenario. The first one, what we started, and by the way, these companies operate globally, more than 50 countries, and at least from an SAP perspective, more than 40 countries and multiple legal entities within those countries are in scope. It was an aggressive timeline that was set from a deal perspective. First, we started with the demerger project to stocklist the first company, and it was a 10-month period. Subsequently, when we successfully delivered that project, we went on to do the next project, which is an IP separation of the second company. Also, it's only not from an SAP carve-out perspective. There were requirements from a transaction perspective in terms of logical separation. That means, you know, legally splitting these companies in order to, from a listing pre-principles. There are multiple dimensions to it. A very challenging project, not only in terms of the global scale, but also in terms of the complexity of multiple upstream, downstream systems connected and impact to the remaining company, and so on and so forth. Also on top of it, the pressure coming from the deal timelines itself, right? Making it super complex, super challenging, also very rewarding when we successfully deliver it. Yeah, thanks for those insights, Sajid. I concur that deals are always going at high speed, high pace, and that's one of the challenges, isn't it? There's a lot of dependencies across the board when you're looking to separate the IT landscape as well. Thanks for setting that sort of context and the carve-out and also just talked about the triggering and what triggered the carve-out, et cetera, and the scope as well. How did you define success for this project at the start? All right, see, IT carve-out are not only technical projects. These are business transformations. There is an underlying objective of this, the trigger to the carve-out itself, right? In that context, from the beginning, we knew that this is not only going to be a technical separation. I would classify success factors for these types of carve-out into three. First and foremost, the North Star would be the business continuity. Whatever IP separation happens, the business users continue their operations. One particular after the weekend when that separation happens, right? By the way, the cases that we are talking about today, it's more of a big bang go live. Globally, it's a big bang kind of a carve-out situation. Over a weekend, switch on to the new entire IT landscape, right? The business continuity is the first and foremost success factors. I mean, that would be the criteria, right? The second would be the data integrity, the quality of data to enable the business to operate as usual, but also from a financial reconciliation point of view, both in terms of form from a P&L and also from audit and compliance purposes. The data integrity is at most one of the key success criteria, I would say. The third itself, as I mentioned, the objective of the separation itself, how we as technical specialists, system integrators can ensure the objective of the separation is met. That means faster PSA exit so that the separated company can be standalone and look forward to their own future. I would classify these three as the key success criteria for these types of carve-out. Amazing, Sajid, thank you. As we all know, the separations are ever, you know, with the pace at which it goes and lots of dependencies and the number of, let's say, the entities involved, et cetera, there's always going to be a tight timeline to meet the TSA timeline, but also ensuring the data integrity and the compliance with the governance, the rules, and the frameworks is quite important. Thanks for kind of highlighting those. It's amazing. Thank you. Matthias, over to you. Let's talk a little bit about what were the biggest technical hurdles. If you talk about maybe a little bit more about the architecture, you know, going into a little bit of the technical side of things, what was the architecture at the start and what was the architecture at, you know, following the carve-out? How did SNP's software and TCS's transformation methodology help addressing some of the challenges in respect to the technical approach itself? Yes, of course, Ibrahim. We at SNP and also the partners and customers have a big advantage because we are using our SNP CrystalBridge software, and that's basically an easy way to carve out data or move data between systems, between system landscapes. We bring a lot of flexibility to certain carve-out. For example, when it comes to finding a go live date, with our approach, we can take basically every day in the year. We are not dependent on a month-end closing, and we're aiming in the whole project to make it happen on a go live weekend. Like Sajid before said, going with the big bang, one go live, and that's it. Everyone can work on the next day. That's one big topic. The other topic is when it comes to selecting data with our software, we can slice however we want to have the data. I would say luckily in this perspective, we had a clean slicing of company codes and bringing them over to the target with full history. Of course, there are also other examples where we need to slice with profits and plans and leave data behind. That's a story for another time. That's really a big advantage to get this data integrity right to start with the right basis. That's some cool features that I like as a Project Manager and also that the customers and partners love when doing such migrations with SNP. Yeah, I wanted to add a couple of points on what Matthias said. When we had this customer requirement, we needed a tooling specialist, right? Just to add there, when we collaborated, partnered with SNP on this, there are multiple ways that we can do the carve-out, right? One is like in this case, what we adopted is a selective data migration, and the other approach is clone and delete. Clone the whole set of data into the target system and delete it. We had quite a good deliberation and evaluation for this particular customer situation, which would be the right best option because there was a sizable amount of data in the source system. Like also Matthias said, we need to do certain massaging data transformation and quite a lot of aspects there. What Matthias and SNP team was able to analyze and give the right approach, then the whole architectural design itself for this, you know, temporary systems, you know, and all of it and create the whole landscape for the carve-out that was done. That was quite impressive. Amazing, Sajid, and thanks for adding that on because obviously the software and the approach to help with these carve-out and divestments do amazing things in order to achieve that technical separation. There are often many variations in these approaches depending on the deal itself, what's the level of the data entanglement in the source system, how do we carve that out, and also what are the sensitivities of that data that needs to be validated before and after it's been shared as well. There are a number of factors that need to be considered, and I think in these sort of approaches, we, as you said, Matthias and the team did an amazing job in identifying what are the key criteria in which the approach needs to be adapted to and taking that to the customer situation. Great to hear. Was there any integration, unexpected challenges, or data challenges at all as we sort of approached these carve-out in the way that we did? Was there any key or highlights that we took away from that we had to address as part of our approach to the carve-out? Matthias, that's all. Let me quickly add to this topic of data integrity. With the approach that we are doing in the projects and that really perfectly fitted with the TCS methodology to run this project, it's more like waterfall, but inside the phases, we were pretty agile with doing corrections after a test migration during the test phase and making therefore sure that we are already heading into the next test phase with an even better basis. You can't jump too many steps in phases. You need to do the project one step by another. What we always do at SNP, we're migrating since the first test migration with the full data set. This will help for data integrity, definitely, because you're not postponing to migrate the last 500,000 transactions at the next round and next round. No, we need to go full. This is a hidden champion, I would say, also in terms of data quality. You will always find topics where you have some challenges with data integrity. One very small detail would be like if you are moving employees and you're migrating the master data of them. One employee already left the company, is not active anymore, and you don't bring them over to the target system. You need to see if there are certain processes where this data is still used and you need to further process the data. These topics always come up because at every deal, there are certain specifics or certain discussions between partner and customer where you then find solutions to bring over also inactive employees or bring over someone who was one time in their history in these companies where they were carved out, but they're still in another company now. That's some challenges that we always see. Maybe also some kinds of mixed documents if there are inter-company business done between a company code that is still in the old system that will be staying, that will not be carved out, but it has some business done with a company code that will be carved out. You always will find out in the first test migration or in the test migrations. Although you want to analyze and design everything upfront, the real truth then comes when doing a data migration and going into a very well-organized test phase. Yeah, if I want to add a couple of points on that, Matthias, well said. The most important aspect is doing, I mean, how do we mitigate the risk, right? We talked about data integrity. That is to do multiple data iterations. In this customer case, we have had at least four full runs of migrations. Exactly the full load, right? We call it test migration 0, 1, 2, and we did a go live simulation, right? Iteratively, we improved. What we have also done in a way is to couple SNP's data migration test migration round with, let's say, unit testing, integration testing, and UAT. Once we do the full set of migration, then we did the integration testing, for example. In this particular customer case, it is not only the SAP, you know, got separated. We're talking about 15, 16 applications getting carved out on one particular weekend. The integration testing, and we have temporary landscapes for all those connected applications, and also the applications which are already separated, you know. The integration testing, how the data flow between the systems, we were able to validate together with the test migration rounds. In that way, that was best practices that we take it from our previous engagements, and we are able to successfully deploy in this customer case as well. Amazing, amazing. I think it's important to just recap some of the good points made there. One is design happens at the start in terms of what needs to be separated, but the test migrations are ever so important to highlight any key challenges or dependencies in the case of a data entanglement across company codes. Maybe one company code is in the data privilege and the other is not. How do we handle those inter-company type challenges? Also, the applications, it's not SAP only, but other applications in the landscape that need to be separated. How do they come into the picture across the separation timeline itself and test it against the approach and the migration across the whole landscape, not just SAP? Those are really important points. I'm glad you guys kind of touched upon those, so thank you. Moving on to a little bit about collaboration and the delivery itself. How did Tata Consultancy Services and SNP work together, Sajid? I think I'll put this question to you to start with. Can you give us a little bit of insight into what made that partnership work? Yeah, I would say their trust and openness. When we started the project, of course, TCS and SNP had a long-standing relationship and multiple assignments, multiple engagements globally TCS was doing. At least from me, it was the first time working with SNP. We have had initial challenges, you know, but that is quite natural when two different parties are coming together and the customer also, you know, because there is, as I said, a lot of time pressure and also anxiety from the customer as well because carve-out they are doing for the first time. Any customer, at least this customer case, they have done multiple transformation projects, global implementations of ERP and so on and so forth. Carve-out at this scale is the first time, you know. With that, we had initial challenges, but we were quickly able to overcome that. We had a very strong governance setup between TCS and SNP and also a tripartite governance with the customer as well. We were able to flag the risk early and make tough decisions, yeah, and then able to move on. All in all, the underlying objective for everyone that we had is this, you know, we need to meet the timeline and we ensure there is a, you know, the business continuity of the, you know, the business should not be disrupted. With that, all three parties, customer, TCS, and SNP, and TCS and SNP joining hands for the customer engagement. That collaboration and a strong governance, right? That was key to success is what I feel. Quite importantly, when we finished the first project, the second project came natural to us, you know, quite a lot of seamless collaboration, even strengthened further. Even from the customer side, because the customer has got a confidence that one project was successful, massive, big bang project, which helped without any major issues there. It further strengthened how our relationship has built and how we are able to successfully deliver. Nevertheless, every carve-out teaches us a lesson, right? It is unique and the customer situation is unique. How we as a partner are holding hands for the good times and bad times, that really makes a difference. Very good. Anything to add to that, Matthias, at all? Yes, first projects are always the hardest ones. Did you know the storming, norming, performing phases from the team building? Once you have passed this one project, it was really so easy, I would say, to do it because you know already what the other guy expects from you and there is really a good partnership. That was hard-earned in the first project because of all the challenges that we have. It was really, really rewarding because we not only looked at this topic of the data integrity, but we always looked at business continuity. In each of the test cycles, when it was closed before the next test migration round started, everyone together had a look at the topic performance. If you do this all the time, then it's coming to a common goal. The guys were looking for parameters, for finding out can we size up the CPUs a little bit more, what would it cost, what parameters should be set, how to make some command in the database to even improve it. It felt like play, and especially in the second project. Amazing. Okay, Matthias, it wasn't only about refining the scope and validating the scope throughout those test migrations, but also refining the performance to meet the required performance parameters or expectations of the carve-out and the customer itself as you go through those test migrations. Thanks for highlighting that as well, right? Correct. It was at the beginning, of course, you run a test migration zero in the first project where you just have to find the scope. All of a sudden, you end up with a runtime of 100+ hours. Everyone is looking to you, how will you be able to manage this on a weekend? In the performance reviews, you could clearly show them from each cycle to each cycle that the runtime decreased and everyone helped each other out to get a stronger system on the basis side to performing better on the data migration rule side. Amazing. Okay, good governance, well-defined communication channels, and decision-making approach and ways of working. I think that was underpinning that sort of great partnership that allowed the customers to realize the full benefit of both the technology, but also the methodology as well. Great things to hear. Let's move on a little bit into lessons learned. I think our audience will be quite excited about understanding what some of the lessons are, what went well, what wasn't. What advice would you give to someone starting a carve-out, for example? Matthias, let's start with yourself first. What would be the key advice to give someone who is contemplating a carve-out that's coming up? Yeah, think about, first of all, that would be like the first question also when we go into workshops: what is the highest level scope that you currently think of when you are running this carve-out? Is it on company code level or is it below company code level? Out of this question, already next follow-up topics will come. The first and most important thing is how to slice the data and what is in the deal when it comes to how much history is someone willing to carve out or is the other party willing to pay for that. That's the number one topic for me, the high-level selection scope. Amazing. Sajid, what about yourself? What went well from your perspective? Is there anything that you, in hindsight, would you do differently? Okay, I'll check this, like your previous question to Matthias as well. What if someone wants to start a carve-out, what are the things to be focused on? Retrospectively, having done two back-to-back carve-out over an 18-month, two-year period, three things. First one is to have a strong governance mechanism. If you're on the customer side, for the audience in this chat here, if you're on the customer side, establishing a strong separation management office, that constitutes, I mean, talking only from an IT perspective now, IT separation point of view. The SMO and driving the IT initiative, because there could be multiple suppliers involved, SAP, system integrator, tooling partners, and so on and so forth. When we say a carve-out, it's not only SAP, right? Creating a standalone enterprise IT environment, right from networks to data centers and application getting separated, end-user services and devices and the processes, so the enterprise-wide impact. SAP normally, it's one of the complex applications to carve out, as we know. Establishing a strong governance to manage the dependencies, right? This is quite important. The dependencies of upstream, downstream systems, if multiple systems are getting carved out at the same time, how the plans are aligned, if there is a deviation, how to communicate and how to, you know, course-correct and adjust what are the impact and the dependencies. The communication part, the governance with all these stakeholders, including the business, you know, because business should be aware of what is the downtime, what to expect, what is the impact to them, how they should be prepared. That is the first element. The second aspect would be, like we said, over-invest in data. That is important. Clear, you know, over-invest in data quality, do multiple iterations and validation rounds. We may often need business to come and validate. In a carve-out scenario, if you look at it from a business point of view, in a like-to-like carve-out scenario, business is not getting anything, you know, in that sense, you know, and we have to engage globally business users to come and test our integration test, validate. Often, often those have been challenges, but if you are able to manage that, that drives the success, right? The cutover itself, right, and plan for contingencies. That is what I would say that, yes, this is retrospectively speaking, plan A, plan B, what if something delays, how that is going to impact. Prepare for the next, you know, unexpected. Having contingency plans would certainly help. One thing I wanted to call out, in this project, in this particular case, what we realized from a customer point of view, as well as Tata Consultancy Services and SNP Schneider-Neureither & Partner SE as well, is when we are doing this preparation, we started the cutover planning much earlier. We are creating this cutover runbook, creating and sequencing, orchestrating, and doing the planning. We realized the remaining company impact very late in the project. We were planning for the separating company, how we would manage, but what would be the impact to the remaining company, right? When there is a shutdown of the system, it is a shutdown for the separating company as well as the, you know, the company that is remaining here. In this case, when we shut down SAP, the remaining core had impact to shut down their sales systems, e-commerce platforms, how to communicate to the business, their end users, their suppliers, all of that we realized a bit late in the project, but we were able to manage it and then put it on SOS basis. How do we also ensure those elements have been taken care? That is one thing I recall as a major topic. Other topics, such as especially on the data Matthias pointed out, when the test migration, the first test migration we did, it was 100+ hours. The cutover weekend was planned to be over a weekend and a lot of anxieties, a lot of questions. From the performance tuning perspective, overall, just bringing that in the first project, first round, it was first round to the actual go live, the improvement was more than 100% in terms of the clock times from a data migration. How do you learn from this? There are opportunities to improve. How do you make it better, better every round technically, as well as from a process point of view, that would really help. That's some amazing insights there, Sajid. Thank you. Just to recap in terms of some of the important things I heard, it's, you know, IT separation isn't just about the application. SAP is obviously quite an important one. A large application is typically a backbone of many operations, but also there's a lot to do, and it often defines what's the success of the carve-out project as well. It needs to be cognizant of that. Getting business involved early on to make sure that they're involved, not just validations, but also what's happening in terms of the remaining core, i.e., in the cutover, for example, with the downtime that's expected for the remainder of the business, not just the target carve-out. I think it's important to communicate that early, as well as kind of overall communication to make sure that the business kind of joins that journey, which is very important. Also, to the last point, in terms of making sure that there's a good governance across the project, the test migration cycles are managed well and learnings are taken into the next test migration cycle, etc. It's all great points. Thank you very much for highlighting those. At this stage, I would like to thank you both for introducing those learnings and key insights from those projects. Amazing. Thank you very much. Let me switch to some of the questions that the audience has posted as we talked along the way. I'll pick one up from my Q&A prompt. There's a question around, was the company called carve-out a firm decision from the start, or was there some debate about time slice as well as company code? Matthias, would you like to address that question? Was the company called carve-out a firm decision from the start, or was there some debate about time slice as well as company code? From a time slice perspective, we had always the overall approach to take full history. When it comes to the company code, I remember, yes, there were some discussions in the design phase when then also the experts from the customer were involved. What data, what company codes are really the ones to take over, that was fixed during the design phase. Luckily, there were no real changes in the project itself. Maybe I give it off to Sajid as he was way earlier in the project when those discussions took place, maybe about which company code to take or not to take. Yeah, true, true. Like I said in the beginning, when the demerger or the partial demerger was announced, and it was the first company was the target distributed stock-listed. That means completely decoupled from the current system because for audience information, it's a single instance global production system where these three companies were operating in at least eight to 10, I don't recall it now, but at least 10 countries. The legal entities of the separating company and the remaining code were operating in one single legal entity, right? That is the pre, you know, the project before the physical carve-out, we did the logical separation. TCS engaged with the customer, we separated the company code. Legally, we splitted it because that was also mandated for the stock listing. When we started the physical carve-out, we could clearly identify which companies, company codes that will go into the target system. We were able to do that. In, again, the question of time slicing and all, because the separating company needed full history of data because that is very important for them. They entered the full history of data for those company codes. We migrated all. As we speak, after finishing two carve-out, now we are engaged, TCS and SNP is engaged with the customer to do a deletion project in the source system, right? After two carve-out are completed, now the main code has the data of the two separated companies. We are engaged in a deletion project. That is ongoing. Meanwhile, as you know, when this separation happened on those transaction dates, all those data have been ring-fenced already. The remaining code cannot access the separated company data. The ring-fencing with authorization control and all have been done. Okay, very good. I think you touched upon a couple of things, which I want to highlight again. The data primitive itself and the scope of data that needs to be separated, and whether it's time slice or full history, et cetera, would it be fair to say that it's also often governed by the type of the deal and also the agreement between the seller and buyer, right? Yeah, yeah. Okay, very good. Very good. Next question up on my screen. In your carve-out migration projects, what were the key levers? If you had to do it again, what would you do differently to accelerate value or reduce risk? I guess in a way, this is another sort of way of asking, was there kind of a couple of very successful projects, the subsequent one obviously taking any lessons learned from the first one in order to make things even more smooth. Was there anything that you have in your heads, kind of in hindsight, anything to do differently to accelerate the value or increase the value or reduce risk at all? Sajid, why don't we start with you in this one? Yeah, I mean, we touched upon certain elements to this question in our previous comments. A good example, like what we had taken, since we had done two back-to-back major global carve-out in a short period of time, the first project had challenges. That is what is naturally expected in these kinds of projects. The net result was successful, not even a single major incident, not even a single minute lost in terms of business hours lost after the go-live. Like I said, how we improve the data migration runtime, how do we do the dependencies management, not only with SAP, with all the downstream systems and integrations, and how do we better communicate with the business stakeholders? How do we make them informed what to expect and how they should be prepared? Those we learned in a hard way. I would say that because there were a lot of questions, a lot of ambiguity, uncertainties, and also on top of it, the timeline itself, right? Timeline cannot be changed. Basically, you're chasing the dates, right? In the second project, we were able to take those learnings and adopt it, make it even better. The second project took us three-fourths of the time to do exactly some similar scale and size of complexity of the project. Quite a lot of learnings, lessons learned in a positive way that we could use it. Not only in this relationship, but TCS and SNP, we are taking it in our other end customer engagements as we speak throughout in Europe and globally. Very good. Matthias, on your side, is there anything else that you want to touch upon at all? I know we covered some of these already in the discussion, but is there anything that you want to sort of double down on? Now's the time. Sorry, losing my voice. I give you an extra question to Sajid. Okay, let's move on then. I think Sajid already covered quite a lot of points there as well anyway. There's a question which is around, were there any specific requirements from audit, either internal or external, on data validation? In our dealings with the customer in both of those carve-out, were there any specific requirements we came across, not just from the transaction, the deal itself, but also from the audit perspective? Okay, like I mentioned, there are certain obligations, guidelines, guidances on the transaction itself, right? What type of deal is it? Who is obliged to comply with the audit and who the data ownership stays with, who put it in simple terms, right? That always exists. The retention period and all of that. What in this project, what we wanted to, or what was the objective was to see that the financial data is matching. It is that it took to the last cent, right? You know, the financial numbers should match fully reconciled. That was the requirement. That was validated from the customer side, customer finance team, and all of it when we do the final round of testing as well as up to the go live. Of course, external data audit happened post-project, after go live, after a certain period of time through an external auditor just to ensure all things are in place. During the project, we did not have a kind of audit requirement other than we had to ensure that data is fully, fully synced from the source system to the target system and the finance numbers are matching. That was the challenge, I mean, in any carve-out that we had to see and plan it. It's a typical data validation, reconciliation. Yeah, interest. Yeah, sure. Okay, okay, very good. I'm conscious of time as well, but I would like to cover a couple more questions, if you may. A couple more there as well. How was the historical data planned for the target company? Partial or in full? What about the archived data? I suppose in this case, we had historical data in full anyway, but was there any archived data? I suppose, you know, that's the gist of that question. Was there any challenge with that in the database size? Were there any challenges with that? Also, three key learnings and checks companies should always consider in their carve-out plan to contain unforeseen risks. I think we touched upon some of those as well. It's a big question. I'm just trying to compact that and fallback plan if things are not going as planned, if things experience errors in past execution. To summarize, I think, you know, was there any archived data? Was there any sort of challenges around archived data? Was there any challenges around the database size at all? I think we talked about key learnings already. Was there any fallback plan at all based on those, sort of, the learnings we got from the two projects? Matthias, are you back with us? Would you like to look at archived data in the database? Yeah, archived data. We also had archived data in the scope. There we also could find a nice solution to select all the archived documents, so invoices, for example, that were related to any transactional data, to also bring the ones where we already moved the SAP data. We also brought over the archived data. That was working nicely, I would say. Yeah, was also in scope. Okay, so archived data was in scope and that was part of the carve-out as well. That's good. Was there anything about database size at all in terms of challenges? Because, you know, regardless of the type of the carve-out, et cetera, when we carve out a large amount of data from a large database as well, there's always an impact on the downtime, isn't there? Yeah, I mean, databases always have their specifics. As we're doing table-based migration directly over the database, we favor some databases. This time we had one that was a little bit challenging, a little bit tricky. You need to find the right parameters, be it to be very technical. What is the file size to export the file to the file share to have the best performance than putting it into the target database? That's something, or like deactivate the archive logging. We don't want to have archive logs written during the data migration because there won't be any point-in-time recovery anyway because we're doing the data migration and we can, very often, fix all of these issues. Databases, the sizing, yeah, was a couple of terabytes. Of course, there you have also the challenge when selecting the data. The bigger it is, the more resource-heavy those selection criteria and attempts are to the system and also to the runtime. Yeah, that would be my two cents. Same on the question on the fallback plan, right? The fallback plan is part of your cutover plan. The cutover plan should provision a fallback. What triggers the fallback? What are the decision criteria? What are the decisions, what can influence the fallback? Who takes the decision? At what point in the cutover window, in a calendar clock time, when this should be evaluated? Most of the key aspect is when we plan this carve-out, let's say if you take an example, 48 hours is the downtime, right? That's the window that we got, right? From shutting down the system, initiating migration, finishing migration, validating it, smoke testing it, and switching on the integration. That's a positive scenario, right? We should provision for fallback. How much time a fallback takes? What we need to get back, things everything back in place so that business is not affected or the downtime is not increased. A fallback plan is part of the cutover plan. You need to provision the time within that accordingly and plan your downtime for it. Thank you, Sajid, for catching that question there. I think it's important and highlighting that the fallback has to be part of that consideration of the cutover plan anyway, in any case. It's a great, great shout out there. Thank you. Just one last question, conscious of time as well, gentlemen. What do companies do in the source system, in the old system, after they've carved out the data and there are still active companies in the system? I think this is more to do with the companies carving out data. In this case, obviously, the parent company is still operating. Therefore, obviously, the system is operational. What about the data that belongs to that target entity, the Supreme Court entity? What happens in the source system? Was there any question about that in the carve-out that we delivered? You know, like I said, after the transaction date, we have ring-fenced the data in the source system. The remaining company cannot or will not access or cannot access except a few authorized users for financial audits or some sort of things because that's a liability of the remaining code because based on the deal. Very few people have access and only in the financial data just to comply with statutory obligations. It's all fully ring-fenced. Like I said, now Tata Consultancy Services and SNP Schneider-Neureither & Partner SE is engaged in a project to delete the data from the source system, the data which have been separated for these two companies. We are engaging in deleting those so that we delete that. Yes, of course, there are enough backups and all, but we are deleting from the main database. That was an aspect of post-carve-out data deletion of that data in the source system. Yeah, correct. Okay, very good. That's a possibility as well, which is important for the audience to understand and know as well. It's not just carving out a system, but also being able to delete, account to delete that data in the source. Great. Gentlemen, thank you very much for your invaluable insights and your time. Again, audience, thank you again for your time as well for joining us in this fireside chat. Just a reminder, you'll receive a link to the recording as access to, and as well as access to our latest white paper on the SAP carve-out as well. It's a very good read. I will encourage. Thank you very much for your time today. Hopefully, you found this as insightful as I have and enjoyed it as I have. Have a great rest of the day. Thank you. Thank you. Thank you.