PTC Inc. (PTC) Earnings Call Transcript & Summary

I will start the webinar now. I think recording is already running as far as I know, so this will be distributed afterwards. So welcome, everybody, to today's webinar. Thank you for taking your time to join us today. Today's webinar is about a very -- at the moment, a very hot topic. It's migration from Windchill RV&S to Codebeamer. I did a post myself on LinkedIn just recently. I have a long history of RV&S. And when I look through the people that attend, I know a lot of names. I can associate the companies with it. So hello to everybody I know, and hello to everybody I don't know yet. Just a brief overview from my side, what we will cover today. So with me today is Björn Deiss. He will do the majority of the presentation. He will lead you through the migration technology and use cases that can be discussed. Maybe from a logistics standpoint, the chat is open for questions. When Björn is on the line talking about Migrator, I will be looking at the chat, answer everything directly what I can. Anything else will be discussed afterwards in the Q&A session. Okay. Let me briefly introduce NANGA SYSTEMS for those who don't know us yet. NANGA SYSTEMS was founded in 2014. We have a bit more than 60 employees, number is climbing. And from a customer base, it's about 350-plus. That's also a very volatile target, which is changing to the better a lot. You can see on the map that we have here, we've got five subsidiaries. There's one in Austria, one in Germany. Germany is the headquarter. We've got one in the U.K. And we also have one in Japan. And the offices I just named now are all sales and services offices. So we do cover the complete portfolio in those different locations. We have an office in Kiev in Ukraine. Disregarding all the turbulences, people are still working there. And what Ukraine does for us is basically software development. And software development then always leads to software products, NANGA PRODUCTS that we sell, the Migrator being one of them that we will present today. Just a few words of what NANGA offers as a service. NANGA has three pillars basically that we base our business on. So it's consulting. Consulting started for the first time. Basically, it was, of course, the founder, Dominik Kasse, who started this company as a consulting company, always focusing -- mainly focusing on ALM. That's the DNA of NANGA SYSTEMS. And most of the employees came or grew up with NANGA SYSTEMS -- sorry, grew up with ALM. The second one that we do, when we do engagements, we also resell licenses from -- not only from PTC, also other vendors. I will show that in a minute. And we resell those licenses. We support those licenses. And from a consulting standpoint, we do everything from the first engagement all the way through the life cycle of the use of the product. And the first part that I mentioned was NANGA PRODUCTS. Like I said, the Migrator that we will be introducing today is one of NANGA PRODUCTS. We have many more. And NANGA PRODUCTS is always an add-on that we develop for customers based on the experiences that we have in a project that fulfill or that fill gaps like usability, integration or administration topics. That's the three pillars that NANGA is based on. Move to the next slide. And I will show you the partners that we work together with. So you basically have six different partners. It's -- PTC is our main partner. This is, of course, also what we based our discussion on today, RV&S and Codebeamer both being PTC products by now. We have other partners. And it's mainly focused around vendors that are very heavily used in R&D developments. So we have Atlassian. We have a partnership with them, also services and license selling. pure-systems, we had a partnership before the acquisition. Now pure-systems is part of the PTC family, too. We have, of course, a partnership with LieberLieber/Sparx Enterprise for Enterprise Architect. And we have Apptio, Apptio being an agile solution that can sort of implement the safe framework in your company, connecting to team-level tools like Codebeamer or RV&S. Some of our customers, I don't want to go into any specifics. We've been around for some time. We are working in many of the larger projects maybe as a service engagement, maybe as the licensed reseller in these large engagements. Like for example, Volkswagen, we have done services for both solutions, RV&S and Codebeamer, in the past decades. So a lot of experience, and that's also, for example, when you look at Veoneer, where this idea of migration came from, but Björn will talk about this in detail in the next few minutes. Just a very quick glance, I don't want to read through everything. We will distribute the slides afterwards. But this is an overview of the services we offer for ALM. I think if you put it in a nutshell, I haven't heard anything that we can't do. If it's software and you can program interfaces, usability extensions, you can configure solutions, you can train solutions, you can make add-on widgets that you need for a customer. We have a training catalog for different roles and different project situations. So anything around ALM, please feel free to contact us. We're happy to work with you on this. Okay. Just a very quick overview, and I think it's for distribution and reading. But this is sort of the people, the larger projects we work with together with PTC, focused here on the automotive industry mainly. And we are an implementation partner in this case. And we are discussing with a few of those also the migration technologies we present today. So we've learned from the best, which was not always an easy way. But the results speak for itself. This is the locations. In case you need to have contact with us. And again, if you have any questions, type them in the chat. We will monitor the chat all the time. And I will now hand over to my friend, Björn. Please do your magic, Björn. Thank you very much.

All right. So let me my share my screen. All right. Yes, welcome also from my side. My name is Björn Deiss, as Lars already said. I'm Senior Consultant at NANGA SYSTEMS, with the company since 2018, working with Codebeamer since 2019. Because as Lars said, we have been a partner of [ implant ] even before the acquisition, so we have a strong background in both RV&S and Codebeamer. And what I want to talk to you about today is the migration from RV&S to Codebeamer. So topics will be questions that come up when we were talking to our customers, when we are planning the migrations, to build questions that ask us. And this will all be supported by some use cases and some examples that we learned in the last years. And I will also show you some ideas how that then influenced development of the NANGA Migrator. So it will not be a demo of the Migrator today. We won't do any live migration. If you're interested in watching that, please contact Lars and his sales team or me directly, and we can schedule a demo. But today, it should be more really the high level and how that Migrator was built and why we made some decisions there. And last but not least, of course, we have time, as Lars already mentioned for Q&A. So all the questions that Lars can't answer during my presentation, we will read through them, then after the webinar, and I'll try to answer them afterwards. But let's jump directly into the topic. And yes, I'm going to start with one really important remark here. There is not something like size fits all if we're talking about migrations. So if somebody would tell you they can do the migration in a given time frame or with a fixed budget, my very own -- my specific opinion is I think that they have no clue what they're talking about or they just want to sell you something. But I think it's not possible to have this one-size-fits-all approach for migration. The reasons are your data is completely different to the data of your -- of another company, of your competitors. It's like the data size that really matters, the data complexity, the configurations that you made in RV&S and that you want to keep in Codebeamer, but also the strategy, how you want to migrate. And it's all topics that we want to discuss in this webinar today to show you, okay, there's nothing like a one size fits all. But still, we will find solutions for every migration that's out here in the market. Well, let's start with the data because I think this is the starting point for every migration, the data model, the configuration that you have in RV&S and how to bring that into Codebeamer. And the first thing that I want you to think about as when you're starting with a new tool, you're not working with RV&S anymore, you want to start working with Codebeamer. So you really have the chance to rethink what you did in the past here. Most of you will probably start your configurations 5 years ago, 10 years ago, 15, 20 years even. So is there maybe something that you could do better, that you could do easier now in Codebeamer than you did it in RV&S in the past? Is there maybe some new feature that Codebeamer offers that RV&S didn't offer or at least a version that you used when you started working on your configuration, was not available in RV&S? So is there anything that you can enhance configuration-wise or process-wise? Also, talking about the processes, are they still up to date? Are the workflows that you configured in RV&S, are they still what you need? Or could you also make some things or some changes there, make things better? And then last question, about the data itself. So do you really need to migrate all the data? Very often, we see that, of course, everybody wants to migrate everything from RV&S at the beginning. But then when they start the migration planning, they think about, "Well, maybe we do not need everything. Maybe there are some things that we do not need anymore in the Codebeamer or that can just stay in RV&S as kind of a history software." But yes, we'll look at that later. So to summarize that in one sentence, my advice would be do not try to reimplement RV&S in Codebeamer, but think about of Codebeamer as a new tool and think about how you can make things that are there. And to support it, I had chosen two examples that we got from some migrations that we did so far, two real customer examples. The first thing or first example here is a configuration that you see on the left side here, how we found it in the old RV&S system of this customer, where we had three different fields with some content. So I just named them field A, field B, field C in this case. And interesting thing about this field force, they were not needed anymore, not even in the newer RV&S projects. So it was something they needed back then, but new projects don't use these fields anymore. But still, the information there is relevant. So they said, well, they want to migrate it to Codebeamer, but in a way that it does not affect the new Codebeamer configuration too much. And also, the second thing about this field force, the information there was stable. So it's all legacy data, which is needed, which is still relevant, but it won't change anymore. It's not updated, nobody maintains it anymore. So the easy option would, of course, be -- well, for field A, we created a field in Codebeamer. For field B, we created a field B in Codebeamer. And for field C, we also created a field C in Codebeamer and met this configuration of 1:1. But in this planning, we came up with something a bit better, make a better configuration in Codebeamer as such. So this is what we did on the right side here. We just merged that together into one field. So instead of having three legacy fields, we just have one field, which is actually called legacy RV&S data as an example. And what we needed to do there is then enhance our Migrator to make this merging possible. So basically, what the Migrator offers now is the possibility to merge several fields into one field. So we have, in this case, three RV&S fields that are merging to one Codebeamer field. Still, we keep the data, the information about where this came from. So you see that this field is over -- starting with the name of the field, where the content is coming from, an RV&S, so that's the field name, RV&S field A here and then comes the content. And then we have some blank space and then comes the second field, the person's name and then content. And this can be repeated as often as needed. So the big benefit for this customer was that instead of having -- I don't remember actually if it was three fields or even a bit more, but all these legacy fields do not need to be configured in Codebeamer anymore. We instead have one field. And if newer projects don't use that legacy data, well, it's just one field which is empty instead of three, four, five fields that are not needed. So this is one example how you could rethink your Codebeamer configuration and what -- or how that affects the mapping. Because it's clear now that we are having different configurations in Codebeamer and RV&S. We need to find a good solution on how to bridge that gap, how to map these differences in the data model. And that is one example how it could look like. Another example that I will bring you is about a status field in the RV&S configuration of another customer. Status field is probably something everybody knows. And I just put some examples here, not a full status model. But one state called in progress and three states with done, rejected and canceled, which are end states in RV&S in their configuration. And what they were thinking about was, well, as we do not want to have these multiple end states anymore in our new Codebeamer configuration and instead we just want to have one single field -- sorry, one single state which is the closed state, the end state for the new RV&S workflow -- sorry, for the new Codebeamer workflow. So this is what we see here on the right side, top right to be more precise, the status field is now having a start state, which maps from the in progress, and a closed state, which maps from done, rejected and canceled. Now what this customer wanted is still some meaning behind the closed reasons. So not only the status closed but also some reason why it was closed. And they created a new field for everyone. So instead of having three different end states, they said, "Well, we want to have one state and closed as another state." But additional field closed reason, where users need to fill the reason for closing the item. So this is a mandatory field as soon as the status is closed. And this, of course, is a good idea configuration-wise, which caused a few issues for us and for our development team in Ukraine, as Lars already introduced them. When they were working on the Migrator, they needed now to implement something which we call the conditional mapping. So instead of just mapping the status to the status field, we needed to have a conditional mapping, first of all, status-to-status, but then also in case the status was done, rejected or canceled, met this field to the closed reason and mapped the status to a choice field in Codebeamer. So yes, two examples of how our customers changed their Codebeamer configuration because they had a possibility to try something new in the tool and how we supported that with some extensions of our migration utility. Now after the part that we had a short view on how data could look like and how we handle differences in the data models, let's discuss the overall strategy of such a migration. So again, there is no one-size-fits-all solution. But there is something like a tendency, how you could do your migration. So if you give a small set of data, if you normally have a small company with just a small amount of data, we could, of course, migrate everything at once. So this is what we call here the big bang. You start with your migration, you do everything at once. And if you finish the migration run, then everything is moved from RV&S to Codebeamer. But this is really just for very small amounts of data. Because as larger data gets, the time for running such a migration would be increasing, of course. And nobody wants to have a migration that would be running for 3 weeks and stop the complete work on RV&S for 3 weeks and then continue in Codebeamer. So as large as the data gets, of course, you need to think about it a bit differently like, for example, migrating one project after the other. This is something that we also support. And this, of course, gives you some other benefits, like it's giving you a clear separation of the users that are already in Codebeamer or that are still working in RV&S. And this can be used, of course, for moving the users to Codebeamer project-per-project or to also decide if you want to keep some projects in RV&S to decide which projects should be migrated and which should remain in RV&S. This is also something that we've seen, projects that are closed in a few weeks or a few months and do not need to be migrated to Codebeamer anymore that they will be finished in RV&S and will never be migrated, but you only migrate projects that continue to live in Codebeamer. Talking about data in systems in RV&S environment, which is too big to even be migrated project-by-project, we, of course, also support a migration where we just migrate part of a project until the project is completely finished. And this is something that's made possible by the delta migration, for example, which I will talk about in a few seconds. But before going to the delta migration, I want to also show you how these different approaches, different strategies on how to choose the data that is migrated in one run, a fact that the development of our migration utility. And to show you that, I'm going to zoom out a bit and want to show you really the high-level process how this tool works. It's three steps that it performs for each migration. And these steps can, of course, be repeated as often as needed for the full migration of the data. So the first step is always to read-in the data from RV&S. And this is where we define a strategy, so we can read-in all data at once on the complete system. We can define a single project that should be migrated or we can use queries or query definitions to select a certain part of the data that should be migrated in this run. So that could be, for example, a certain part of a project or it could also be the new slice of data according to the item types, for example, having all the box from three different projects being migrated at the same time and then the next item type of the same project, for example. All this data is read-in on the first step and then transformed into some intermediate data model. And from this intermediate data model, we create Codebeamer items. First of all, we have the choice to say we're going to create them into existing trackers or into new trackers. So depending on your settings in Codebeamer, if you're using deployment models and so on, you could either say, "You need to pre-configure the trackers or you can just activate the template and just template will be used automatically to create new trackers. And then there's also the difference between so-called normal items like box defects, user stories, tasks, whatever. They will all be migrated into item-specific tracker while documents will be migrated into a document-specific tracker. So if you have two different documents, both type of requirement, for example, they will both be migrated into their own specific tracker while they still have the same tracker-type requirement, or box, for example, will go into the item-specific tracker of [indiscernible]. One of the last step, and this approach is that as soon as we created all the items, we can relate them. So we might create relationships, either to relationships in Codebeamer using this relationship fields or to associations. An important thing is that this can be done separately. So we can also say, well, we just run the first two steps. We do not run the third one. We do not migrate the relationships yet. Because for example, if we have a couple of projects that are really connected to each other, we could say we first migrate all the projects, all the data and then on a separate step, migrate a relationship that we also can relate all the project data in between each other. And what's really important is that this idea of how we perform that migration on a really high level is not something that we came up with in the last few weeks. But it's something that's proven to work for years already. So the first time that we used this approach and the first time that we created as Migrator, Lars, I think it was 3 years ago now when we migrated from SystemWeaver to Codebeamer for a very big Tier 1 automotive supplier. But those who don't know that tool yet, SystemWeaver is a tool that's pretty common in the Nordics. And now that you see how this three-step approach works, it's pretty easy to exchange the first steps. So all we needed to do to go to RV&S instead of SystemWeaver, we needed to change the first one. Instead of reading XML files from SystemWeaver, we are now reading the data from RV&S directly via the RV&S API and everything else can remain stable. So it's really a proven concept, a proven software that supports the migration here. And of course, if somebody has different tools that need to be migrated from, it's easy to change the first part of the tool again. Instead of reading data from the SystemWeaver or reading data from RV&S, we could, of course, also read it from some other source. So yes, while a lot of people are talking about migrations here, we still need a couple of times with different tools. So feel free to also discuss it with Lars after the webinar. But yes, coming to the part of the delta migration that I was talking about, this is under the big keyword, business continuity. So the important thing is that many people think about the migrations as kind of an operation that happens at a certain point in time. So it's like there's a clear before the migration, then there's the migration happening and then there's the thereafter. So it could be a big bang approach, as I said before, or it could be project-by-project. But even if you're talking about project-by-project, people tend to think about it as a small big bang. So you start migrating the project, you finish the migration, then you jump to Codebeamer and that's that. But what's important is that there is another possibility that we have here, a so-called transition phase, which makes sure that you can work in RV&S without any interruption until all the data is in Codebeamer. There are two really important examples why you would do that, working with this transition phase during the migration. One is the sheer amount of data. So if you have lots of data in one project, it doesn't even work to migrate one project after the other. It could make sense to use this transition phase on the delta migration. The other one is while it also supports people in giving them the time to get comfortable with the new tool. One example that we always see is we're starting a migration. We're making plans. We're making some test runs. But we always do it just with a very small group of people, so some IT admin, some key users maybe, some people from the different business units. And once we recasted everything and those few people said everything is fine, we start the production migration now. We're on the migration. And then hundreds of thousands of people see the data in Codebeamer for the first time. And every time, they see something which is not exactly like it was intended to be, something was wrong in the mapping, some data is missing, something is just not perfect. And this is also something that can be made better using this transition phase. So what would it look like? How would it work out? We would still migrate an initial run. So all the data that's available in RV&S will be migrated to Codebeamer for a given project or everything at once, depending on the strategy. But then we don't stop the migration and say, "Well, now it's finished, it's completed, and you can continue working Codebeamer." But instead, we are starting this transition phase, where we regularly keep on migrating. So we just run the delta migration, which only migrates whatever has been changed since the last successful migration. And we can continue working in RV&S during the time. So one example of how it could look like as the following here. We have a huge project where we need to slice into three different parts, part A, part B and part C, because we just can't handle all the data in one migration. So the first step would be to migrate part A. We migrate all the data. But as said, people would continue to work in RV&S. But now as they are working in RV&S, they already have the data available in Codebeamer and they could have a look at the data. So they could already get familiar with the new environment, and they could check if the mapping -- if the data -- if everything as it was intended to be. In the same time, the migration is run on a regular basis. So this means that we run the delta migration. Everything that has been changing in RV&S will be migrated to Codebeamer as well. So people can actually see the changes they make in Codebeamer and they can continue to work in RV&S until we set a final date for a final migration. Same thing now repeats for the part B of the project. So we again migrate everything off part B. People keep continuing working in RV&S. They can watch what's happening in Codebeamer. Data is migrated all the time using this delta migration and then repeat it for the last time for part C as well. Now after we migrated part C and we've given users of part C also some time to get familiar with Codebeamer and check for errors there, certain deadlines is defined at a certain date, where the actual transition happens. That could be for something over the weekend. So maybe a Friday evening, everybody makes last changes in RV&S, or to regain the last delta migration before the whole project runs. And on Monday, the users can continue working in Codebeamer completely seamlessly. So it's really like they shut down their system on Friday. They start it again on Monday in a new tool. But now it's not like they have never seen it and they find all the errors and the mapping differences and so on. But they were able to watch that how it would look like in Codebeamer for a couple of days or weeks even before and they can really seamlessly work in Codebeamer then. Well, that's the business continuity example and how we can support it with the delta migration and this transition phase. And combined with this overall strategy and with different approaches on how to configure your data and so on, this is still more a high-level view on how to run such a migration and high-level planning questions that we can always ask. But there's a more detailed, more technical question that we also hear every time. And this is about data history. So if we go a bit more into details here, everybody really wants to migrate all the data. It is typically for each migration that people are asking us at the beginning like, "Can we migrate everything from RV&S to Codebeamer? Every single record that we have in RV&S, every single change for every single item, we want to have that in Codebeamer." What's very typical is that we don't start the discussions and say, "Well, of course, we could do that, but that's a huge effort." And then people start to think, "Well, not sure if that really makes sense or maybe there's a better solution." So in the end, it's the same thing as we were talking about the data configuration here, the data model, we think it, think about if it really makes sense to have all the history start in a new tool or if you could make a separation here between the history, everything that happened in RV&S and everything that will not happen in Codebeamer. So what's -- or what's the three approaches that we found out that are working pretty well here as the following. First of all, the easiest one, keep the history in RV&S. So that's something that a lot of customers come up with in the end. Well, maybe it just makes sense to keep a small amount of licenses for RV&S, keep running that server in read-only mode, keep that as really the history server for everything that happened before. So you have all the history that -- of all those changes that you made in RV&S, you can watch it there. And everything what's happening after RV&S is happening in Codebeamer and you have the backlog there. And this is one possibility. The other two possibilities are, more or less, common. It's about migrating the history but not migrating it completely to Codebeamer because that would be as such way too much effort normally. So one solution that we found very common is that we attach the history. So we are exporting all history from Codebeamer from each single item into an HTML file. And that HTML file can be then attached to the Codebeamer tracker item. So the benefit that you have from that solution would be, of course, you have all the history in Codebeamer. You do not need to change to RV&S if you want to look something up. But you do not need to migrate every single entry and need to create new history entries in RV&S -- sorry, in Codebeamer. Instead, you have on file, which is containing the complete history of the item, everything that happened before you switched the Codebeamer. The second solution is similar. But in this case, we're not storing it to the Codebeamer tracker item. We're creating the same file, the same HTML file, but instead, we are storing that somewhere for some other network share, so you can select where you want to store it. So you still keep track of all the history of the items, but you do not raise space in Codebeamer for something that's just used not very often. Because this is also something that, from our experience, happening a lot that people tend to overestimate the time they actually need to look up something in the history. And maybe it's a better solution than storing everything in Codebeamer. Maybe it could be also a solution to store it to somewhere else. And if you really need to look it up, then go there and try to look for it either on the network share or even in RV&S if you run it as a legacy system as such. Now the second of these more technical details that are always asked is, yes, how do we handle our baselines? And there's one thing that we came up with one of our customers, which we also implemented in our migration utility now. What you see here on the left top side is different baselines in RV&S. So the segment would have a baseline 1, 2 until 5. And you see we already skipped 3 and 4. So that is something that our Migrator is capable of. You can select which baselines you want to migrate actually, in this case, just 1, 2 and 5. And what you see on the bottom of this page here is a representation of the item history of a Codebeamer tracker item. So this is just a table that you see there if you click on the item history of the tracker item. And the entry on the bottom is the first one that's being created. So that would happen if our Migrator in Codebeamer runs and finds the first baseline number 1. So it creates the item. This is the submit action here and then terminology of a Codebeamer and it will create a version 1 of this tracker item. Now it automatically detects baseline 2, detects all the changes that have been made in RV&S, submits them to Codebeamer, updates the item. And this would be the second entry here, which is an added action, which creates the version number 2. And what you would also see in the history of Codebeamer then would be the field changes, new value and old value. So you would see all the differences between version 1 and version 2, or coming from RV&S, baseline number 1 and baseline number 2. And the third one, the baseline number 5 would be treated the same way. So in that case, it will be another update of the Codebeamer tracker item, which would lead to version number 3. So you see here that it's not somehow tied to the numbering of a baseline, baseline number 5 upgrades version 3 because this is just a third version of the tracker item here. And what we would also see again, of course, would be the field changes, new values, old values, so all the differences that have been migrated in between baseline 2 and baseline number 5. So basically, what it does is you can select different baselines. You can also choose which baselines you want to migrate. You can skip some ones like the number 3 and number 4 here in our case. And every baseline is represented not only in some history file or something, like we did it for the overall history of the tracker item, but it's really represented here in the items in Codebeamer with updates of the actual tracker item. Yes, that's the second question that we're always asked or almost always asked on a more technical level. Now that we're talking about the strategy, about the data, but these more technical questions, one question that's still remaining, of course, how much time do we need for it? So how can we come up with a good effort estimation of how long we will need for the migration? And in the end, of course, how much will it cost us? Again, I can just repeat myself here. There is nothing like a one size fits all. It should be clear from what we discussed so far in this webinar. One example, if you have a really small amount of data and you can run a big bang, it's a completely different thing than if you have a lot of data, a lot of projects, a couple of hundred big projects, where you need transition phases and so on. This will take a lot more time, of course, than if you can run a big bang. So it really depends on your data, your data complexity, the amount of data, your strategy, how you want to and what's the use and so on. So as I do not want to just give you the answer, "Well, it depends," we, of course, have come up with something a bit better than just saying, "Well, it depends." We defined a process how we can support you with estimating that effort. And that process looks like following, so first of all, we start the discussion between you and our migration experts, talking about the requirements that you have for your migrations. And it also comes with something we call the pre-migration analysis, where our experts have a look at your data, check just how it looks like, what data types you have, what do you want to migrate, how you want to migrate it and also support you in setting up the mapping tables, so to be, at the end, capable of running some test migrations. And these test migrations, these are the really important part here because they give you a good understanding of what would the actual effort be in the end. We set up some mapping tables at the time, so you know how complex that is to start up the mapping tables. You make your mind up how you would configure Codebeamer if that's the best solution or some things could maybe be configured a bit better, how long the actual migration runs, if you want to have this transition phase, for example, how long it should take time for them. So after having run some test migrations, you should be able to effort and to estimate the effort, which is needed for actual production migration, which then comes as last step, of course. And this migration, the actual production migration to Codebeamer can then be also supported by our experts, of course, or you could decide to just use our own migration utility and do the last migrations then on your own. Now what you see here is that the first three steps are colored a bit differently than the last one. And this is because the first three steps are supported by a trial version of our migration utility. So you have the possibility to ask our sales guys for some trial of the Codebeamer Migrator, and we can support you then with all the things that I just explained here. We can support your pre-migration analysis. We can run some test migrations with you. We can support the creation of the mapping files and so on, making it possible that you get a good enough understanding of how much effort it will be. And then after this trial, you can make your decision. First of all, do you want to use our utility for running your migration? And second, do you want to use it on your own? Or do you want to continue working with us together on your migration? Now I've talked a bit about Migrator already mainly as such and why we've chosen some of the decisions that we made and where it was coming from. One obvious slide that I want to go over pretty fast is -- there's, of course, a lot more. So we have talked about baseline, delta migration, history and so on. But of course, there's a lot of more features like rich text conversion, like validation of the data after the migration and so on. So yes, if you're interested in the full feature set, again talk to Lars, that's his stuff. And what I want to come to ask rather, the key takeaways for you, so what is really important, what should be the outcome of today's webinar. So first of all, I've said it for a couple of times, but I can only repeat it again because it's really for me one of the most important things is there is nothing like a one-size-fits-all. Estimating what you need for your migration is really depending on your data, how complex it is, what do you want to migrate, how you want to migrate it, how you want to set up the configuration for Codebeamer, what differences you have there and all these different decisions you need to make. Because of that, because there is no one size fits all, second outcome is flexibility is key here. So you need some tool like the Migrator that we developed, which can handle all these different options, which can handle the flexibility, which gives you the flexibility to choose a big bang or really project-after-project approach with transition phase. And the last really important thing is, well, you probably do this migration for the first time, I guess, at least, at least to Codebeamer. I guess, nobody is migrating to Codebeamer the second time already. But we have done it a couple of times. So based on our experience, trust us if you need support here, just contact again Lars or contact me, and we can support you there with your migration. Because we have done that a couple of times. Well, and that's it already. So I just want to say thank you to everybody who joined this webinar. Of course, as such, we will stay in the line for some minutes, answer all your questions, if there are some more coming. And if you want to ask some very specific questions or if you want to see how this actually would look like with the Migrator as such, contact Lars, contact me, you will get all the slides after the webinar. I think we'll give enough contact information so that you can reach us and ask everything that you want. But for the moment, thank you, everybody, and hope that there are some questions coming.

So super, thank you, Björn. I see hundreds of e-mails coming my way. Thank you for that, Björn. So looking forward to answer everything. And no, fun aside, we've got five questions, Björn. The first one is a question if we are also able to migrate Windchill requirements connect to metadata, exchange IDs, for example.

That's something that we would need to discuss. Because currently, we can't just coming from the -- if it's not stored in RV&S, it's difficult. But as I understood the question, it's the metadata that's stored outside and export. So that will be difficult. Of course, there could be options. If we export first and then somehow connect it to our database because we have something like an internal database that stores all the IDs from the elements that we have imported, for example, that supports this delta migration. So there will definitely be some technical possibilities to implement that. Out of the box, it's not possible yet. But this brings me to one very important thing. If there are some features that are not available yet, feel free to discuss them with us. Because that's our philosophy that we will continue to develop this is my greater fervor. So all your requirements that are not met by the current version could be implemented for a future version then. That could be one of those ideas that we could maybe implement for -- or to that one, whatever, of the Migrator here.

Super. Thank you. And I've mentioned one -- I've answered one question already earlier going into the same direction, Björn. So we are still developing further use cases, add-ons and so on and so forth. So like Björn said, please approach us for this. We need your guidance for future use cases. But we're ready for it, and we've got a few -- a couple of use cases on the top of our list already.

One more remark maybe here, this is also why we have this trial period. So if you're not sure if all your requirements are met, ask Lars for a trial period. We can check if the Migrator can already fulfill all you needs. If not, then we discuss what's missing and we can implement it during the trial period, so you see if there are things working the way you want it.

Super. Four more questions, let's go for it. So then maybe it has been answered already in the presentation, but one answer was when doing a project-by-project migration, is it possible to migrate traces between items in different projects?

Yes. As such, there are two ways in the end how you could do that. First of all, it could be that you say, okay, you just migrate only the project data without the relationships first. Or you could also migrate everything at the beginning and then run a second run later on, which only migrates the relationships. Because what happens if the migration can't relate two items because one is maybe not existing yet in Codebeamer because it's coming off a different project that hasn't been migrated yet, it will show an error, which is clear then where it's coming from, well, the item is not there yet. So you could ignore it. You could migrate a second project and then run a third migration run, which only relates to the items between the two projects. So that's perfectly possible.

Okay, super. So you have many approaches for this. I hope this answers the question. If not, again please contact us for further clarification. Next question is, is it also possible to jump from Integrity 1.2 to Codebeamer? So version 1 -- sorry, version 11.2, sorry.

Okay, I was thinking about it, version 1.2. It should. So we may need to change a bit because it's a really very old version already. I would need to check how -- or if there were any differences in the API. Because as said, we are using direct API access to RV&S in order to retrieve all the items. I would actually need to check if we would need to integrate an older version of the API. But that should not be a big issue. So I'm not sure yet which is the oldest version that we support out of the box. But it could be that it is 11.2. We need to check that with our development team. If not, we need just to use a different version of the API and it is not a problem and no problem also to support 11.2.

Okay. So maybe one remark because this is an anonymous question. We would need -- please approach us with e-mail data or your e-mail, so we can get back to you and discuss the topic directly. Next question we have is, are we going to migrate all the objects and comments?

Yes. Short answer is yes.

Okay. And then we have one more question or we've got two more questions actually. How the documents, attachments, access to PTC, et cetera, are migrated from RV&S to Codebeamer, for example, there are several terabytes of data stored in an RV&S storage. So that's the S in RV&S. So that's a question for you.

Okay, I didn't get it. It says store as an attachment or in source?

It sounds to me like source, but it doesn't clarify or specify if it's source or not.

Well, yes, in case of attachment stored directly in the items, we, of course, also support that. So this is the most -- part of it comes about to the migration time. Because we need to download the data from RV&S and we need to upload it to Codebeamer again. It's all supported. But this is -- if you have a lot of attachments, something I would recommend, the transition phase and a delta migration and to run one migration over here, migrate all the attachments first. And then later on, some delta migrations, which will be done a lot faster if all the attachment have been migrated already. If it's actually stored in source and the items are not placed as attachments in RV&S but are just linked, then this is something that we need to discuss. Because in the current version, source and source links or trace links are not supported by the Migrator. This is something that we are currently in discussion with a couple of customers if they need it and if yes, then which way they need it. So I don't know if you have the name of this question or if it's also...

Yes, we can follow up. And then maybe one comment beyond that, there's two more questions also from an old friend and from an anonymous person, is all around the source discussion, right? So maybe one strategic outlook that I can give from a PTC side, they are planning to integrate the two solutions, so the source part and the Codebeamer part. And I think we still have to discuss what data you have there. One question was, can we migrate it to Git and then connect it to RV&S -- sorry, to Codebeamer? I think that discussion, we need to be in detail. We've got contact data. And if not, like if you're anonymous, please send an e-mail to me with your contact data and then we can follow up with the discussion separately.

That's also something, maybe just a comment about that, that we did some migrating from source Integrity to Git is something that we did in the past. That's also possible. It's not part of that Migrator here because this Migrator is really focusing on the requirements and validation part, not on the source part. But it's something that could be also connected that we say, okay, we do a Git migration there and then do some post-processing to related data again. But yes, as such, this is something that's not coming out of the box. That's something that we would need to clarify in the future then with the customers.

Yes. And we will make sure that we contact everybody about their questions directly then. Again, if it's anonymous, we need to have some contact data. I've got one last question here now. It's about the partial migration. So if you partially migrate, you have both systems and -- but with RV&S being read-only mode and CB for the rest, or how is that solved so that there's no changes on one side?

Yes. Partial migration, it depends. So it could be in the way that you say, okay, you do it without a transition phase, then it would be you do a partial migration. And as soon as you start a migration, this data is locked in RV&S. So how we could do that is, for example, we were always, as such, storing in a database what we have migrated so far. And we have also the possibility to write back the information about the migration to RV&S., so information about times to migration, the corresponding tracker ID of the corresponding item and so on. So there's ways to keep track of what has been migrated already and what has not been migrated yet. If you run without a transition phase, then, yes, you would probably put RV&S or at least these parts that you have been migrated already in read-only mode or just do not allow users to change them anymore and people will directly search in Codebeamer as soon as the data is there. If you work with this transition phase, as said, it would be exactly the other way around. So you would keep working in RV&S. Codebeamer would only be in read-only mode until you say you run the final migration. And this is probably the most sophisticated version of a migration that you say you can keep this transition phase for days or weeks if you need to. People continue working in RV&S. Codebeamer data is all in read-only mode. They can see it, but they can't change it. Because all changes they would do there would be useless. They would be overwritten. So the daily work is still being done in RV&S. And then at some time, you just moved them from RV&S to Codebeamer. Running the last delta migration, as soon as you start it, you would, yes, put RV&S in read-only mode so that users can't change anything anymore after the migration started and as soon as it's finished, then could continue in Codebeamer. So which systems is the main tool, that is still being worked on. And which one is just in read-only more depends a bit if you're going to use this transition phase or not.

Super. Perfect. There's no more questions, at least not in the chat at the moment, or in the question-and-answer -- there's one popping up. In a few words -- maybe in a few words, why should I migrate from Windchill RV&S to Codebeamer? Does PTC -- that's something we will take offline, I think. I have your name. Of course, very quick answer, of course, Windchill RV&S, it's not end of life. There's too many people working with it at the moment. But the direction is, specifically if you're talking about us, it's Codebeamer. So we are just offering help to get there. It's no pressing issue. But something that might be considered mid- to long term by many people. And if you want to have a discussion about Codebeamer, what's the advantages of Codebeamer, how is it different, please get back to us. We'll be happy to do a demo for you. We've got a demo environment, so we can show you differences between Windchill RV&S and Codebeamer and maybe talk about specific use cases you might have that you can find in Codebeamer. That's the answer to this one. Again, so from a logistics -- there's one more question coming up. If you have a fully customized solution and we want to get rid of PTC, are you able to migrate everything to Codebeamer or to another tool if we have a fully customized solution? I'm sure it's [indiscernible] model, right, Björn?

If we could migrate to something else in Codebeamer, did I get it correct?

It says if we have a fully customized solution and we want to get rid of PTC, I guess, that's RV&S, are you able to migrate everything to Codebeamer or to another tool? Okay. So it's a question about the flexibility, RV&S to Codebeamer or to something else.

So to Codebeamer, of course, yes, no problem. Whatever customizations you did, that should not be an issue. I mean, most of the customers we migrated so far also were on really customized configurations. To another tool, this depends a bit on the tool. Because currently, everything is built in a way that it supports migration to Codebeamer. Of course, we could also try to migrate to another tool. But this really depends on which tool it is and how the APIs, how the -- how everything looks there. I can't give an answer to that, it depends on the tool. So approach Lars or me and then we can find a solution probably.

Exactly. And there has been experiences also with different tools from different colleagues of us. You're mentioning here Polarion in the question, in the Q&A session. Let's discuss that offline. Let's have a discussion about the needs that you have and then we can see and discuss what possibilities or what actions or what options we have there. Okay, looking at the time, 4 minutes left, I think we used up the time very good. So Björn, thank you very much for the interesting presentation. So there was many, many people attendees, still a high number of attendees. Again, we will send out all the material that we've presented today, so the NANGA overview and the slide from Björn that he's presented about the Migrator. You will have contact details. Please send an e-mail. So according to the job description of Björn, you know what to send to me and what to Björn. So we would be in sync there, no challenge. And we're really happy to talk about this, maybe have a discussion and have a demo, send a trial version or perhaps give you a trial version. There's many, many options we have. Approach us, be open to discuss with us. And I think for today, we should close this webinar. Thank you very much, everybody, for attending. And we are looking very much forward. This was only the first step to hearing from you in the future and work together with you. Thank you very much, and have a good afternoon.