SNP Schneider-Neureither & Partner SE (SHF.F) Earnings Call Transcript & Summary

Hello, everyone. And thank you for joining today's fireside chat. We are really excited to take you behind the seeds of 2 highly complex SAP carve-outs 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 and 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 and mergers, acquisitions and carve-outs. I'll be your moderator for today's session. I'm joined on the stage by 2 fantastic guests. SNP's project manager on these projects, Matthias Wienerroither and Sajith Sasidaran, Managing partner at TCS, who also play a leading role in this journey. Together in the session, we'll explore the challenges, surprises and the lessons learned from 2 highly complex carveouts and have 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 will run about 4 to 5 minutes. And obviously, we'd love to hear from you. So please pop your questions on the right-hand side into the Q&A box. I'll bring those to Matthias and Sajith at the end of the session. And don't worry. The session is recorded, so we'll receive a link afterwards as well. So 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. So we have to start. My name is Matthias as already presented by Ibrahim. I joined SNP 5 years ago and I am a project manager at SNP. So in the past years, I have done several projects in the area of mergers, acquisitions and of course, lately, a lot of S/4 projects. So I was the project leader in those 2 projects, where we will have a back-to-back session now. And therefore, I will hand over to Sajith 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. Yes. Thanks for having me here, Ibrahim. Nice to be part of this fireside chat.

Amazing and thank you both as well for taking the time out of your busy schedules to be here on the stage with me. So let's jump right in. Sajith, can you start us off by describing the projects a little bit on the business context that set the stage for these carve-outs, please?

All right. So when looking at this context, the customer situation that TCS have partnered with SNP in the recently concluded 2 back-to-back carve-outs that we did. And this is a Finland-based global customer, where in which they had 3 distinct business units under 1 umbrella. Sometime spring 2023, the owners of the Board has decided to split these 3 companies. That means one of the company will be divested because the rationale behind this, the company wanted to focus on the core businesses. So one of the business unit will be divested and the other 2 will become stand-alone stock-listed companies. So we are talking about our demerger and the 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. So it was an aggressive time line that was set from a deal perspective. So first, we started with the demerger project to stock list the first company, and it was a 10-month period and then subsequently when we have successfully delivered that project, then we went out to do the next project, which is an IT separation of the second company. And 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 legally splitting these companies in order to -- from our listing pre [indiscernible]. So there are multiple dimensions to it. So a very challenging project, not only in terms of the global scale, but also in terms of the complexity of multiple the upstream, downstream systems connected and impact to the remaining company and so on and so forth. And also on top of it, the pressure coming from the deal time lines itself, right? So making it super complex, super challenging, also very rewarding when we successfully deliver it.

Yes. Thanks for those insights, Sajith, and I concur that deals are always going at high speed, high pace, and that's one of the challenges, isn't it? And also there's a lot of dependencies across the board when you're looking to separate the IT landscape as well. So thanks for setting that sort of context and the carve-outs and also just talked about the triggering and what triggered the carve-outs, et cetera, and scope as well. How did you define success for this project at the start?

All right. See, IT carve-outs are not only technical projects. These are business transformations -- there is the underlying objective of this -- the trigger to the carve-out itself, right. So in that context, from the beginning, we knew that this is not only going to be a technical separation. So I would classify success factors for these type of carve-outs into 3. First and foremost, the NorthStar would be the business continuity. Whatever IT separation happens, the business users continue their operations. On particular after the weekend when that separation that 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? And the business continuity is the first and foremost success factors. I mean the criteria, right? The second would be the data integrity, the quality of data from -- to enable the business to operate as usual, but also from financial reconciliation point of view, both in terms of -- from a P&L and also from audit and complex purposes. So the data integrity is at most -- 1 of the key success criteria, I would say. And the third itself, the -- as I mentioned, the objective of the separation itself, how we as technical specialist system integrators can ensure the objective of the separation made that means faster [ TSA ] exit so that the separated company can be stand-alone and look forward to their own future. So I would classify these 3 as the key success criteria for these type of projects.

Amazing, Sajith. As we all know, yes, so the separations are ever with the pace at which it goes and lots of dependencies and the number of, let's say, the entities involved et cetera, is always going to be a tight time line to meet the TSA time line, but also with the ensuring the data integrity and the compliance with the governance, the rules and the frameworks is quite important. So thanks for kind of highlighting those is amazing. Thank you. And Matthias over to you. So let's talk a little bit about what were the biggest technical hurdles. So if you talk about maybe a little bit more about the architecture going into a little bit of the technical side of things, what was the architecture at the start and what was architecture following the carveouts? How did SNP software and TCS' transformation methodology helped addressing some of the challenges in respect to the technical approach itself.

Yes, of course, Ibrahim. So we, as SNP and also the partners and customers had have a big advantage because we are using our SNP, Kyano CrystalBridge software, and that's basically an easy way to carve-out data or move data between systems between system landscapes. And we bring a lot of flexibility to certain carve-outs. So for example, when it comes to finding go-live date with our approach, we can take basically every day in the year, we're not dependent on a month end closing and we were aiming in the whole project to make it happen on a go-live weekend. So like Sajith before said, going with the big bank won't go live and that's it, everyone can work on the next day. So that's one big topic. And 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 profit center plant and leave data behind. So that's the story for another time. But that's really a big advantage to get this data integrity right to start with a right basis. So that's some cool features that I like as a project manager and also that the customers and partners then love when doing such migrations with SNP.

Yes. I wanted to add a couple of points on what Matthias said. So when we had this customer requirement, so then we needed a tooling specialist, right? So just to add there, when we collaborate and partnered with SNP on this. So there are multiple ways that we can do the carve-out, right? 1 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. So we had a quite a good deliberation and evaluation for this customer situation, which will be the right best option because there was a sizable amount of data in the source system. And like also Matthias said, we need to do certain massaging, data transformation and quite a lot of aspects there. So what Matthias and SNP team was able to analyze and give the right approach, then the whole architectural design itself for the [ seno ] temporary systems and all of it and create the whole landscape for the carve-out that was done. So that was quite impressive.

Amazing, Sajith and thanks for adding that on because obviously, the software and the approach to have with these carve-outs and divestments do amazing things in order to achieve that technical separation, but 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 it out? And also what are the sensitivity of that data that needs to be validated before and after it's been shared as well. So there are a number of factors that needs to be considered. And I think in this 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. So great to hear. Was there any integration unexpected challenges or data challenges at all as we sort of approach this carve-outs 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-outs Matthias as well?

Let me very quickly add to this topic of data integrity. So with the approach that we are doing in the project 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. We're doing corrections after a test migration during the test phase and making there for sure that we're already heading into the next test phase with an even better basis. So you can't jump too many steps in phases you need to do the project one step by another. And there, what we always do is at SNP, we are migrating since the first test migration with the full data set. And this will help for data integrity definitely because you're not postponing to make the last -- to migrate the last 500,000 transactions at the next round and next round, no. We need to go full. And this is a hidden champion, I would say, also in terms of data quality. But you will always find topics, where you have some challenges with data integrity. So one very small detail would be like, if you are moving employees you're migrating the master data of them. So 1 employee already left the company, it's not active anymore. And you don't bring them over to the target system. Then you need to see, if there are certain processes, where this data is still used and you need to further process the data. And there, these topics always come up because in 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 1 time in their history in these companies where they were cast out, but they are still in another company now. So there's some challenges that we always see, maybe also some kind of mixed documents, if there are intercompany, a business done between our company code, that is still -- in the old system, they will be staying. That will not be carved out, but it has some business done with the company code that will be carved out. So the area always will find out in the first test migration or in the test migrations. And although you want to analyze and design everything upfront, the reimproved incomes, when doing a data migration employed into a very well-organized test phase.

Yes. If I want to add a couple of points on that, Matthias. The most important aspect is doing -- I mean, how do we mitigate the risk, right? We're talking about data integrating. That is to do multiple data iterations. In this customer base, we have had at least 4 full round of migrations, exactly the full load, right, we call test migration, 0, 1, 2, and we did a go-live simulation, right? And iteratively be improved. And 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. So once we do the full set of migration, then we did the integration testing. For example, then it is also then -- you see in this particular customer base. It is not only the SAP got separated. We're talking about 15, 16 applications getting carved out on 1 particular weekend. So the integration testing, and we have temporary landscapes for all those connected applications and also the applications which are already separated. So the integration testing how the data flow between the systems, we were able to validate together with the test migration rounds. So in that way, that was best practices that we take it from our previous engagements, and we are able to successfully deploy and deploy in this customer base as well.

Amazing, amazing. I think, yes. So the -- so I think it's important to just recap some of the good points made there. So 1 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 data entanglement across company called maybe one company called it in the data privacy, other is not. How do we handle those intercompany type challenges. And also the applications, it's not SAP or the other applications in the landscape that needs to be separated, how do they come into the picture across the separation time line itself and tested against the approach and the migration across the whole landscape, not just SAP. So those are really important points. I'm glad you guys can touch up on. Just moving on to a little bit about collaboration and the delivery itself. So how did TCS and SNP work together. Sajith, I think I'll kind of put this question to start with. Can you kind of give us a little bit insight into what made that partnership work?

Yes. I would say the trust and openness, yes, -- when we started the project, of course, TCS and SNP had a long-standing relationship and multiple assignments, multiple engagements, globally TCS was doing. But at least from me, it was first time working with SNP and we have had initial challenges, but that is quite natural when 2 different parties coming together and customer also because there is -- as I said, there are a lot of time pressure and also anxiety from the customer as well because carve-out we're doing for the first time, because any customer, at least this customer case, they have done multiple transformation projects global implementations of ERP and so on and so forth. But carve-out and this scale is first time. So with that, we had initial challenges, but we were quickly able to overcome that and we had a very strong governance setup between TCS and SNP and also our triparty governance with the customer as well. So we were able to flag the risk early and make tough decisions, and then able to move on. And then all in all, this -- the underlying objective for everyone that we had is this -- we need to meet the time line and we ensure there's the business continuity of the business of it, the business should not be disrupted. So with that, all 3 parties, customer, TCS and SNP and TCS-SNP joining hands for the customer engagement. So that collaboration and strong governance, right? And then that was key to success is what I feel. And quite importantly, when we finish the first project, second project came natural to us. Quite a lot of seamless collaborates even strengthen further and even from the customer side, yes, customer has got the confidence that one project was a successful, massive big bang project, which are without any major issues there. But then it further strengthen how our relationship has built and how we are able to successfully deliver. But nevertheless, every carve-out teach us a lesson, right? It is unique and the customer situation is unique. But how we as a partner in affording hands for the good times and bad times, that really makes the difference.

Very good. Anything to add to that, Matthias at all.

Yes. So first projects are always the hardest one. So this -- that you know that the storming, norming performing phases from the team building once you have passed this 1 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. And it was hard earned in the first project because of all the challenges that we have, but it was really rewarding because we're not all -- we not only looked at this topic of the data integrity, but we'll always look at business continuity. So in each of the test cycles when it was closed before the next test migration round started, we always, everyone together have a look at the topic performance. And -- if you do this all the time, then it's getting -- it's coming to a common goal. And yes, then the guys were looking for parameters for finding out can we size up the CPUs a little bit more, what would it cost what perimeter should be set, how to make some command with the database to even improve it. And yes, it was -- it felt like play and especially then the second project.

Amazing. Okay, Matthias. So it wasn't only about refining the scope and validating the scope throughout those test migration, but also refining the performance to meet the required performance parameters or expectations of the carbide and the customer itself as you go through those test migrations. So thanks for highlighting that as well right.

Yes, correct. Because it was -- at the beginning, of course, you run a test migration 0 in the first project, where you just have defined the scope and then all of a sudden, you end up with a run time of 100-plus hours and then everyone is looking to you, how will you be able to manage this on a weekend. And yes, the performance reviews, it could clearly show them from each cycle to each cycle that the run time decreased and everyone helped each other out to getting a stronger system on the basis side to performing better on the data migration rule side. So yes.

Amazing. Okay. So a good governance, well-defined communication channels and decision-making approach and ways of working. I think that well underpinning that sort of great partnership that allow the customers to realize the full benefit of both the technology, but also the methodology as well. So great things to hear. Let's move on to a little bit into sort of lessons learned, if you like, I think all these audience will be quite excited about understanding what are some of the lessons and so what went well. What wasn't. So what advice would you give to someone starting a carve-out, for example, Matthias, lets started yourself first. What will be the sort of maybe key advise to give someone who is kind of contemplating about a carve-out that's coming up?

Yes. Think about, first of all, that would be like the first question also when we go into workshops is what is the highest level scope that you currently think of when you are running this carve-out. So is it on a company code level? Or is it below company code level? And then out of this question already next follow-up topics will come, but 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 somewhat willing to carve-out or is the other party willing to pay for that. So that's the #1 topic for me, the high-level selection scope.

Amazing. Sajith, what about yourself? What went well from your perspective? Is there anything that you -- in hindsight, would you do differently?

Okay. I'll take this like your previous question to Matthias as well. What if someone to start a carve-out, what are the things to be focused. So retrospectively, having done 2 back-to-back carve-outs over a 18 months, 2-year period, 3 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. So the SMO and the -- driving the IT initiative because there will be multiple suppliers involved, SAP system integrator, tooling partners and so on and so forth because when we say a carveout, it's not only SAP, right, creating a stand-alone enterprise IT environment. Right from networks to data centers and application getting separated, end user services and devices and the processes that the -- so the enterprise wide impact and SAP normally is 1 of the complex application 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 getting carve-out at the same time, how the plants are aligned, if there is a deviation, how to communicate and how to, of course, correct and adjust what are the impact and the dependency. So the communication part that the governance with all these stakeholders, including the business, 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. And second aspect would be, like we said, over invest in data that is important. Overinvest in data quality, do multiple attritions and validation round, we may often need business to come and validate, because in a carveout scenario, if you look at it from a business point of view, in a like-to-like carveouts scenario. Business is not getting anything. In that sense, and we have engaged globally business users to come and test or regression test, validate. So often, those have been challenges. But if you are able to manage that, that drives the success, right? And then the cutover itself, right, and plan for contingencies. That is the -- that is what I would say that, because this is retrospectively speaking, plan A and plan B, what if something delays, how that is going to impact. So prepare for the unexpected and having contingency plans would set any. So one thing I wanted to call out what in this project in this particular phase, what we realized from a customer point of view as well as TCS and SNP as well as when we are doing this preparation, right? We started the cutover planning much earlier, right? We are creating this cutover run book, 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 of the remaining company, right? When there is a shutdown of the system, it is the shutdown for the separating company as well as the company that is remaining, right? So because in this case, right, when we shut down SAP, the RemainCo 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 of those elements have been taken care. So that is one thing I recall is a major topic. But other topics such as especially on the data, Matthias, pointed out that is migration, the first test migration we did it was 100-plus subs, right? And the cutover weekend was planned to be over a weekend. And a lot of anxieties, lot of questions and so the performance tuning perspective, but overall, I 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, right, from a data migration. So how do you learn from this, right? And then there are opportunities to improve? And how you make it better and better every round technically as well as from a process point of view, that would really help.

Some amazing inside Sajith, thank you. So just to recap in terms of some of the imports and things I heard it. 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 there's also a lot to do and it also defines what's the success of the carve-out project as well, so it needs to be cognizant of that. And the -- not getting business involved early on to make sure that they're involved, they not just validations, but also what's happening in terms of the RemainCo, i.e., in cutover, for example, to downtime is expected for the remainder of the business, not just a target carve-outs, 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, but also to the last point in terms of making sure that there's a good governance that cause the project, but also the test migration cycles are managed well and learnings are taken into the next test migration cycle, et cetera. It's all great points. So thank you very much for highlighting those. At this stage, I would like to thank you both for kind of introducing those learnings and key insights from those projects are amazing. Thank you very much. So let me switch to some of the questions that audience has posted as we talked along the way. I will pick 1 up from our Q&A prompt. So there's a question around was the company called carve-outs a firm decision from the start? Or was there some debate about time slice as well as company code. Matthias, would you like to sort of address that question? So 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?

So from a time slice perspective, we have always the overall approach to take full history, when it comes to the company codes 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, but that -- it was fixed during the design phase. And luckily, there were no real changes in the project itself. But maybe I'll give it also to Sajith as he was way earlier in the project when those discussions took place, maybe about which company code to take or not to take.

Yes, true, true. So like I said at the beginning, when the demerger or the partial demerger was announced. And it was -- the first company was the target is to get it stock listed. So that means completely decoupled from the current system because for audience information, it's a single instance global production system, where these 3 companies were operating. In at least 8 to 10, I don't recall it now, but at least 10 countries, the legal entities of the separating company and the RemainCo operating 1 single legal entity, right? So that is the project before the physical carve-out, we did the logical separation. So TCS engaged with the customer, we separated the company code RemainCo -- so legally we splitted it because that is also mandated for the stock listing. So when we started the physical carve-out, we could clearly identify which companies ports that we go into the target system. So we were able to do that. And then again, the question of time slicing out because the separating company needed full history of data. Because that is very important for them. So they handed the full history of data for those company codes. So we migrated all. And as we speak, after finishing 2 carveouts, now we have engaged TCS and SNP is engaged with the customer to do a deletion project in the source system, right? Because after 2 carve-outs are completed. Now the RemainCo has the data of the 2 separated companies. So we are engaged in a deletion project, so that is ongoing. Meanwhile, as you know, then when this separation happened on those transaction date, all those data have been ring-fenced already. So the RemainCo cannot access the separate company data, the ring-fencing with authorization control and all have been done.

Yes. Very good. I think you touched upon a couple of things which I want to highlight again, but the data perimeter itself and there's a couple of data that needs to be separated and whether it's time slice or full history, et cetera, would it fair -- would it be fair to say that it's also often governed by the type of the deal, the agreement between the seller and buyer, right?

Yes.

Okay. Very good, very good. So next question up on my screen. In your carve-out migration projects, what were the key levers? And 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 boss, there were a couple of very successful projects, the second one, obviously taking any lessons learned from the first 1 in order to make things even more smooth -- was there anything that you have in your heads kind of in hindsight, anything differently to accelerate the value or increase the value or reduce risk at all? Sajith, why don't we start with you this one?

Yes. I mean we have touched upon certain elements to this question in our previous comments. But the good example like what we have taken since we have done 2 back-to-back major global carve-outs in a short period of time. The first project was had challenges that's what naturally expected in these kind of projects. But 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. But like I said, how we improve the data migration on time. How do we do the dependencies management not only with SAP with all the upstream, 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 are 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? So -- but in the second project, we were able to take those learnings and adopt it make it even better. So the second project took us nearly 3/4 of the time to do exactly somewhat similar scale and sizes of complexity of that project. So quite a lot of learnings lessons learned in a positive way that we would use it and not only in this relationship, but TCS and SNP, we are taking it in our other end customer engagements as we speak, throughout in the Europe and globally...

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 there's anything that you want to sort of double down on now is the time.

Losing my voice. So I give next question to Sajith.

Okay. So let's move on then. So I think Sajith already covered quite a lot of points there as well anyway. There's a question, which is around, will there any specific requirements from audit either internal or external on data validation. So in our dealings with the customer in both of those carve-outs, whether any specific requirements we came across, not just from the transaction deal itself, but also from the audit perspective?

Okay. Like mention that -- there are certain obligations, guidelines, guidances from the transaction itself, right? And 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 a simple terms, right? That always exists. Then the retention period and all of that. But what -- in this project, what we wanted to or what was the objective was to see that the financial data is matching to the last cent, right? The financial numbers should match, fully reconciled. That was the requirement, and that was validated -- validated from the customer side, customer finance team and all of it when we're doing the final round of testing as well as option that 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. But during the project, we did not had kind of an audit requirement other than we have to ensure that the data is fully, fully sync 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 have to see it and plan it programs.

It's a typical data validation reconciliation.

Yes. I think that's...

Okay, very good. [indiscernible] time as well, but I would like to cover a couple more questions, if you may, a couple more there as well. So how was the historical data planned for the Spinco, this is the target the new company that's being set up. So how was the circle data plan for the target company partial or in full? And what about the archived data. So I suppose, in this case, we had historical data in full anyway, but -- was it an archived data, I suppose, is the gist of that question. What database size? Was there any challenges with that? And also 3 key learnings and checks companies should always consider in a carve-out planned to contain unforeseen risks. I think we touched upon some of those as well. It's a big question. I'm just kind of trying to compact that and fallback plan, if things are not going as planned, if things experience your recent past execution. So to summarize, I think was there an archived data, was there any sort of changes around archived data. Was there any changes around the database size at all. I think we talked about key learnings already. What was there a fallback plan at all based on those sort of the learnings we got from the 2 projects. Matthias are you back with us. Would you like to [indiscernible] archive data...

I'll take the archive data. We also had archive data in the scope. So there, we also could find a nice solution to select all the archive documents. So invoices, for example, that were related to do any transaction data to also bring the ones where we already moved the SAP data. We also brought over the archive data. So that was working nicely, I would say, was also in scope.

Okay. So archive data was in scope and that was part of the carve-out well. That's good. Was there anything about database size at all in terms of challenges because 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 that?

I mean data bases are always have their specifics, as we are doing table-based migration directly over the database we favor some databases. And this time, we had 1 that was a little bit challenging, a little bit tricky. And then you need to find the right parameters be it to be very technical, what is the file size to export the file to file share to have the best performance than putting it into the target data base. So that's something more like deactivate the archive log-in. We don't want to have archive logs to 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 will -- we can very often fix also these issues. So data base is, the sizing, yes, was a couple of terabytes and of course, they have also the challenge when selecting the data. The bigger it is, the more resource heavy those selection criterias and the attempts are to the system and also to the run time. That would be my...

And on the question on the fallback plan, right? So the fallback plan is part of your cutover plan. So the cutover plan should provision a fall black and what triggers a fallback? What are the decision criteria and what are the decisions -- which should -- what can influence a fallback? Who takes the decision. At what point in the cutover window in a calendar clock time, when this should be evaluated. So -- and it's -- 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 its, home testing it and switching on the integration, okay, that's a positive scenario, right? We should provision for fall back. 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. So fallback plan is part of that plan. And we need to provision the time within that accordingly and plan your downtime.

Thank you, Sajith, for catching that question there. I think it's important and then highlighting that the fallback has to be part of that consideration of the cutover plan anyway, in any case. So it's a great, great chance out there. So just 1 last question, conscious of time as well, gentlemen. What do the companies do in the source system in all 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. So in this case, obviously, the parent company is still operating. So therefore, obviously, the system is operational. But what about the data that belongs to that target entity, the Spinco entity, what happens in the source system. Was there any question about it in the carve-outs that we delivered.

In the carve-out, like I said, after the transaction date, we have ring-fenced the data in the source system. So that the remaining company cannot or will not access or cannot access except few authorized users for financial audits of some sort of things because that's a liability of the RemainCo because based on the deal. So very few people have access and only in the financial data, just to comply with statutory obligations. So it's all fully ring-fenced. And like I said, now TCS and SNP is engaged in a project to delete the data from the source system. The data which have been separated for these 2 companies, we are engaging in deleting those. So that we will dealing that. But yes, of course, there is backups and all, but we are deleting from the main database.

So there was an aspect of count to deletion of that data in the store system.

Yes.

Okay. Very good. So that's a possibility as which is important for audience to understand and note as well. So it's not just carrying out a system, but also being able to delete -- account to delete the data in the source. Great, so gentlemen thank you very much for your invaluable insights and your time. So again, audience, so thank you again for your time as well for joining us in this fireside chat. And just a reminder, you will receive a link to the recording as access to -- as well as in access to our latest wide paper on the SAP carve-outs as well. So it's a very good read. I would encourage. But thank you very much for your time today. And 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.