about migrating from proprietary to open source knowledge management tools. I'll talk a bit
in general about the migration process and then demonstrate two migrations, one from
conference and one from SharePoint with different technologies just to see what's possible on
our side and in general. So first, why migrate from proprietary to open source? I'm sure
everyone has a lot of good reasons for that in mind but some that we have identified as well
would be first for privacy and security concerns. Of course, with open source software, you have
more flexibility in where you host your data, how you host it, the environment and access that
you set up. Two other concerns that are related and we have also seen some important examples in
the recent years are vendor and data lock-in. So when you're using a proprietary software, you're
a bit more vulnerable to the vendor than when you're using an open source software in the sense
that if they make any significant strategy or pricing changes, you may find yourself in a
situation where you need to migrate quickly or you need to quickly adjust to that change. A
recent example is Confluence. Maybe some of you have stumbled across it. They had a cloud version
and a server version and a data center but that's usually for larger teams. The server version was
used by smaller teams that wanted to host the data on their premise and in late 2020, Confluence
decided to stop the server version. So because of that, a lot of small companies had to either
move to cloud, so host their data in the states, which wasn't possible for a lot of people,
or move to data center, which was much more expensive and difficult to handle. And that was
an example of how using proprietary software can make you quite vulnerable to their changes.
One other thing that is important is the data lock-in. So using open source software usually
allows you to migrate easier and integrate with certain tools due to open standards and protocols
and formats. So if you're using an open source tool at some point and then you want to migrate to
another, it may be easier than migrating from proprietary tools to other proprietary tools
or open source ones. Then of course, accessibility, having access to the code and all the features
may allow us to further extend it or contribute to it and implement other features. And finally,
from a values or ethical point of view, when we are using open source, we kind of facilitate
integration and technological growth for everyone, rather than focusing on products and standards
that just have a small benefit or a benefit for one company. Okay, so with all these good reasons
I hope in mind, I'm going to talk about how to approach migration. So in general, as a plan,
I hope that's okay. So in general, as a plan, when we migrate from one knowledge management tool to
another, but this can be kind of extended to other software as well, we first need to think
about data format and dependencies. What type of data do we have? Do we have flat HTML pages? Do we
have structured pages? Do we have any metadata tags? All that needs to be considered. Then we
also need to look at the other extensions that we're using. What type of authentication do we have?
Are we integrating with anything else that needs to be kept? Then once we have that listed, based
on that, we can identify and set up the new software. For example, let's say that we have identified
that on the confidence side, we can export to XML. Xfiki supports that and we want to do this
migration. We need to set up the new software in the environment that works for us. Then we need
to make the migration plan and clean up. This is of course quite specific to the software that you
that you're migrating to and from. But in general, it's also interesting to know that it can be a
good moment to clean up your data. For example, if you have a system that you have been using for
10 years, you may have a lot of obsolete data that can be cleaned up at this moment. Aside from the
plan of migrating, you can also eliminate some pages or even reorganize the content if possible.
Then of course, we need to execute the migration. Again, it depends on each organization or company
if they executed with a team, if they executed with other services. But this is an important step
that also needs to be planned and kind of realistically planned in time as well to say so.
When we migrate itself, we also need to try to map the data and its structure. As I said
previously, if you have some type of structured data, you will want to map that. Also, you will
want to create the new integrations or dependencies or install them. Then finally, once that is done,
we need to do a thorough testing of course before releasing the new system. Finally,
delivering in production and a step that is quite commonly skipped would be the user training.
If you have any sort of organization, you may have been in the situation where
you had to change the software and people may have been resistant to using the new software or
became a bit less efficient or didn't really know how to handle certain aspects. A bit of user
training can be very helpful as well if you're changing your knowledge management tools.
Now we know the general plan and we can see two examples in action. For the conference
to xWiki migration, I'm going to demonstrate the XML export way. For the share point,
we're going to see an example of CSV export. On the migration from conference to xWiki,
we already had a lot of tools available to migrate. However, in recent years, we
dedicated a bit more efforts to trying to make them as easy to use as possible. We had before
the filter streams converter that also supported the conference format. Nowadays, we have an
integrated migrator that has a couple of steps. We'll see them right away. For the macros,
in conference, we have some macros like we have in other wiki systems or knowledge management
tools. One concern while migrating were the macros that had to be supported or migrated
properly. Because of that, we also developed a package of bridge macros, how we call them,
or macros that were identical to what exists in conference and that would support migration.
Of course, we don't have all the macros that exist in conference because both xWiki and
conference are products that have been around for a really long time and they have their own
specificities. That is a concern to keep in mind not only when migrating from conference to xWiki,
but from any software. Again, this fits into the dependencies or applications that you're using
part. Let's see how a migration works. Again, I'm going to use the integrated one,
the integrated migrator, which reuses the original filter streams. What we did for
this migrator itself, to make it, again, a bit nicer to use, we created this concept of a profile
in which you can basically import each space separately and you'll have a bit of an analysis
on what pages were imported, if you had any pages that caused issues and you're able to follow the
process a bit better. You can name your profile however you want. If you want, you can also connect
to the conference instance. This is not mandatory, but if you connect to the conference instance,
it also gives you a pre-analysis of the pages that were already imported into xWiki, so that
can be useful. If you're having conference cloud, your username and token would be
username and the token that you get, the API token. If you're running conference server,
the username would be your administrator username and the token will be your password.
We have here, of course, a demo purpose conference instance. It's not what we use internally.
Then we need to put the URL as well in order to map the URL schema. Let's take that as well.
We don't have a custom URL path. This is important again for the URL schema and for
their adaptation. If you have wiki in the path, that will be a standard URL. If you don't,
if you have things like display or something else, that would be a custom URL. In this case,
it's not applied. Then we need to mention the name, the key of the space that we're migrating.
In this case, I made this dummy text demo space called FOS. This is the space that I want to
import. Now I have my profile. Let's see if I'm connected. Yes, I can start the migration.
The way in which the migration works is that you have a couple of steps. The first one is just
the prerequisites. It would tell you what would be the requirements for migration. They usually
apply for larger imports. In our case, we're just going to do a 7-megabyte zip. It's not
that large. We don't need to adapt everything. Of course, in general, when you're running a
migration, you need to have enough resources on the machine, enough memory, disk space and all that.
Specifically, on the Xfiki side, you can also disable notifications in the Xfiki properties
file. You can also disable some listeners if you know that you will be importing very large
packages. The second step that I told you about previously with that analysis, if you are connected
to the conference instance, you can see if you have on Xfiki any pages that already exist,
so that if you have in the package that you're trying to import from conference pages that exist
on Xfiki. We have some logs here. We can see that it looked at all the pages. We don't have
on Xfiki pages that we're trying to import right now. In the third step, it's just to
tell you to go to conference and export. It depends on what server version or conference
or cloud version you have. In this case, it's a cloud version with XML, full or custom export.
You can choose again between those two. I already have it downloaded, so I'm not going to download
it again. At this step, you just have to import your export file. Let me show you the example to
import. If you have it on the same server, you can also specify the source in the server.
If you have Xfiki running on the same server that you have the files in, you can also specify it
directly. All of this configuration is the filter streams configuration that you can adapt.
It has some fields that are prefilled, but there's also a lot of power in other things that you can
configure. For example, you can also import users. You can do user ID mapping. For example,
if you have an LDAP that has generated on the conference site some random number IDs,
and you want to map those to the new users that you have created on Xfiki, that's something you
can do. Also, you can choose if you want to keep the author and history metadata and so on.
You have some nice configuration that is quite granular. Once the configuration is done,
you would import. This is the point where our documents are getting created.
Because they configured it, we also have the history. For example, here you see this was
created and then updated because on the conference side, I had multiple changes on those pages.
Now, we see that we have the pages imported with no error. With no error, it's of course a great
thing, but you can also have errors, of course. In our experience, the most common errors are caused
by unsupported characters or corrupted pages on the conference side. If you are trying this out
and you have some errors, the logs should tell you what is the page that is causing the issue.
You can then fix it on the conference side and then re-import or fix it manually in Xfiki,
whatever suits you best. Now, we have the pages imported. This is a post-import
fixes check that we can also perform in case we have pages that were imported that don't have
a parent or pages that have corrupted parents. Both in Confluence and Xfiki,
we have the hierarchy system. In Xfiki, we have nest pages.
In Confluence, you may have situations where the parent pages are corrupted. If you would have had
that, you would see it in these reports. It's not the case here. Finally, we would need to
recreate the hierarchy that we had in Confluence. You can see now that the pages that I have
imported are flat. We have just one level hierarchy here. Now, I'm going to execute the nested pages
migration tool that we also have at Xfiki. The pages will be moved into their parents
according to the hierarchy that they had in Confluence. As you see, it's converting all the
pages and they will be moved in the right place. Okay, cool. Now, we have a migration done. You
can look at the pages to see all of your content. You also have, again, a lot of the macros that
are also installed and can be reused. For the macros, the pro macros that I told you about,
the bridge macros on our side are packaged. They are open source. They are public here,
if you want to check them out or repackage them. On our side, they are packaged as under a license
to be able to further support the development of the product. If you want to check them out
or contribute to them, you can see them on our Git. We have here a Confluence migration done
very quickly and without much hassle. We saw the Confluence migration. Now, let's see the SharePoint
one. The way in which we migrate from Confluence is based on the XML export. From SharePoint,
it's very different. In SharePoint, you have the option to export to CSV. If you're using
SharePoint as a knowledge management tools and you have your documents with a bit of metadata,
so like we have in this case, department could be considered a metadata or a structure data
of field that you can check or uncheck and change. The pages have a form structure.
If you have this type of data, one thing that you can do is to export to CSV, then create the same
data structure on Xwiki. On Xwiki, we have an application that is called App Within Minutes
that allows you to create structured data systems. Here, I already have an example made,
but we can look at the structure. Basically, I just created the same structure that I had
in the SharePoint example, so title, department, reviewed, and finally the content of my documents.
Then, once I have that structure done, I can use the batch import application. Sorry, not here.
Okay. With the batch import application, I would import the CSV that I have just
got from SharePoint. I'm able to map the columns from the CSV to fields in Xwiki
that I have just created. Here is the mapping that I just did before. You can choose whatever you
want, even exclude some columns if it's the case. Then, we preview the mapping,
and this is what they would look like on the Xwiki side. You can see that all the content
is getting migrated. Let's just see a page. Here, you can say what you want to happen if you
have duplicates. Then, we do the import, and the final result is something like this. All
the pages were imported, and if you go to a page, you can see that you have this structured form
type, and you can further edit it. Okay. That's all for the two examples. Sorry, I had to go through
them very quickly. There are a lot of things that you can do to migrate, and of course,
we're very happy to facilitate any migration from any other preparatory tool to get more
users to open source. Thank you if you have any question. No questions? That clear? Yes.
Yes, please.
How would you deal with migration from basically just the directory with all its office documents?
So, how do we deal with migration from the directory of all the office documents?
So, two things that we can do. So, when you import office documents into Xwiki,
we do have abundant integration with LibreOffice that allows you to convert office pages into
Xwiki pages, but that's page by page. Or, if you have any sort of directory of office files, what
you can do is to actually create manually this type of a CSV where you put in a row the content,
and in this way, you can also add some metadata, for example, if you want to organize them in some
departments or responsible person, so on. You can do that and then still use the batch import.
At the moment, we don't have an existing tool for just feeding some files. We have something in
progress also with batch import, but yeah, the one option is to either convert them one by one
or use the batch import, but you would still need to organize them in a sort of a list.
Yeah, that answers it. Yes, please.
Thank you for the question. Just to repeat it, if it's the case, the question is if we can,
if we facilitate in any way the addition of metadata or the cleanup, I would assume.
So, on the metadata, as just mentioned now, for the office part, if you have office documents
in any way, you can adapt that CSV file before migrating. So, for example, if you have office
files or if you have an export from SharePoint, but it's not all documents have metadata,
you can add them manually in the CSV that you do. On the conference side,
not that much. You can, of course, so the labels and everything are imported,
but to be straight here, it depends more on what you have on conference, because basically,
with the migration from conference, we just take everything that you have and put it into Xfiki.
We don't really facilitate any cleanup, but we allow you to migrate labels and macros that also
do reports and all that. But for conference, specifically, it's a bit difficult to add metadata.
Do you also migrate pages and lists? Sorry? For SharePoint, do you also migrate pages and lists
so it will be not only documents? From SharePoint, at the moment, we migrate documents,
so Word documents. There are other tools that we're working on with office integrations and
Microsoft integration, but yeah, at the moment, we only import documents. Thank you.
Maybe you told it, what about the user's permission right to view part of the document?
Thank you. That's a really good question. The question is for user rights or permissions.
That's in the part of the dependencies or integrations that we need to mind.
At Xfiki, if you migrate from conference, for example, and you have native conference users,
yes, we have the option to import them. You just need to configure that in the
filter streams, and you can import the users, but not the permissions. The issue with the
permissions is that the systems are very different. In conference, you have a very different
system of access permissions compared to Xfiki. You can do that custom, like if you do a script
that maps the rights and tries to set up some rights, we can imagine that, but at the moment,
it's not possible. It's very difficult to do it generically. The alternative or the best case
scenario is if you have something like an LDAP or even an SSO system that you have connected to
your current tool, and when you migrate, you connect that same user directory to the new tool,
such as Xfiki, and you just have the users created at the first login.
That's, of course, the best case scenario. It's also actually possible to migrate users
with the batch import, so you can do a bit of a hack there and import users as well,
but for permissions, it's generally very complicated, and it's a case-by-case situation.
You can import permissions, you can import groups from LDAP. We're also working on importing groups
from as your SSO, but permissions, it's not yet generic enough done in our extensions.
Yes?
So thank you. Also a great question. If the history of additions is kept for the
conference migration, yes, or for the XML migrations in general, yes. We do have that,
and you can also see in our example here, I'm not sure if this one has enough history, but
yeah, okay, so just a quick example, the history is retained, again, if you configure the filter to
do so, and if you have this history retained, you can also see the changes between the versions,
so that's something very nice. For SharePoint, we don't have that at the moment because we're not
taking gold metadata from the documents, and also on other tools that support this type of
filter streams migration, you may also get the history. Okay, thank you very much. Thanks.