WikiTraccs FAQ
This FAQ covers questions folks have while evaluating and using WikiTraccs.
The answers are often short on purpose and nuance might be lost this way. Please refer to the documentation links for an in-depth discussion of the respective topics.
Q: What is the access level needed in SharePoint to migrate spaces to? Same question for Confluence.
A: For Confluence creating a migration account is recommended. The following access levels work for this account: Confluence administrator (recommended), space owner, read-only user. Lesser access means that page restrictions and/or user account information (email address, name) cannot be migrated.
For SharePoint creating a migration account is also recommended. This account should be site collection administrator of SharePoint target sites. Furthermore an Entra ID app registration is required. The app needs delegated permissions, ideally FullControl, but Manage works to an extend. Refer to the linked documentation for details.
Further reading:
- More about Confluence permissions here: Authenticating with Confluence
- More about SharePoint permissions here: Authenticating with SharePoint Online
- Step-by-step instructions for creating Entra ID app registration: Registering WikiTraccs as app in Entra ID
Q: What if we don’t have access to a global admin account of SharePoint?
A: You probably don’t need a SharePoint global admin. Here’s what’s needed when preparing the migration:
- in SharePoint Online, create modern sites and assign the migration account permissions - if self-service site creation is enabled then any user can do this
- in Entra ID, register an Entra ID application - this can be done by an account with Application Developer role in Entra ID, but see the linked Microsoft documentation for more details; this has to be done once as prerequisite to using WikiTraccs
- only if a new migration account is to be used for SharePoint: in the Microsoft 365 administration, create a migration account - this needs the User Administrator admin role
- only for WikiPakk: in SharePoint Online, add the WikiPakk app from Microsoft AppSource to the global tenant app catalog - the user doing this needs to be Owner of the tenant app catalog site, although it more commonly is the SharePoint administrator
Further reading:
- More on who can create and configure Entra ID applications: Delegate app registration permissions in Entra ID
- Step-by-step instructions for registering the application in Entra ID: Registering WikiTraccs as app in Entra ID
- More about the permissions of the Entra ID application here: Authenticating with SharePoint Online
Q: Will the links between Confluence pages work properly when migrated to SharePoint?
A: Yes, mostly. When a Confluence page is migrated to SharePoint, links to other Confluence pages, spaces, and attachments are transformed to point to the respective SharePoint pages. This is true for soft links, that means “proper” Confluence links. See the next question about hard links and why it’s harder for WikiTraccs to handle those.
Link transformation is done based on a naming scheme WikiTraccs uses for SharePoint page names, thus the target page doesn’t need to exist, yet. You can migrate Confluence page Foo that links to Confluence page Bar, without having to migrate Bar. The link will be transformed and points to a (yet) non-existing SharePoint page Bar - until you migrate page Bar. Then the link works.
Note about versioning: the link will always point to the current page version in SharePoint since WikiTraccs only migrates the current page version.
Further reading:
- Details about hard link handling: WikiTraccs 1.6.4 Release Notes
- Feature description: Features -> Links specific to Confluence
- For cross-space links to work the space to site mapping has to be configured in the Space Inventory: Cross-space links and target sites
Q: What is a Hard Link for WikiTraccs? And why is it hard for WikiTraccs to migrate hard links?
A: Hard links are plain old HTML links that Confluence is oblivious of, from a metadata standpoint. Technically, hard links appear like any other text content on a Confluence page. And also technically, they lack important metadata that is needed to locate the target page - a page ID, page title or space key. Sometimes those links make it into a Confluence page, mostly by pasting text into a page. As long as the target Confluence page does not change much those links work. But upon renaming the target page those links might break.
To transform a Confluence link to a SharePoint link WikiTraccs needs to know which Confluence page or space a link points to. As the needed metadata is only present with soft links and missing for hard links, WikiTraccs might not be able to transform hard links.
Since release 1.6.4 WikiTraccs has basic hard link support. WikiTraccs looks for hard links and tries to figure out the target page. If that is successful the hard link is transformed to a proper page link in SharePoint. But this might not always succeed. And this does not work for hard links to attachments.
Further reading:
- Details about hard link handling: WikiTraccs 1.6.4 Release Notes
- Feature description: Features -> Links specific to Confluence
Q: How do you know which spaces and pages can/can’t be migrated from Confluence?
Q: Can I choose which space I want to migrate so I can migrate batches of spaces?
Q: What granularity does the selection of migrating give us? Space-by-Space? Page-by-Page?
A: Migration with WikiTraccs is done on a per-space basis. You choose Confluence spaces to migrate, and which target SharePoint site to use as migration target. All pages from the source space will be migrated to the chosen target.
Technically, there is no restriction as to which Confluence spaces can be migrated. Everything the Confluence migration account sees will be seen, and can be migrated by WikiTraccs.
You choose which spaces to migrate in the Space Inventory, a list that WikiTraccs creates in SharePoint. WikiTraccs stores basic information about each space it finds in Confluence in this list. You then tick a box for all spaces that should be migrated. When starting the migration, WikiTraccs looks at this list to know what to migrate, and to which sites.
Migrating spaces in batches can be done by adjusting the space selection in the Space Inventory: select spaces for a batch, then migrate; for the next batches, adjust the space selection accordingly.
Further reading:
- Documentation: Confluence Space Inventory
- For cross-space links to work the space to site mapping has to be configured in the Space Inventory: Cross-space links and target sites
Q: Do the versions of Conflunence pages also get migrated?
A: No. Only the current version of pages and attachments will be migrated.
Q: Is having WikiPakk the only way to keep the left page tree menu like we currently have in Confluence? Is subscription charging the only way for WikiPakk?
A: WikiPakk is the only ready-made option I’m aware of that shows a SharePoint page tree and breadcrumb, for migrated and out of the box SharePoint pages. At this time a monthly subscription is the only supported payment model. A yearly subscription option will be added soon. If you’d prefer another model, please let me know as demand drives development.
Technically you could develop another form of visualization. The metadata that WikiTraccs creates for each migrated page in SharePoint contains the Confluence page ID, parent Confluence page ID and space key. That is all that’s needed to visualize the hierarchy.
Q: If the execution is interrupted during migration, will it restart where it stopped? We have lots of spaces and access restrictions per team.
A: Yes, WikiTraccs is very forgiving with respect to interruptions. The migration can be interrupted at any time and continues where it left off.
Q: Will it also migrate spaces/pages restrictions as well or we will have to do manually? Please, show us how to migrate also the users/team permissions on migrated pages.
A: WikiTraccs can migrate permissions, to the extend possible given the differences between Confluence and SharePoint. In Confluence you have a page hierarchy and access to each page in this hierarchy can be restricted, at each level. SharePoint in comparison has no hierarchy, just a bunch of pages in the Site Pages Library. There is no permission hierarchy on pages in SharePoint.
Furthermore, when moving from Confluence to SharePoint Online, you need to think about groups. Are all groups from all Confluence user directories that take part in the Confluence permission scheme present in Entra ID? WikiTraccs does not create groups.
The bottom line is that permission migrations - while possible to an extent - rarely make sense.
Further reading:
- Refer to this blog post for instructions on how to migrate permissions, and for a list of capabilities and restrictions with regard to permission migration from Confluence to SharePoint: Mapping principals and migrating permissions
Q: Currently our SharePoint only creates “Modern Pages”, and we cannot create “Wiki Style pages” is that a problem?
A: Perfect, WikiTraccs creates modern pages as well. Classic pages are not supported.
Q: In the target SharePoint site I see in the “+ New” button we now have a new option “Site Page (transformed by WikiTraccs)”, why is this?
A: That’s a new page content type created by WikiTraccs, that is derived from the standard SharePoint content type Site Page. It contains additional fields to hold metadata from Confluence and about the migration. It’s a technical artifact and should be hidden from the user. (#76)
Q: If a page or space makes use of a template (Jira Report / Decision / Sprint Review / etc.) can it be migrated to SharePoint and keep the template working in SharePoint?
Q: If the page has buttons will the button continue to work on SharePoint with same behavior?
Q: There are numerous page templates w/in Confluence. How does WikiTraccs handle page templates (page layout/structure)?
A: WikiTraccs migrates Confluence pages to SharePoint Online modern pages. It transforms the content of Confluence pages to something that can be shown in a SharePoint page, and is limited by what SharePoint has to offer (layouts, web parts, formatting, …). WikiTraccs has no explicit knowledge of templates.
What WikiTraccs recognizes is the use of Confluence page layouts with sections, like “two column section” or “three column section with side-bars”. Those will be translated to SharePoint page sections, which are comparable.
Overall, you can think about it this way: WikiTraccs can do in an automated fashion what you can do manually in SharePoint. If you cannot create something in SharePoint, WikiTraccs can’t do it either. But if you can create it, WikiTraccs could be able to do it as well, if it’s not already doing it.
Further reading:
- This overview covers what WikiTraccs can do: Feature Overview. If you think something should definitely be in there, please create a feature proposal.
- Confluence page layouts, sections, columns, and panels.
Q: Will the tool flag if it could not properly migrate a page or space?
A: Yes. WikiTraccs measures migration success on two levels: page and space.
For page content migration success WikiTraccs collects indicators. Those indicators are stored with the page in the Site Pages library. You look at those indicators to find problematic pages, in each target SharePoint site.
For space content migration success WikiTraccs creates progress log files for each migrated space. You can see which pages have been migrated, how many are yet to be migrated, and more.
Further reading:
- Page migration success: Measuring page migration success
- Space migration progress: Monitoring Confluence to SharePoint Migration Progress
- And for general diagnosis of issues: common log files
Q: How does the tool decide if it should create a Team site, Hub site or a communication site when migrating? Can the tool decide this automatically?
Q: Does the tool always require a blank target site in SharePoint?
Q: If we point the tool to target a SharePoint url destination that already has content with same title, will it be overwritten, or the tool will create a new site keeping any existing SharePoint site intact?
A: WikiTraccs does not create SharePoint sites. You need to create or choose target SharePoint sites for the migration. Note: the target sites need to have the Site Pages feature enabled which is on by default for modern sites.
You enter the target SharePoint URLs into the Space Inventory.
Deciding the right type and number of target sites in SharePoint is out of scope of WikiTraccs and would be part of a transformation project of any kind.
Further reading:
Q: Is it better to centralize the migration in one team? WikiTraccs seems to requires us to migrate from the root URL of Confluence, if not, there will be an error.
A: The migration could be done by multiple teams. For that to work you would create clusters of source space and target sites and assign each team one cluster. Each team could use different migration accounts for Confluence and SharePoint. This way each team would only see content from their cluster. Keep in mind that this might break links between pages if WikiTraccs cannot access both the source and target page/space.
Regarding the root URL: WikiTraccs uses the Confluence REST API and needs to know the Confluence base URL to find the correct REST endpoints.
Q: I find it difficult to understand what pages I was selecting comparing against the left page tree view menu. I want to migrate only pages under menu “FAQ”. How can we do that in the “Confluence Space Inventory”?
A: WikiTraccs migrates spaces. It does not allow selecting single pages or parts of the page tree for migration. If you want to migrate only some pages of a Confluence space to SharePoint you need to migrate the whole space and delete the content from SharePoint that you don’t need.
Further reading:
- Feature proposal to allow selecting pages via CQL query: #77
Q: How much time does it take to migrate?
A: The migration time depends on a number of factors. Let’s look at each of those:
- SharePoint usage and throttling affects migration time
- depending on the usage of Microsoft 365 worldwide and the region you are in the speed of SharePoint-related operations can vary; migrating on a weekend might be faster than during working hours
- also depending on the overall Microsoft 365 service usage clients might be throttled; this means for WikiTraccs that sometimes it has to wait before being allowed to create new content; this is also why it might make limited sense to run parallel migrations - throttling might occur faster
- throttling can happen at any time, slow cloud perforformance can happen at any time
- the speed of a SharePoint tenant as well as throttling limits depend on the number of active licenses in the tenant; thus migrating to a SharePoint test environment might be slower that migrating to a production environment
- page contents affect migration time
- migrating a simple page from Confluence to SharePoint on average seems to take about 4 to 8 seconds
- migration time per page will be higher if the page links to page-external content, like Jira issues (causes request to Jira server), external images (causes download of external image), and other Confluence pages, spaces, or attachments (causes additional requests to those Confluence resources)
- attachments affect migration time
- each attachment has do be downloaded from Confluence and uploaded to SharePoint Online
- downloading from Confluence takes time that is dependent on the Confluence instance’s performance
- uploading to SharePoint can take anything up from half a second
- larger attachments take more time
- the number of pages per space can affect migration time
- when starting and stopping the migration of a Confluence space WikiTraccs requests the list of pages for that space from Confluence, to fuel progress bars and measure migration success
- for spaces with a large number of pages (say 10000 pages and up) getting the list of space pages can take minutes - this is a known Confluence issue
- the time to retrieve pages from such a large space can vary; one Confluence instance might return a list of 25000 pages in 20 seconds, another instance might take half an hour
WikiTraccs migrates pages one by one and does not parallelize. You can parallelize the migration by running a second WikiTraccs instance on another machine.
Further reading:
- Documentation about the challenges of large spaces: Migrating large Confluence spaces to SharePoint
- Feature proposal to speed up migrating large Confluence spaces: #69
- Documentation about throttling by Microsoft
Q: Has WikiTraccs ever done a big migration / Enterprise level like ‘big company’?
Q: We Have at least 350 Confluence wiki spaces to migrate to SharePoint. Is there a batch of so many wiki spaces you can do in one run?
Q: We have multiple attachments currently in the Confluence wiki spaces and is there a limit how many attachments can be migrated to a SharePoint site?
A: The largest successful WikiTraccs-based migration that I know of “in the wild” consisted of ~160 spaces and ~200,000 pages. The largest space had ~20,000 pages. Note that I’m not aware of customers that did restriction/permission migrations and would advise against it, as SharePoint works differently that Confluence with regard to permissions.
The largest migration in a test environment has been ~3,000 spaces, consisting of ~120,000 pages, having ~360,000 attachments that where ~850 GB in size - all migrated from Confluences to a single SharePoint target site collection.
In principle there is no defined technical limit to the number of pages or attachments WikiTraccs an migrate, and SharePoint can ingest within its impressive limits. It’s just that migrating and verifying takes longer with every space, page and attachment that is part of the migration.
The “Is there a batch of so many wiki spaces you can do in one run?” question carries additional topics: the concept of a batch and run. In my view a batch would be the Confluence content to be migrated as configured via the Space Inventory list. You defined the size of the batch. A run would be what WikiTraccs does after kicking off the migration. It will migrate the content one page after another.
One note regarding the you can part of the question; this might just be a phrasing issue, but to be clear: The Wiki Transformation Project does not offer consulting services and does not take part in migration projects. The Wiki Transformation Project provides the tool WikiTraccs that can be a vital part of your Confluence to SharePoint migration tool belt, as well as WikiPakk to provide a SharePoint page tree experience that will make users happy.
Further reading:
- Documentation: Confluence Space Inventory
- How to map Confluence Spaces to SharePoint Sites
- Hints about what you should consider as part of your migration project: Migration Playbook
- More about the SharePoint breadcrumb and page tree experience: WikiPakk
Q: Do you provide consulting services?
Q: Can you provide more details about the PS costs that you can share?
Q: Are there maintenance fees?
Q: Do you offer any professional services to assist our team, if required?
A: The Wiki Transformation Project provides unrestricted break-fix support via email and GitHub.
Read more about your options here: Support Options
With regard to consulting services (advisory services, premier support, alliance support, etc.): The Wiki Transformation Project does not offer consulting services and does not take part in migration projects. The Wiki Transformation Project provides the tool WikiTraccs that can be a vital part of your Confluence to SharePoint migration tool belt, as well as WikiPakk to provide a SharePoint page tree experience that makes users happy. I might recommend consulting partners though, depending on the region you are operating in.
Further reading:
Q: In your experience what determines the success or failure of a migration project from Confluence to SharePoint?
Q: Do you have a “Default Plan” how we should proceed with such a migration?
Q: What do the success stories have in common?
A: You need to have a plan before thinking about migration tooling.
The Migration Playbook hints at that in the Proof of Concept Phase, Decision, and Analysis Phase.
Providing migration guidance or consulting is out of scope of WikiTraccs. But I might recommend a partner that can help. Get in touch if you are interested in a recommendation.
Q: How long is the trial period for your product (30 days, 60 days or 3 months)?
Q: What limitations are there on using the free eval?
A: When WikiTraccs doesn’t find a license key, it runs in trial (or evaluation) mode.
When running in unlicensed trial mode, WikiTraccs slightly changes the SharePoint pages it creates. It inserts a promotional header, sometimes a footer, and replaces some words in the page with “WikiTraccsTestMigration”. This stops as soon as there is a valid license key.
The trial period of WikiTraccs is as long as you need it to be. There is no end. Try as long as it takes to make an informed decision.
All features are available in WikiTraccs trial mode as well, so you can test them thoroughly. You can perform a test migration of all your Confluence pages; no limits on the number of pages, files, or spaces.
Further reading:
- Separate FAQ around pricing and licensing here: WikiTraccs Pricing
Q: Is the look and feel of the Confluence wiki spaces migrated/transformed to SharePoint site same as in Confluence after it is migrated?
A: This question could refer to the look and feel of the actual Confluence spaces - which will become SharePoint sites - or the look and feel of the wiki pages once they have been migrated to SharePoint.
WikiTraccs does not create or configure SharePoint sites. Creating and configuring SharePoint sites is a manual task that usually is part of a transformational project. This is out of scope of what WikiTraccs can do.
With regard to the migrated Confluence pages the answer is No, the look and feel of the SharePoint pages is not the same as in Confluence.
Confluence and SharePoint are different with regard to layout, styling, metadata, permissions, navigation, user management, and integration with other Microsoft 365 services - so the look and feel will certainly differ. This is something that should be taken into account when introducing SharePoint as Confluence replacement.
I strongly recommend getting to know SharePoint before migrating Confluence content to SharePoint. Create some pages and learn their capabilities.
It's important to note that WikiTraccs creates SharePoint modern pages as wiki pages, not classic pages. Modern pages are part of the SharePoint modern experience which is the future.
Furthermore, when creating modern pages, WikiTraccs aims to create standards compliant pages that a user could have created. This approach is different from other products.
Why is this important? Because when a user edits and saves a migrated page, it will behave like a normal SharePoint modern page, without any formatting disappearing. Besides, it will be friendly to mobile use.
Please refer to the linked pages for more information about WikiTraccs’ capabilities and visual migration samples.
Further reading:
- What can be migrated? Read here: WikiTraccs Features
- Visual migration samples: Migration Samples
- Blog post: What about those Confluence Macros?
Q: Do you need to do any type of tweak or adjustment to make the spaces and attachments look exactly same as Confluence wiki spaces in the SharePoint site(s)?
A: It’s impossible to make the SharePoint sites to look exactly like Confluence, or to make the migrated pages look exactly like the Confluence pages. At least with the approach WikiTraccs takes.
It's important to note that WikiTraccs creates SharePoint modern pages as wiki pages, not classic pages. Modern pages are part of the SharePoint modern experience which is the future.
Furthermore, when creating modern pages, WikiTraccs aims to create standards compliant pages that a user could have created. This approach is different from other products.
Why is this important? Because when a user edits and saves a migrated page, it will behave like a normal SharePoint modern page, without any formatting disappearing. Besides, it will be friendly to mobile use.
The configuration of SharePoint sites is entirely up to you. WikiTraccs won’t do much to a SharePoint site that might be relevant to your use cases.
Migrated Confluence pages will become SharePoint pages - which are different in their capabilities from Confluence pages. For example, Confluence macros are not present in SharePoint. That alone makes a big difference.
Migrated Confluence page attachments stay as they are, as they are just files. SharePoint can store files. WikiTraccs downloads Confluence page attachments and uploads them to the SharePoint Site Assets library, the default place for page attachments in SharePoint. Page attachments can be made visible per SharePoint page via a list view web part, that WikiTraccs can insert at the end of a page.
Q: Are there Confluence standard macros which won’t be migrated?
Q: Confluence allows for many “macros” and application integrations. What happens when WikiTraccs encounters such application integrations?
A: For most macros and integrations it’s technically impossible to migrate them to SharePoint.
You can make an experiment: choose a Confluence macro you’d like to see migrated to SharePoint. In a modern SharePoint page, try to rebuild what that macro does.
Could you rebuild the macro functionality in SharePoint? Good! WikiTraccs could do the same. If WikiTraccs does not yet support your scenario - get in touch, tell me about your solution!
But most likely you won’t be able to find anything in SharePoint that could be a drop-in replacement for your chosen macro. And in this case WikiTraccs cannot find one, either.
Further reading:
- See how certain Confluence macros are handled: Known Confluence Macros
- Blog post: What about those Confluence Macros?
Q: Confluence is also integrated with Jira, and most likely utilizing linked/embedded Jira EPICs, FEATUREs, etc. - How does WikiTraccs handle this situation?
A: There are different Jira macros that can be used to show Jira-related content in Confluence pages, as well as link to those contents.
One macro allows to link to a single Jira issue. WikiTraccs converts this macro to a simple hyperlink, that links to the respective Jira issue. When users click those links in SharePoint they are redirected to the external Jira application.
As of this writing, all other Jira macros are replace by a static placeholder text. Corresponding feature request: #102.
Further reading:
- See how certain Confluence macros are handled: Known Confluence Macros
- Blog post: What about those Confluence Macros?
Q: Is it a one to one Confluence wiki space migration to SharePoint? So 350 wiki spaces will be migrated to 350 different pages and spaces in SharePoint site?
A: WikiTraccs migrates the pages of Confluence spaces to SharePoint sites. You configure the space to site mapping.
When migrating a space, all pages of this space are migrated.
Each space can go to its own target SharePoint site.
Multiple spaces can go to one target SharePoint site.
Note: Currently it’s not possible to “split” a space, migrating its pages to different target SharePoint sites.
For migrating 350 Confluence spaces to 350 target SharePoint sites the process would roughly be as follows:
- create 350 target SharePoint sites and configure them according to your concept; using PnP PowerShell and PnP templates is one common approach to automate site creation
- use WikiTraccs to automatically fill the Space inventory list with information about those 350 Confluence spaces
- map each space to its target site URL
- select spaces to migrate
- start the migration using WikiTraccs
Further reading:
- How to map Confluence Spaces to SharePoint Sites
- Feature proposal to allow selecting pages via CQL query, which would allow “splitting” spaces: #77
Q: Can we do all this in one license or we have to purchase multiple licenses?
A: You buy one WikiTraccs license with the appropriate Page Count Tier and are good to go. There are currently no feature-dependent licenses.
Have a look at the Pricing page for details.
Q: What does the “Page Count Tier” (or “number of pages”) mean?
A: The Page Count Tier refers to the sum of pages and blog posts in the source Confluence environment, at the time of purchase.
The following four tiers are available:
- up to 10,000 pages
- up to 50,000 pages
- up to 100,000 pages
- over 100,000 pages
Note that this is not the number of pages you plan to migrate. Also note that this is not the number of page migrations that you can do.
Here are examples for illustration:
- Example 1: There are 20,000 pages and blog posts in Confluence. You plan to migrate all of them. The license needed is “up to 50,000 pages”, because that covers the source environment’s number of pages and blog posts.
- Example 2: There are 45,000 pages and blog posts in Confluence. You plan to migrate 7000 pages to SharePoint. The license needed is “up to 50,000 pages”, because that covers the source environment’s number of pages and blog posts.
- Example 3: There are 9,000 pages and blog posts in Confluence. You migrate all 9000 pages. Something happens and you need to migrate 5000 of those pages a second time. The license needed is still “up to 10,000 pages”, because that covers the source environment’s number of pages and blog posts.
Further reading:
Q: Is it per-license cost or do you provide an enterprise license model?
A: The cost is per WikiTraccs license key. The purchased license key is for internal use, sublicensing or providing services to a third party is not permitted. The third party would have to acquire a separate license key.
Further reading:
Q: How many licenses we need to complete the project?
A: That depends on the duration of your project.
A WikiTraccs license key is valid for a 6-month period, starting with the date of the purchase. After 6 month you would need to purchase a new license, that again is valid for 6 month.
You need one such license for WikiTraccs with the appropriate Page Count Tier. Have a look at the pricing page for details: Pricing.
Q: Do you recommend each Confluence space to a SharePoint Online subsite?
A: Microsoft does not recommend using subsites in SharePoint Online, and WikiTraccs cannot migrate to subsites. So, I would advise against it.
Further reading:
- Introduction to SharePoint information architecture > Guiding principle: the world is flat