[00:00.000 --> 00:10.320]  about migrating from proprietary to open source knowledge management tools. I'll talk a bit
[00:10.320 --> 00:15.800]  in general about the migration process and then demonstrate two migrations, one from
[00:15.800 --> 00:22.640]  conference and one from SharePoint with different technologies just to see what's possible on
[00:22.640 --> 00:28.640]  our side and in general. So first, why migrate from proprietary to open source? I'm sure
[00:28.640 --> 00:34.400]  everyone has a lot of good reasons for that in mind but some that we have identified as well
[00:34.400 --> 00:39.920]  would be first for privacy and security concerns. Of course, with open source software, you have
[00:39.920 --> 00:46.400]  more flexibility in where you host your data, how you host it, the environment and access that
[00:46.400 --> 00:53.600]  you set up. Two other concerns that are related and we have also seen some important examples in
[00:53.600 --> 01:00.480]  the recent years are vendor and data lock-in. So when you're using a proprietary software, you're
[01:00.480 --> 01:06.480]  a bit more vulnerable to the vendor than when you're using an open source software in the sense
[01:06.480 --> 01:11.840]  that if they make any significant strategy or pricing changes, you may find yourself in a
[01:11.840 --> 01:18.640]  situation where you need to migrate quickly or you need to quickly adjust to that change. A
[01:18.640 --> 01:26.560]  recent example is Confluence. Maybe some of you have stumbled across it. They had a cloud version
[01:26.560 --> 01:33.840]  and a server version and a data center but that's usually for larger teams. The server version was
[01:33.840 --> 01:40.320]  used by smaller teams that wanted to host the data on their premise and in late 2020, Confluence
[01:40.320 --> 01:46.560]  decided to stop the server version. So because of that, a lot of small companies had to either
[01:46.560 --> 01:52.080]  move to cloud, so host their data in the states, which wasn't possible for a lot of people,
[01:52.080 --> 01:57.920]  or move to data center, which was much more expensive and difficult to handle. And that was
[01:57.920 --> 02:04.160]  an example of how using proprietary software can make you quite vulnerable to their changes.
[02:05.120 --> 02:10.160]  One other thing that is important is the data lock-in. So using open source software usually
[02:10.160 --> 02:17.040]  allows you to migrate easier and integrate with certain tools due to open standards and protocols
[02:17.040 --> 02:21.440]  and formats. So if you're using an open source tool at some point and then you want to migrate to
[02:21.440 --> 02:28.480]  another, it may be easier than migrating from proprietary tools to other proprietary tools
[02:28.480 --> 02:34.960]  or open source ones. Then of course, accessibility, having access to the code and all the features
[02:34.960 --> 02:41.120]  may allow us to further extend it or contribute to it and implement other features. And finally,
[02:41.120 --> 02:48.960]  from a values or ethical point of view, when we are using open source, we kind of facilitate
[02:48.960 --> 02:56.640]  integration and technological growth for everyone, rather than focusing on products and standards
[02:56.640 --> 03:04.800]  that just have a small benefit or a benefit for one company. Okay, so with all these good reasons
[03:04.800 --> 03:12.240]  I hope in mind, I'm going to talk about how to approach migration. So in general, as a plan,
[03:12.240 --> 03:19.280]  I hope that's okay. So in general, as a plan, when we migrate from one knowledge management tool to
[03:19.280 --> 03:24.960]  another, but this can be kind of extended to other software as well, we first need to think
[03:24.960 --> 03:29.920]  about data format and dependencies. What type of data do we have? Do we have flat HTML pages? Do we
[03:29.920 --> 03:35.360]  have structured pages? Do we have any metadata tags? All that needs to be considered. Then we
[03:35.360 --> 03:40.400]  also need to look at the other extensions that we're using. What type of authentication do we have?
[03:40.400 --> 03:47.600]  Are we integrating with anything else that needs to be kept? Then once we have that listed, based
[03:47.600 --> 03:54.240]  on that, we can identify and set up the new software. For example, let's say that we have identified
[03:54.240 --> 04:02.800]  that on the confidence side, we can export to XML. Xfiki supports that and we want to do this
[04:02.800 --> 04:09.200]  migration. We need to set up the new software in the environment that works for us. Then we need
[04:09.200 --> 04:14.480]  to make the migration plan and clean up. This is of course quite specific to the software that you
[04:14.480 --> 04:20.560]  that you're migrating to and from. But in general, it's also interesting to know that it can be a
[04:20.560 --> 04:24.880]  good moment to clean up your data. For example, if you have a system that you have been using for
[04:24.880 --> 04:31.120]  10 years, you may have a lot of obsolete data that can be cleaned up at this moment. Aside from the
[04:31.680 --> 04:39.120]  plan of migrating, you can also eliminate some pages or even reorganize the content if possible.
[04:40.000 --> 04:45.440]  Then of course, we need to execute the migration. Again, it depends on each organization or company
[04:45.440 --> 04:53.600]  if they executed with a team, if they executed with other services. But this is an important step
[04:53.600 --> 05:00.880]  that also needs to be planned and kind of realistically planned in time as well to say so.
[05:02.800 --> 05:08.320]  When we migrate itself, we also need to try to map the data and its structure. As I said
[05:08.320 --> 05:13.600]  previously, if you have some type of structured data, you will want to map that. Also, you will
[05:13.600 --> 05:23.840]  want to create the new integrations or dependencies or install them. Then finally, once that is done,
[05:23.840 --> 05:29.680]  we need to do a thorough testing of course before releasing the new system. Finally,
[05:29.680 --> 05:34.800]  delivering in production and a step that is quite commonly skipped would be the user training.
[05:35.680 --> 05:39.840]  If you have any sort of organization, you may have been in the situation where
[05:39.840 --> 05:45.040]  you had to change the software and people may have been resistant to using the new software or
[05:46.480 --> 05:52.880]  became a bit less efficient or didn't really know how to handle certain aspects. A bit of user
[05:52.880 --> 05:59.280]  training can be very helpful as well if you're changing your knowledge management tools.
[06:00.800 --> 06:07.120]  Now we know the general plan and we can see two examples in action. For the conference
[06:07.120 --> 06:14.720]  to xWiki migration, I'm going to demonstrate the XML export way. For the share point,
[06:14.720 --> 06:32.640]  we're going to see an example of CSV export. On the migration from conference to xWiki,
[06:32.640 --> 06:41.520]  we already had a lot of tools available to migrate. However, in recent years, we
[06:41.520 --> 06:48.240]  dedicated a bit more efforts to trying to make them as easy to use as possible. We had before
[06:48.240 --> 06:54.960]  the filter streams converter that also supported the conference format. Nowadays, we have an
[06:54.960 --> 07:03.680]  integrated migrator that has a couple of steps. We'll see them right away. For the macros,
[07:05.040 --> 07:13.680]  in conference, we have some macros like we have in other wiki systems or knowledge management
[07:13.680 --> 07:22.880]  tools. One concern while migrating were the macros that had to be supported or migrated
[07:22.880 --> 07:29.440]  properly. Because of that, we also developed a package of bridge macros, how we call them,
[07:29.440 --> 07:36.720]  or macros that were identical to what exists in conference and that would support migration.
[07:36.720 --> 07:42.400]  Of course, we don't have all the macros that exist in conference because both xWiki and
[07:42.400 --> 07:47.040]  conference are products that have been around for a really long time and they have their own
[07:47.040 --> 07:55.280]  specificities. That is a concern to keep in mind not only when migrating from conference to xWiki,
[07:55.280 --> 08:00.880]  but from any software. Again, this fits into the dependencies or applications that you're using
[08:01.440 --> 08:08.480]  part. Let's see how a migration works. Again, I'm going to use the integrated one,
[08:09.600 --> 08:16.400]  the integrated migrator, which reuses the original filter streams. What we did for
[08:16.400 --> 08:23.120]  this migrator itself, to make it, again, a bit nicer to use, we created this concept of a profile
[08:23.920 --> 08:30.320]  in which you can basically import each space separately and you'll have a bit of an analysis
[08:30.320 --> 08:37.040]  on what pages were imported, if you had any pages that caused issues and you're able to follow the
[08:37.040 --> 08:44.000]  process a bit better. You can name your profile however you want. If you want, you can also connect
[08:44.000 --> 08:50.320]  to the conference instance. This is not mandatory, but if you connect to the conference instance,
[08:50.320 --> 08:56.400]  it also gives you a pre-analysis of the pages that were already imported into xWiki, so that
[08:57.120 --> 09:03.440]  can be useful. If you're having conference cloud, your username and token would be
[09:04.080 --> 09:10.160]  username and the token that you get, the API token. If you're running conference server,
[09:10.160 --> 09:16.080]  the username would be your administrator username and the token will be your password.
[09:17.120 --> 09:24.240]  We have here, of course, a demo purpose conference instance. It's not what we use internally.
[09:24.240 --> 09:44.080]  Then we need to put the URL as well in order to map the URL schema. Let's take that as well.
[09:44.080 --> 09:54.240]  We don't have a custom URL path. This is important again for the URL schema and for
[09:54.240 --> 10:00.800]  their adaptation. If you have wiki in the path, that will be a standard URL. If you don't,
[10:00.800 --> 10:04.560]  if you have things like display or something else, that would be a custom URL. In this case,
[10:04.560 --> 10:10.320]  it's not applied. Then we need to mention the name, the key of the space that we're migrating.
[10:10.320 --> 10:18.640]  In this case, I made this dummy text demo space called FOS. This is the space that I want to
[10:18.640 --> 10:26.880]  import. Now I have my profile. Let's see if I'm connected. Yes, I can start the migration.
[10:29.040 --> 10:33.760]  The way in which the migration works is that you have a couple of steps. The first one is just
[10:33.760 --> 10:41.360]  the prerequisites. It would tell you what would be the requirements for migration. They usually
[10:41.360 --> 10:47.680]  apply for larger imports. In our case, we're just going to do a 7-megabyte zip. It's not
[10:47.680 --> 10:52.160]  that large. We don't need to adapt everything. Of course, in general, when you're running a
[10:52.160 --> 10:59.120]  migration, you need to have enough resources on the machine, enough memory, disk space and all that.
[10:59.120 --> 11:06.080]  Specifically, on the Xfiki side, you can also disable notifications in the Xfiki properties
[11:06.080 --> 11:12.160]  file. You can also disable some listeners if you know that you will be importing very large
[11:13.200 --> 11:20.880]  packages. The second step that I told you about previously with that analysis, if you are connected
[11:20.880 --> 11:28.720]  to the conference instance, you can see if you have on Xfiki any pages that already exist,
[11:28.720 --> 11:33.360]  so that if you have in the package that you're trying to import from conference pages that exist
[11:33.360 --> 11:41.040]  on Xfiki. We have some logs here. We can see that it looked at all the pages. We don't have
[11:41.040 --> 11:48.480]  on Xfiki pages that we're trying to import right now. In the third step, it's just to
[11:48.480 --> 11:54.720]  tell you to go to conference and export. It depends on what server version or conference
[11:54.720 --> 12:03.520]  or cloud version you have. In this case, it's a cloud version with XML, full or custom export.
[12:04.640 --> 12:09.120]  You can choose again between those two. I already have it downloaded, so I'm not going to download
[12:09.120 --> 12:21.200]  it again. At this step, you just have to import your export file. Let me show you the example to
[12:21.200 --> 12:38.000]  import. If you have it on the same server, you can also specify the source in the server.
[12:38.000 --> 12:43.040]  If you have Xfiki running on the same server that you have the files in, you can also specify it
[12:43.040 --> 12:48.960]  directly. All of this configuration is the filter streams configuration that you can adapt.
[12:48.960 --> 12:57.760]  It has some fields that are prefilled, but there's also a lot of power in other things that you can
[12:57.760 --> 13:04.240]  configure. For example, you can also import users. You can do user ID mapping. For example,
[13:04.240 --> 13:09.520]  if you have an LDAP that has generated on the conference site some random number IDs,
[13:10.400 --> 13:16.400]  and you want to map those to the new users that you have created on Xfiki, that's something you
[13:16.400 --> 13:23.280]  can do. Also, you can choose if you want to keep the author and history metadata and so on.
[13:24.560 --> 13:29.920]  You have some nice configuration that is quite granular. Once the configuration is done,
[13:30.560 --> 13:36.640]  you would import. This is the point where our documents are getting created.
[13:38.560 --> 13:43.360]  Because they configured it, we also have the history. For example, here you see this was
[13:43.360 --> 13:50.400]  created and then updated because on the conference side, I had multiple changes on those pages.
[13:51.360 --> 14:03.200]  Now, we see that we have the pages imported with no error. With no error, it's of course a great
[14:03.200 --> 14:10.320]  thing, but you can also have errors, of course. In our experience, the most common errors are caused
[14:10.320 --> 14:17.920]  by unsupported characters or corrupted pages on the conference side. If you are trying this out
[14:17.920 --> 14:23.440]  and you have some errors, the logs should tell you what is the page that is causing the issue.
[14:25.120 --> 14:30.000]  You can then fix it on the conference side and then re-import or fix it manually in Xfiki,
[14:30.880 --> 14:38.000]  whatever suits you best. Now, we have the pages imported. This is a post-import
[14:38.000 --> 14:43.680]  fixes check that we can also perform in case we have pages that were imported that don't have
[14:44.880 --> 14:50.480]  a parent or pages that have corrupted parents. Both in Confluence and Xfiki,
[14:50.480 --> 14:53.920]  we have the hierarchy system. In Xfiki, we have nest pages.
[14:55.840 --> 15:02.720]  In Confluence, you may have situations where the parent pages are corrupted. If you would have had
[15:02.720 --> 15:09.680]  that, you would see it in these reports. It's not the case here. Finally, we would need to
[15:09.680 --> 15:14.720]  recreate the hierarchy that we had in Confluence. You can see now that the pages that I have
[15:14.720 --> 15:24.400]  imported are flat. We have just one level hierarchy here. Now, I'm going to execute the nested pages
[15:24.400 --> 15:33.120]  migration tool that we also have at Xfiki. The pages will be moved into their parents
[15:33.760 --> 15:37.520]  according to the hierarchy that they had in Confluence. As you see, it's converting all the
[15:37.520 --> 15:46.480]  pages and they will be moved in the right place. Okay, cool. Now, we have a migration done. You
[15:46.480 --> 15:54.560]  can look at the pages to see all of your content. You also have, again, a lot of the macros that
[15:55.920 --> 16:04.000]  are also installed and can be reused. For the macros, the pro macros that I told you about,
[16:04.000 --> 16:11.920]  the bridge macros on our side are packaged. They are open source. They are public here,
[16:11.920 --> 16:20.240]  if you want to check them out or repackage them. On our side, they are packaged as under a license
[16:20.240 --> 16:28.080]  to be able to further support the development of the product. If you want to check them out
[16:28.080 --> 16:37.040]  or contribute to them, you can see them on our Git. We have here a Confluence migration done
[16:37.040 --> 16:45.440]  very quickly and without much hassle. We saw the Confluence migration. Now, let's see the SharePoint
[16:45.440 --> 16:53.360]  one. The way in which we migrate from Confluence is based on the XML export. From SharePoint,
[16:53.360 --> 17:02.320]  it's very different. In SharePoint, you have the option to export to CSV. If you're using
[17:02.320 --> 17:07.200]  SharePoint as a knowledge management tools and you have your documents with a bit of metadata,
[17:07.200 --> 17:13.280]  so like we have in this case, department could be considered a metadata or a structure data
[17:13.280 --> 17:21.680]  of field that you can check or uncheck and change. The pages have a form structure.
[17:22.880 --> 17:29.680]  If you have this type of data, one thing that you can do is to export to CSV, then create the same
[17:29.680 --> 17:36.400]  data structure on Xwiki. On Xwiki, we have an application that is called App Within Minutes
[17:36.400 --> 17:43.520]  that allows you to create structured data systems. Here, I already have an example made,
[17:43.520 --> 17:48.800]  but we can look at the structure. Basically, I just created the same structure that I had
[17:48.800 --> 18:00.000]  in the SharePoint example, so title, department, reviewed, and finally the content of my documents.
[18:00.000 --> 18:08.400]  Then, once I have that structure done, I can use the batch import application. Sorry, not here.
[18:08.400 --> 18:21.760]  Okay. With the batch import application, I would import the CSV that I have just
[18:22.640 --> 18:29.920]  got from SharePoint. I'm able to map the columns from the CSV to fields in Xwiki
[18:29.920 --> 18:36.080]  that I have just created. Here is the mapping that I just did before. You can choose whatever you
[18:36.080 --> 18:42.080]  want, even exclude some columns if it's the case. Then, we preview the mapping,
[18:43.280 --> 18:49.120]  and this is what they would look like on the Xwiki side. You can see that all the content
[18:50.960 --> 18:59.200]  is getting migrated. Let's just see a page. Here, you can say what you want to happen if you
[18:59.200 --> 19:08.000]  have duplicates. Then, we do the import, and the final result is something like this. All
[19:08.000 --> 19:15.120]  the pages were imported, and if you go to a page, you can see that you have this structured form
[19:15.120 --> 19:23.360]  type, and you can further edit it. Okay. That's all for the two examples. Sorry, I had to go through
[19:23.360 --> 19:29.840]  them very quickly. There are a lot of things that you can do to migrate, and of course,
[19:29.840 --> 19:37.040]  we're very happy to facilitate any migration from any other preparatory tool to get more
[19:37.040 --> 19:50.720]  users to open source. Thank you if you have any question. No questions? That clear? Yes.
[19:50.720 --> 19:52.720]  Yes, please.
[19:52.720 --> 19:59.200]  How would you deal with migration from basically just the directory with all its office documents?
[20:00.640 --> 20:04.560]  So, how do we deal with migration from the directory of all the office documents?
[20:10.080 --> 20:16.320]  So, two things that we can do. So, when you import office documents into Xwiki,
[20:16.320 --> 20:22.800]  we do have abundant integration with LibreOffice that allows you to convert office pages into
[20:22.800 --> 20:29.200]  Xwiki pages, but that's page by page. Or, if you have any sort of directory of office files, what
[20:29.200 --> 20:35.520]  you can do is to actually create manually this type of a CSV where you put in a row the content,
[20:35.520 --> 20:40.480]  and in this way, you can also add some metadata, for example, if you want to organize them in some
[20:40.480 --> 20:46.560]  departments or responsible person, so on. You can do that and then still use the batch import.
[20:46.560 --> 20:52.480]  At the moment, we don't have an existing tool for just feeding some files. We have something in
[20:52.480 --> 20:59.760]  progress also with batch import, but yeah, the one option is to either convert them one by one
[20:59.760 --> 21:05.840]  or use the batch import, but you would still need to organize them in a sort of a list.
[21:05.840 --> 21:10.480]  Yeah, that answers it. Yes, please.
[21:36.160 --> 21:58.480]  Thank you for the question. Just to repeat it, if it's the case, the question is if we can,
[22:00.000 --> 22:04.640]  if we facilitate in any way the addition of metadata or the cleanup, I would assume.
[22:04.640 --> 22:13.840]  So, on the metadata, as just mentioned now, for the office part, if you have office documents
[22:13.840 --> 22:20.960]  in any way, you can adapt that CSV file before migrating. So, for example, if you have office
[22:20.960 --> 22:29.760]  files or if you have an export from SharePoint, but it's not all documents have metadata,
[22:29.760 --> 22:34.640]  you can add them manually in the CSV that you do. On the conference side,
[22:35.680 --> 22:42.480]  not that much. You can, of course, so the labels and everything are imported,
[22:42.480 --> 22:48.240]  but to be straight here, it depends more on what you have on conference, because basically,
[22:48.240 --> 22:52.960]  with the migration from conference, we just take everything that you have and put it into Xfiki.
[22:52.960 --> 23:00.480]  We don't really facilitate any cleanup, but we allow you to migrate labels and macros that also
[23:00.480 --> 23:07.840]  do reports and all that. But for conference, specifically, it's a bit difficult to add metadata.
[23:07.840 --> 23:15.120]  Do you also migrate pages and lists? Sorry? For SharePoint, do you also migrate pages and lists
[23:15.120 --> 23:20.560]  so it will be not only documents? From SharePoint, at the moment, we migrate documents,
[23:20.560 --> 23:26.880]  so Word documents. There are other tools that we're working on with office integrations and
[23:27.520 --> 23:35.360]  Microsoft integration, but yeah, at the moment, we only import documents. Thank you.
[23:35.360 --> 23:42.960]  Maybe you told it, what about the user's permission right to view part of the document?
[23:44.640 --> 23:51.120]  Thank you. That's a really good question. The question is for user rights or permissions.
[23:51.920 --> 23:58.240]  That's in the part of the dependencies or integrations that we need to mind.
[23:59.280 --> 24:04.960]  At Xfiki, if you migrate from conference, for example, and you have native conference users,
[24:04.960 --> 24:09.520]  yes, we have the option to import them. You just need to configure that in the
[24:09.520 --> 24:15.200]  filter streams, and you can import the users, but not the permissions. The issue with the
[24:15.200 --> 24:19.840]  permissions is that the systems are very different. In conference, you have a very different
[24:20.480 --> 24:26.000]  system of access permissions compared to Xfiki. You can do that custom, like if you do a script
[24:26.000 --> 24:31.120]  that maps the rights and tries to set up some rights, we can imagine that, but at the moment,
[24:31.120 --> 24:36.640]  it's not possible. It's very difficult to do it generically. The alternative or the best case
[24:36.640 --> 24:42.000]  scenario is if you have something like an LDAP or even an SSO system that you have connected to
[24:42.000 --> 24:48.080]  your current tool, and when you migrate, you connect that same user directory to the new tool,
[24:48.080 --> 24:52.480]  such as Xfiki, and you just have the users created at the first login.
[24:53.520 --> 24:58.560]  That's, of course, the best case scenario. It's also actually possible to migrate users
[24:58.560 --> 25:03.440]  with the batch import, so you can do a bit of a hack there and import users as well,
[25:03.440 --> 25:08.480]  but for permissions, it's generally very complicated, and it's a case-by-case situation.
[25:08.480 --> 25:14.400]  You can import permissions, you can import groups from LDAP. We're also working on importing groups
[25:14.400 --> 25:22.720]  from as your SSO, but permissions, it's not yet generic enough done in our extensions.
[25:22.720 --> 25:28.720]  Yes?
[25:35.920 --> 25:42.160]  So thank you. Also a great question. If the history of additions is kept for the
[25:42.160 --> 25:48.560]  conference migration, yes, or for the XML migrations in general, yes. We do have that,
[25:48.560 --> 25:56.240]  and you can also see in our example here, I'm not sure if this one has enough history, but
[25:56.240 --> 26:02.880]  yeah, okay, so just a quick example, the history is retained, again, if you configure the filter to
[26:02.880 --> 26:07.840]  do so, and if you have this history retained, you can also see the changes between the versions,
[26:08.560 --> 26:15.200]  so that's something very nice. For SharePoint, we don't have that at the moment because we're not
[26:15.200 --> 26:23.280]  taking gold metadata from the documents, and also on other tools that support this type of
[26:23.280 --> 26:45.920]  filter streams migration, you may also get the history. Okay, thank you very much. Thanks.