This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

News About WikiTraccs

Fixing image positioning in SharePoint

How to cope with the new way SharePoint handles images that are placed next to each other.
By Heinrich Ulbricht |

Summary of what happened images in SharePoint

Up until about mid-2023 SharePoint text web parts were able to display inline images next to each other. Then Microsoft started upgrading the editor component that powers the text web part, while at the same time introducing changes to the overall page style. This broke adjacent image positioning.

Specifially, when editing a SharePoint page, its text web parts are auto-upgraded to the new editor version which positions once-adjacent images now vertically, not horizontally:

So what are our options to fix this?

How to fix image positioning? And who?

The SharePoint text web part, at the time of this writing, does not support putting multiple images next to each other. Neither in the browser editor, nor via programmatic means.

Here’s a list of parties that could influence image positioning in text web parts, in principle:

  1. Microsoft - but they say the current behavior is by design, so they won’t help
  2. WikiTraccs
  3. You

Number one is out, let’s look at the other two options.

What can WikiTraccs do?

Short version:

At the moment, nothing.

Longer version:

When migrating Confluence pages to SharePoint, WikiTraccs creates pages that still show adjacent images. That’s because it’s generating pages in a version that still supports this. SharePoint supports displaying pages that use the (now) older version.

As soon as you edit such a page it is upgraded to a newer version that doesn’t support adjacent images anymore.

The only thing that WikiTraccs could do is starting to generate pages in such a way that images won’t be adjacent anymore, to begin with. You’d then see the non-adjacent version right away, without having to edit the page.

I’ll look into such options as soon as the new way to display pages is confirmed as generally available by Microsoft. I don’t have such a confirmation, yet.

That means that WikiTraccs cannot do anything at the moment.

What can you do?

You have two options:

  1. Re-arrange images and content when you edit a page.
  2. Roll back the layout change that Microsoft did to screw up image positioning.

Option 1 is straightforward: you edit a page, adjacent images are not next to each other anymore, you have to clean up.

Option 2 involves rolling back a single layout change that Microsoft introduces when upgrading the text web part.

The Wiki Transformation Project provides a tool to achieve option 2: the WikiTraccs Page Companion.

Introducing the WikiTraccs Page Companion

For option 2 to work, we need to change pages as they are displayed in the browser. It’s like duct taping a small piece of paper over a bad part of the page, using duct tape that can be removed without traces.

Fortunately Microsoft provides a supported means of integrating with SharePoint pages: SharePoint Framework (SPFx) Application Customizer. Using such a customizer, we can hook into each page as it is being displayed in the browser.

Regrettable, the change we need to make to how pages are being displayed is not officially supported by Microsoft. We need to accept that if we want to proceed with this duct tape option.

Here’s a demo video of the WikiTraccs Page Companion in action. About 11 seconds into the video, note the little box reading Legacy image positioning (by WikiTraccs) in the lower right corner, that’s the extension:

(Note, because I get asked: the page tree you see in the video is WikiPakk, the SharePoint page tree experience.)

The toggle button can be used to toggle the image positioning fix on and off on a per-page basis. On means, the duct tape is applied. Off means, the duct tape is being removed, again. It is opt-in, so not enabled by default.

As an author, you would check the page you are editing, and toggle the button as needed. The fix affects the page both when being edited and being viewed.

The WikiTraccs Page Companion is available as pre-compiled download (to be deployed to a SharePoint app catalog), and also as source code for you to build yourself. It’s all on GitHub: WikiTraccs Page Companion.

Note that the non-standard nature of this option means that it might stop working when Microsoft makes changes to pages. If that happens, the adjustments that need to be done need to be re-evaluated.

I’m putting the source code out there, so that you are in control as well.

Get in touch if you have any questions.

Broken inline image positioning in SharePoint

A recent update to the text editor web part seems to break positioning for adjacent images.
By Heinrich Ulbricht |

In general, SharePoint is behind Confluence when it comes to positioning images in relation to each other and to surrounding content.

But at least putting images next to each other is possible. Is? Was. s Those two blog posts took a deep dive into the topic of images:

Unfortunately a recent update to the SharePoint text editor web part breaks adjacent images. They aren’t adjacent anymore when editing a page.

Microsoft is upgrading the editor version of SharePoint pages - and the trouble starts

The text editor web part is powered by the CKEditor editor component. It can be licensed by any third party to build rich editor experiences in the browser. Microsoft did that.

The following things define how the text editor web part behaves:

  1. the features that CKEditor provides - like formatting highlighted text, adding tables and so on
  2. add-ons to the editor that Microsoft develops
  3. internal settings set by Microsoft defining which features are available to users
  4. surrounding styles (CSS) that define how things look (e.g. font size)
  5. page contents

The most recent version of CKEditor is version 5 (v5). So far SharePoint used version 4 (v4) of CKEditor.

Microsoft now upgrades pages to use CKEditor v5.

Why is this important for content creators? Because the content of SharePoint pages is somewhat coupled to the editor version of the text editor web part. Microsoft cannot just upgrade from CKEditor v4 to v5 without breaking old pages. Therefore Microsoft auto-upgrade pages when they are being edited. And that modifies the page content.

When you start editing a page and its content briefly disappears and then comes back - this might have been an auto-upgrade.

And somewhere along the way of this auto-upgrade the handling of inline images changed.

How does the page upgrade affect adjacent inline images?

Here are three visuals showing how pages used to behave, and how they behave now.

How it used to be…

This is a page with three adjacent images in view mode, using CKEditor v4:

This is the same page in edit mode, using CKEditor v4:

How it’s now…

And here is a video that shows what happens when the auto-upgrade to v5 for this page kicks in:

Note: I used the browser’s developer tools to slow down the internet connection, which allows us to watch everything in slow motion.

What can be seen in above video:

  1. the page enters edit mode and the three inline images can be seen next to each other for a brief moment
  2. then all web part content vanishes; the auto-upgrade happens where SharePoint converts the content from CKEditor v4 to CKEditor v5
  3. the web part content reappears; the images are placed on top of each other (NOT GOOD)
  4. bonus: all images are gone! (this was a first when recording this video) (NOT GOOD)

Editing this page worked perfectly fine for at least the last 12 months. Images stayed in place, no problems.

Now broken.

What does this mean for pages that WikiTraccs migrated from Confluence to SharePoint?

Pages migrated by WikiTraccs use CKEditor v4. Adjacent images look fine when viewing those pages.

When editing a page with adjacent images SharePoint might decide to skip upgrading this page to v5. The page will look fine in view and edit mode.

When editing a page with adjacent images SharePoint might decide to upgrade this page to v5. Adjacent images won’t be adjacent anymore in edit mode and need to be re-arranged manually. This looks like a newly introduced technical limitation of SharePoint. Note that currently there is no way to put images next to each other via the browser editor.

Note: the same applies to pages transformed by other tools, e.g. when transforming classic SharePoint pages to modern SharePoint pages using the PnP Modernization Tooling.

Resources

I’m keeping track of topics related to page upgrades here.

Adjacent image positioning issues

Issues with adjacent image positioning are reported by the first WikiTraccs client in mid-September.

I created a Microsoft Tech Community post to get input: Modern pages with text web parts upgraded from CKEditor v4 to v5 lose image positioning.

I also created a minimal PowerShell script that can be used to create a SharePoint page with adjacent images to test the page upgrade: GitHub repository. To showcase and pinpoint the issue.

Furthermore I opened a case with Microsoft support, which is closed now. The case ID is 2310071420000151. According to them this is expected behavior.

Other known issues

There were issues with tables when upgrading pages from CKEditor v4 to v5:

There are issues with the new spacing between paragraphs:

Wrapping up

It’s not clear what exactly breaks image positioning on modern pages after upgrading the editor from v4 to v5.

It might be the content upgrade for those pages. But it might also be the changed surrounding styles that come with the upgrade.

I really hope that there will be a proper solution to putting images next to each other on a MODERN SharePoint page. Nothing more. Just some images. Next to each other.

How to migrate rich Confluence tables to limited SharePoint tables?

This blog post covers table migrations and how SharePoint differs from Confluence in this regard.
By Heinrich Ulbricht |

What are different table capabilities of Confluence and SharePoint?

The following table formatting options are available in Confluence:

  • setting the background color for table cells
  • having multiple header rows or columns
  • nesting tables
  • merging table cells

All of the above is not possible in SharePoint at the time of this writing.

Let’s see how WikiTraccs works around that.

How does WikiTraccs adjust for table formatting limitations in SharePoint?

WikiTraccs has to get creative when it comes to mimicking the full range of Confluence table formatting options.

Table cell background color is transformed to colored emojis. The color is moved from the cell background to the cell content, as there are no colored table cells in SharePoint.

Confluence table with colored cells

Table after migrating to SharePoint, with color markers

Only a limited set of rectangular colored emojis is available to do this, so the color often will be off.

Multiple header rows or columns are represented as normal table rows and columns in SharePoint where the text content is formatted bold.

Confluence table with multiple header rows and columns

Table after migrating to SharePoint, with bold text simulating the headers

Nested tables are de-nested. This approach is analoguous to how the the Microsoft SharePoint Migrations tool does it for SharePoint on-prem to SharePoint Online migrations.

Merged table cells cannot be created in SharePoint Online. But WikiTraccs marks those cells that once were merged (as of WikiTraccsrelease v1.3.11).

Here is an example of how it looks after migrating a table with merged cells from Confluence to SharePoint:

Confluence table with merged table cells

Table after migrating to SharePoint, without marking former merged cells (note: default behavior before WikiTraccs v1.3.11)

Table after migrating to SharePoint, with marking former merged cells (note: default behavior as of WikiTraccs v1.3.11)

The little arrow in former merged cells points in the direction of the cell it had been merged with before having been migrated.

Marking former merged table cells is standard as of WikiTraccs v1.3.11.

Wrap-up

WikiTraccs needs to get creative when it comes to transforming Confluence tables to SharePoint tables. The results depend on the complexity of the tables that are migrated from Confluence to SharePoint and a manual content review does not hurt.

Let’s hope that SharePoint keeps maturing to a point where formatting tables is on a par with what’s possible in Confluence.

Migrating large Confluence spaces to SharePoint

This post is about migrating spaces with 10000+ pages which can be challenging due to long page retrieval times.
By Heinrich Ulbricht |

How does WikiTraccs determine which pages to migrate for a space?

When WikiTraccs starts to migrate a space to SharePoint it retrieves the full list of pages for this space.

Say a space contains 20000 pages. WikiTraccs retrieves basic information about those 20000 pages and adds them to a migration queue. (Later, when migrating each page, WikiTraccs retrieves the contents of this page and creates the corresponding SharePoint page.)

Confluence doesn’t allow retrieving information of more than 200 pages at once. So to retrieve information about 20000 pages WikiTraccs needs to request 100 batches of 200 pages, as that is supported.

This paged retrieval is where things get interesting for larger spaces.

Why can large Confluence spaces pose a challenge?

The more pages a space contains the longer it takes to retrieve a batch of pages.

Here are numbers from a Confluence 6 test migration of a space with about 23000 pages:

  • retrieving batch 1 takes < 1 second
  • retrieving batch 10 takes about 2 seconds
  • retrieving batch 25 takes about 4 seconds
  • retrieving batch 50 takes about 6 seconds
  • retrieving batch 75 takes about 10 seconds
  • retrieving batch 100 takes about 14 seconds

Assuming retrieving each batch of 200 pages takes a mean of 8 seconds, retrieving 20000 space pages would take 100*8=800 seconds, which is about 14 minutes.

Exporting this space (with empty dummy pages) via the Confluence space export function takes about 16 minutes:

Successful page migrations

Unfortunately there is not much that can be done about the time it takes to retrieve the list of pages. With release v1.6.8 WikiTraccs started to migrate pages while still retrieving the list of pages for a space. This at least allows the waiting times to be used to migrate the first pages.

Confluence 7.18 introduced an API that allows for faster page retrieval, but so far there was no demand I am aware of as migrated environments were older. If you are migrating a Confluence version 7.18 or newer then please comment here to make this demand visible: User faster page retrieval API (Confluence 7.18 and up).

Conclusion

Large Confluence spaces (more than 10000 pages) can add significantly to the migration time.

When WikiTraccs starts migrating a space it retrieves a list of all space pages, which can take several minutes for those large spaces. The list of pages is retrieved multiple times, for example after migrating the space to check if all pages were migrated.

Those times can add up.

So it’s good to know the spaces with large page numbers beforehand, or to learn about them during a test migration.

Ignoring macros when migrating pages from Confluence to SharePoint

This post describes the new macro ignore list feature of WikiTraccs.
By Heinrich Ulbricht |

Why do I need a macro ignore list?

Certain Confluence macros are only visible when editing a wiki page. Often WikiTraccs can see those macros and migrates them to the SharePoint page - where they will be visible for visitors as well.

One sample is the Excerpt macro with the hidden option set.

WikiTraccs offers a macro ignore list that can be used to exclude such macros from the migration.

How to use the macro ignore list?

This series of screenshots shows how to identify macros to ignore and how to configure the ignore list.

Here’s a Confluence page with one visible macro, as shown for readers:

The Confluence page in edit mode reveals the second hidden Excerpt macro:

Without a configured Macro Ignore List WikiTraccs will migrate the hidden macro to SharePoint, making it visible. Here’s a screenshot of such SharePoint page:

To solve this, open the Confluence page, choose View Storage Format for the page and copy the offending macro XML:

In WikiTraccs.GUI, in the menu bar, choose Settings > Configure Transformation. Paste the macro XML to the Macro Ignore List:

In the Macro Ignore List, remove every macro parameter except hidden:

Delete previously migrated pages as needed after changing the Macro Ignore List, and start the migration.

The macro is now removed by WikiTraccs. Here’s the migrated page again as it looks in SharePoint:

Any macro can be added to the Macro Ignore List. Macros matching the Macro Ignore List will be removed from all pages in the Confluence to SharePoint migration.

During migration, WikiTraccs looks at the macro name and its parameters. If it sees a macro that has the same name, and all of the parameters and parameter values as a macro in the Macro Ignore List it will skip this macro and won’t add it to the SharePoint page.

How to monitor if the filter works as expected?

WikiTraccs logs removed macros while migrating pages from Confluence to SharePoint.

Search for the phrase Removed macro via config by matching template in the WikiTraccs log file to see which macros were removed and which template from the Macro Ignore List did match.

In addition, the Site Pages column WT: Transformation Log contains this information as well.

Wrap-up

The Macro Ignore List allows to specify which macros should be skipped in any Confluence to SharePoint page transformation.

It is one feature that was born directly from customer feedback. And it’s another step in the direction of a more configurable transformation process.

Get your migration started today!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

Registering WikiTraccs as app in Azure AD

By Heinrich Ulbricht |

Azure AD is now Entra ID - please refer to the updated documentation: Registering WikiTraccs as app in Entra ID.

Registering WikiTraccs as app in Entra ID

This post shows how to get that Client ID needed by WikiTraccs.GUI.
By Heinrich Ulbricht |

I recently got the following inquiry about WikiTraccs:

Please explain again briefly what the Tenant ID and Azure Client IDs are and how to acquire them.

This request is not the first of its kind and totally understandable. It refers to the following configuration in WikiTraccs.GUI:

Unless you are a Microsoft 365 developer or admin you normally never have to care about those IDs.

Why do I have to enter Tenant ID and Client ID in WikiTraccs? Where do those come from?

When WikiTraccs creates your migrated pages in SharePoint it needs to access APIs provided by Microsoft. Those are the SharePoint API and the Microsoft Graph API.

Accessing SharePoint in any form requires authentication. Open <company>.sharepoint.com (replace ‘<company>’ with the actual value of your SharePoint) in a private browser tab and it will ask for your credentials like email address and password.

Authentication is also required when WikiTraccs starts the migration. It will open a browser window for you to sign in.

Besides users, applications like WikiTraccs have to authenticate as well to access SharePoint.

To allow an application to authenticate, it has to be registered in Entra ID (formerly known as Azure Active Directory, or Azure AD). This is a manual configuration that needs to be done once.

A registered application has an ID - the Client ID. And the Entra ID tenant it is created in also has an ID - the Tenant ID. Those are the IDs needed by WikiTraccs.GUI.

How to register WikiTraccs as Application in Entra ID?

In a browser, navigate to https://entra.microsoft.com.

Sign in with an account that has the Application Developer role in Entra ID.

The Microsoft Entra admin center (former Azure Active Directory portal) opens.

In the left menu, under Applications, select App registrations, then New registration:

The Register an application blade opens:

Configure the following:

  • under Name enter WikiTraccs Migration Tool (note: or any other name of your choosing)
  • under Supported account types select Accounts in this organizational directory only
  • under Redirect URI (optional) choose Public client/native (mobile & desktop) and type http://localhost in the edit field

Select Register to confirm the app registration.

The application’s settings are now open:

In the left menu, under Manage, choose API permissions.

Choose Add a permission to add the following permissions:

  • Microsoft Graph > Sites.FullControl.All (delegated)
  • SharePoint > AllSites.FullControl (delegated)

Make sure to select the Delegated permissions (not application permissions). Here’s a sample screenshot:

The configured permissions need to be consented by the tenant admin.

As a tenant admin, choose Grant admin consent for… and confirm:

In the left menu choose Overview and make note of both the Tenant ID (aka Directory ID) and Client ID (aka Application ID):

Those IDs need to be entered in WikiTraccs.GUI as Tenant ID and Azure AD Application Client ID.

What did I just configure? Can WikiTraccs now access all content in SharePoint?

NO, WikiTraccs can NOT access all content in SharePoint.

Let me explain.

When starting a migration with WikiTraccs you have to log in with a Microsoft 365 account.

Now the permissions WikiTraccs gets are the intersection of two things:

  • the delegated permissions you configured above (that is Sites.FullControl.All, AllSites.FullControl) AND
  • the permissions of the account you logged in with

This is the magic behind delegated permissions. WikiTraccs can only access as much of SharePoint as the logged-in account.

If you log in with an account that is owner in all sites - sure, WikiTraccs could now access those sites.

But if you log in with a dedicated migration account that has only access to some sites - WikiTraccs can now only access those, nothing more.

Are there alternatives to those permissions?

I hear from customers who have trouble to get the tenant admin to consent permissions.

Use less permissions, get less things migrated

If you can’t get admin consent you can try using the following permissions instead:

  • Microsoft Graph > Sites.Manage.All (delegated)
  • SharePoint > AllSites.Manage (delegated)

Those allow a content migration as well.

But the functionality of WikiTraccs will be limited somewhat:

  • page permissions cannot be configured, as WikiTraccs won’t be allowed to do so
  • out-of-the-box SharePoint page and file metadata Created By, Created (Date), Modified By, Modified (Date) cannot be set, as this requires the same permissions as configuring permissions

Use an existing application

If you have access to another Entra ID application that has the required permissions configured you can use the Client ID of this existing app.

That’s why there is the Use M365 PnP Client ID button in WikiTraccs.GUI. It enters the well-known ID of the application used by PnP.PowerShell. This only works, if you have access to and the needed permissions are configured for the application (this is not always the case!).

Troubleshooting

There is one common oversight when configuring the Entra ID application: selecting the right platform.

You might see the following error when testing the connection to SharePoint or starting the migration if the platform is not correct:

“A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details. Original exception: AADSTS7000218: The request body must contain the following parameter: ‘client_assertion’ or ‘client_secret’.”

This error happens when the platform of the Entra ID application has been set to Web instead of Public client/native (mobile & desktop).

Change the platform to Public client/native (mobile & desktop), which then shows up as Mobile and desktop applications here:

The error should now be gone.

Wrap-up

WikiTraccs needs an Entra ID application registration to access SharePoint. This is true for all applications integrating with Microsoft 365 services.

A common challenge is getting the right people to consent the configuration. The purpose of the app needs to be communicated clearly.

Technically, registering the app registration is quickly done following the steps in this post.

Try WikiTraccs!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

The art of positioning images - part 2 of 2

How are images handled when migrating pages? In this blog post we look at actual migration results.
By Heinrich Ulbricht |

This blog post is the second of a two-parter about images in the context of a Confluence to SharePoint migration:

In the last post we looked at image positioning options in Confluence and SharePoint. How can images be formatted in Confluence? How in SharePoint?

Now we look at actual migration results.

The easy ones: images in their own paragraph

An image in a separate paragraph:

ConfluenceSharePoint

Apart from SharePoint taking more space in general the layout looks comparable.

Now a centered, floating image:

ConfluenceSharePoint

SharePoint can do that, good.

Off to something SharePoint cannot do well.

The problematic ones: images as “characters” in the text flow

Here is something that SharePoint cannot do: putting an image at the end of a line:

ConfluenceSharePoint

How about putting text to the right of an image:

ConfluenceSharePoint

This looks better, although WikiTraccs has to cheat here to make it look like this. This image is converted to a floating one, with the text flowing to the right. More on floating images in the next section.

By the way, putting images next to each other for Confluence is like putting characters next to each other. WikiTraccs lets those images float as well, which can look pretty decent in SharePoint:

ConfluenceSharePoint

And something that is just not possible in SharePoint: putting an image right inside the text, like a “giant character”:

ConfluenceSharePoint

Now we have a look at floating images.

The compatible ones: floating images

Text can flow around floating images on the left or on the right side.

Here is a left-floated image, with text flowing around it on the right side:

ConfluenceSharePoint

And here is a right-floated image, with text flowing around it on the left side:

ConfluenceSharePoint

A special case…

A common pattern that I could observe on Confluence pages is to put some explanatory text next to an image like so:

ConfluenceSharePoint

There is a trick WikiTracks needs to play to make this work at all.

WikiTraccs did insert a one-pixel “floatbreaker” image to wrap the text at the right spot, after the sentence “One lone sentence next to the image”.

Here you see the SharePoint page in edit mode, on the left with floatbreaker (selected in the editor), on the right after deleting it.

SharePoint with “floatbreaker”SharePoint without “floatbreaker”

The floatbreaker is another tiny, invisible image in the SharePoint page with positioning set to center. That breaks the text flow where it’s needed. And it’s the only way I found to stop the other text from flowing around as well.

Kind of hacky, but it works and it survives entering the page edit mode. Of course page authors are free to remove the dummy image and change the formatting.

Wrap-up

Migrating images from Confluence to SharePoint is no easy task for WikiTraccs. Confluence provides more formatting options than SharePoint.

And don’t mention Confluence pages that were created by importing from Word files! Somebody will start crying.

But WikiTraccs will make sense of the most common cases it finds. This should make those image-laden instruction pages readable in SharePoint as well.

Try WikiTraccs!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

The art of positioning images - part 1 of 2

How are images handled when migrating pages? In this blog post we look at what is possible in Confluence and SharePoint.
By Heinrich Ulbricht |

This blog post is the first of a two-parter about images in the context of a Confluence to SharePoint migration:

Off we go.

Why is image positioning important?

Hey ChatGPT, why is image positioning important in a Confluence wiki page?

Sounds about right.

Let’s look at what Confluence has up its sleeve for images.

How can images be positioned in Confluence?

Images as a “giant characters”

You can upload images and add them anywhere on a wiki page.

When inserting an image into text it behaves like one big character:

The image cut the word in half and sits there as if it were text, while taking its space.

Spoiler alert: SharePoint cannot do this. This will become relevant when looking at how WikiTraccs migrates such images to SharePoint.

Here is another sample, looking at it from different angles.

First there is the image, without text around it.

Then a line break on the right edge is removed, hoisting text up next to the image.

Then the image itself is hoisted up, now having text on its left edge.

And then the image is again put right into the text, and when making it smaller it starts to fit in.

This mode of positioning images works especially well for putting multiple images next to each other:

Now let’s look at another image positioning option.

Floating Images

There is a different way of positioning Confluence images known as floating.

Text can flow or wrap around such images.

Here is a sample on how to do this in Confluence Server 8:

And that’s it. Now we look at SharePoint.

How can images be positioned in SharePoint Online?

SharePoint does only support the second way of positioning images - floating them.

Here’s a demo of how inserting an image into text works in SharePoint:

The text is split into two parts above and below the image, the image is centered.

Selecting the image shows buttons that control image positioning:

This behavior looks like in Confluence.

Content is either wrapping on the left or right of the image, or the image is centered with text above and below it.

Now I tried to put two images next to each other.

I tried copy and paste. I tried to insert multiple at once. I tried moving them around.

Here’s me failing to position two images next to each other:

And that sums up the state of inline images in SharePoint pretty well. I was not able to put images next to each other.

Luckily WikiTraccs can control the content on a finer level than me with the mouse, while still creating content that adheres to SharePoint standard. More on that in the next post.

Try WikiTraccs!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

Confluence Page Tree in SharePoint

This post demos hierarchical page navigation in SharePoint.
By Heinrich Ulbricht |

How to create a dynamic page tree in SharePoint?

That is a question I hear time and time again.

Pages in SharePoint have no hierarchy (in contrast to Confluence). All modern pages are basically stored at the same level in the Site Pages Library.

Ever since starting working with SharePoint over 10 years ago I helped customers build trees of different sorts:

  • Search-driven page trees
  • Static page trees (deeper that the standard allows)
  • Taxonomy-driven page trees
  • Metadata-driven page trees

There is still no ready-made solution we can take and use to make navigating migrated pages easier. At least none that is free. (If you know one get in touch and I’ll update the post!)

Let’s effin build a page tree!

You’ll probably need a page tree in SharePoint if you are using WikiTraccs to migrate pages from Confluence. Users might be lost without it, depending on the number of pages.

Here is a demo of how such a page tree can look in SharePoint:

What are we seeing here?

The animation starts with a view of the Site Pages library. WikiTraccs was used to migrate the shown pages from Confluence to SharePoint.

Then a page is clicked, opening this page.

Above the page you can see a new bread crumb navigation and a page tree icon.

Clicking the page tree icon opens a panel on the right side that shows a dynamic page tree. The current page is highlighted. Any other page can be opened by selecting it in the tree.

Note: the page trees that are shown as part of the page content are static views of the Confluence page tree macro. This could be the next step: replacing those static placeholders with dynamic web parts. But that is something for the future.

How was it done?

The bread crumb and page tree above are metadata-driven.

When migrating pages to SharePoint WikiTraccs takes care of migrating page tree metadata as well:

  • Page ID
  • Parent page ID
  • Page order

Every migrated page carries this information in the Site Pages library.

The bread crumb and page tree are part of a SharePoint Framework (SPFx) solution.

The bread crumb is inserted above every page as application customizer SPFx extension.

Data is read from SharePoint using PnPjs.

And finally the user interface is a combination of Fluent UI and Material UI.

No additional backend code is involved, this is pure client-side code.

I want such a page tree!

Ok you can have it 😇.

Although it’s more of a demo to see if a page tree in this form proves useful.

Some things could certainly be done feature-wise. It also needs polishing in non-migrated-page contexts.

You could also build one on your own - the metadata is there!

Anyway, let me know if you want to try it. There is no official release, yet.

I’m trying to get the SPFx solution into Microsofts store AppSource. But I heard that this can be pretty complicated, so not sure if this will succeed. Fingers crossed.

As always: Try WikiTraccs!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

What about those Confluence Macros?

When referring to content migration it’s good to know which content is handled how, and macros are a big part of that.
By Heinrich Ulbricht |

Let’s start with something that has different meanings depending on context.

Content

Page content for space owners might encompass everything on and around a Confluence page: text, macros, attachments, metadata and maybe also comments and permissions.

All those things would ideally be migrated 1:1 to SharePoint. Migrate, turn off Confluence, done.

As you might expect: it’s not that easy.

There are different angles to approach this topic and the different types of content one might expect to be migrated.

For today I want to highlight one type of content that needs awareness and preparation: macros.

What’s in a macro?

Confluence macros can be used to display different types of content.

Macros can aggregate content from other pages. Or they can show search results. They also allow entering unique content, like the Code or Info macro.

When WikiTraccs encounters macros it has different strategies to handle them:

  • replace by something similar in SharePoint
  • replace by a static representation (e.g. Page Attachments and Page Tree macros)
  • replace by its rich content (e.g. Expand macro)
  • replace by a mere text placeholder

Let’s look at an example page in edit mode:

Above Confluence page features text and three macros:

  1. the Info macro, containing text that I entered
  2. the Favorite Pages macro that shows my favorite pages
  3. the Lorem Ipsum macro that generates a random paragraph of text

Here’s how this page looks after having been migrated to SharePoint:

This looks pretty similar.

WikiTraccs, when migrating the page, retrieved text, the Info macro plus content and markers for the other two macros. And because Favorite Pages and Lorem Ipsum web parts don’t exist in SharePoint they are represented by a text placeholder in the resulting page.

Let’s now look at the page in Confluence without being in edit mode:

Confluence knows what Favorite Pages and Lorem Ipsum macros are supposed to do and shows additional, dynamically generated, content.

This, of course, is not possible to replicate in SharePoint.

Now what?

There’s not much WikiTraccs can do about macros not being available in SharePoint.

WikiTraccs already has special handling built-in for a handful of frequently used macros, like the Page Attachments and Page Tree macros.

For many macros you’ll see a placeholder in the migrated page.

Let’s zoom out for a moment.

It’s best to see this as a chance rather than an obstacle. SharePoint is different from Confluence. And as part of Microsoft 365 there is a good chance that something powerful can be built on the Microsoft-side of things.

And zooming in again here are some points for the migration-planning check list:

  • create an inventory of spaces and check which can be excluded from the migration
  • create an inventory of macros that are in use on Confluence pages in to-be-migrated spaces
  • evaluate how removing macros might affect legibility and understandability of pages
  • take a look at SharePoint standard web parts as well as community solutions like PnP Samples
  • think about how the content will be used in SharePoint; is it like an archive or will the content be worked on?
  • identify use cases that are affected by macros not being available in SharePoint anymore
  • re-think use cases to SharePoint / Microsoft 365 where needed (don’t forget about Microsoft Teams, Viva, the Power Platform etc.)

Something wholistic like a transformation workshop or down-to-earth requirements analysis might be in place. (My colleagues at Communardo can support with those.)

With WikiTraccs it’s free and easy to just test the migration. Looking at the results can spark meaningful discussions as well.

Get started today!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

What to expect from WikiTraccs?

So what can you expect from the migration tool WikiTraccs? Or even more general: What to expect from any migration tool?
By Heinrich Ulbricht |

I often demo WikiTraccs to potential customers. Those demos spark discussions around the future structure, navigation patterns, usage scenarios, and more.

These are all topics that need to be worked on in the context of a migration project.

WikiTraccs can support your migration efforts.

It can migrate content from spaces to sites. It can migrate permissions and metadata. It has certain limitations. And it has distinct capabilities.

But there are things that WikiTraccs is not meant to do.

So let’s turn the headline around.

What to not expect from WikiTraccs

The following topics need to be worked on in the context of a transformation workshop, a migration project, or whatever format you choose to generate answers:

  • choose what to migrate - content only? metadata? permissions?
  • make decisions about which content goes from where to where - which spaces need to be migrated? which archived? which deleted? which sites do we migrate to? how many are there? how are they created? use new ones or existing ones?
  • know the amount of content to migrate (at least not in a demo context) - 10, 100 or 1000 spaces? 1000, 10000 or 100000 pages? 10, 100 or 1000 GB of attachments?
  • plan an access scheme for the SharePoint sites - users, groups, permissions given at which level in the SharePoint hierarchy of elements?
  • decide which macros are important for users, and which not
  • choose a strategy for your migration - big bang or in waves? who needs to be informed? how? when?
  • choose migration environments - need test environments? how many? where do those come from? how exact do they need resemble the production environment?
  • …and more, driven by your use cases

WikiTraccs cannot do this for you.

So what to expect from WikiTraccs?

WikiTraccs will help you realize the plans you made.

Let’s assume the following simplified migration plan:

  • 📄 migrate all Confluence pages, from all spaces (10000 pages overall; 20000 attachments, mostly images)
  • 🏗️ one target site for each source space
  • 👥 keep page author and editor, no permissions
  • 📝 accept that macros will mostly be lost and plan to educate users accordingly
  • ⚙️ run multiple test migrations
  • 📅 choose a weekend for the final migration

Here’s how WikiTraccs has got your back:

  • 📄 WikiTraccs migrates content and metadata
  • 🏗️ WikiTraccs migrates according to your space-to-site mapping
  • 👥 WikiTraccs replaces Confluence user accounts by Azure AD accounts according to your mapping
  • 📝 WikiTraccs handles macros according to the known macros list
  • ⚙️ you test-migrate as often as you need (the license is not bound to volumes of data)
  • 📅 using the experience from multiple test migrations verify a migration time of about 2 days

A demo is a good way to see this in action.

Testing yourself is even better. You can quickly put above steps into action in your environment.

Give it a try!

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

New attachments macro transformation

What’s new regarding page attachments discoverability in SharePoint and the new attachments macro transformation?
By Heinrich Ulbricht |

WikiTraccs migrates a snapshot of the attachments macro

The Confluence attachments macro shows a list of page attachments, which looks like this:

A Confluence page with attachments macro.

WikiTraccs now transforms this macro to a table in the target SharePoint page. The result looks like this:

A SharePoint page with attachment links in a table.

This feels a lot better than the placeholder that has been generated before.

And do you see the Page Attachments section at the bottom? Let’s talk about that.

Attachments are also available via SharePoint web part

WikiTraccs creates a Page Attachments section on each SharePoint page with attachments. This allows for easy access of page attachments even on pages that had no page attachments macro.

The section is collapsed by default. Click the section title to expand it:

SharePoint list web part showing page attachments.

This section contains a standard SharePoint list web part. It shows all attachments of the page.

Where are those page attachments even stored??

SharePoint puts files that belong to pages in the Site Assets library. Each page has its own folder. And this is where WikiTraccs puts page attachments when migrating a page from Confluence to SharePoint.

The Site Assets library contains all page attachmetns.

The web part in a page’s Page Attachments section shows the content of the page’s folder.

Summary

Both the page attachment macro transformation and the list web part that shows page attachments should make working with page attachments a lot smoother. They are an addition to the latest release of WikiTraccs.

Give it a try

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

Mapping principals and migrating permissions

This blog post covers new features allowing to migrate permissions and map users and groups from Confluence to SharePoint.
By Heinrich Ulbricht |

Terminology

We need to define some terms before starting into the topic.

The term permissions is used broadly to describe which audiences can access which content in Confluence or SharePoint, and to which extent. Those audiences can be users and groups. Users and groups are collectively referred to as principals.

When explicitly talking about permissions for Confluence pages the term page restrictions will be used as this is the correct Confluence terminology.

A sample permission migration

We’ll do a sample permission migration. Screenshots from this migration will be shown throughout the blog post.

For the sake of this sample migration, let’s assume we want to migrate the following Confluence pages:

Confluence Pages

Each of those pages has a different permission configuration. Some pages have view and edit restrictions set. Some for users, some for groups, and some for both. And some pages form a hierarchy to illustrate the challenges associated with that.

How to migrate permissions with WikiTraccs

WikiTraccs can migrate page restrictions from Confluence to SharePoint (within certain limits, more on that later). Migrating page restrictions is done in three steps.

STEP 1: Migrate content and configure mappings for users and groups

First, you migrate page contents. WikiTraccs stores Confluence page restriction and principal information in SharePoint lists, along the way.

When a page is migrated, WikiTraccs also receives page restrictions for this page as well as information about users and groups involved in those restrictions.

No permission configuration is applied to SharePoint pages, yet.

After successfully migrating the Confluence pages shown earlier (only content!) this is how the Pages Library of the migration target site looks:

Migrated Confluence Pages in SharePoint Pages Library

In addition, the document library Confluence Page Permission Snapshots (located in the WikiTraccs site) now contains permission snapshots for those pages, waiting to be applied by WikiTraccs:

Confluence Page Permission Snapshots

Those permission snapshots contain information about a page’s restrictions.

Then there’s a third list that WikiTraccs populates, the Confluence User and Group Mappings list (also located in the WikiTraccs site):

Confluence Users and Groups

You now configure the user and group mapping in this list. WikiTraccs needs to know which Confluence principal maps to which SharePoint principal.

STEP 2: Mapping Confluence users and groups to SharePoint

One factor for a successful permission migration is the mapping of Confluence users and groups to their counterparts in SharePoint. You configure this mapping manually.

Let’s configure the mapping like this, in the Confluence User and Group Mappings table (located in the WikiTraccs site):

Mapping Confluence to SharePoint Principals

The highlighted column WT_Setting_MapForPermissions contains accounts from Entra ID and SharePoint groups.

Those two mappings shall be highlighted in particular, as we’ll revisit them in STEP 3:

  • the Admin Heinrich (admin) Confluence account is mapped to two target accounts Wiki SpaceAdmin and Heinrich Admin Ulbricht
  • the Wiki Reader (wiki.reader) Confluence user is mapped to the Wiki Reader AD account

When you are done with the mapping, proceed with the next step.

STEP 3: Apply permissions to SharePoint pages

In this last step WikiTraccs applies the stored permission information to the already migrated SharePoint pages. This step has to be started manually and separately from the first step.

After choosing permission migration mode, start the migration as usual. WikiTraccs now applies the already migrated permission information to the already migrated pages in SharePoint.

We now have a look at a page permission migration result in depth.

In Confluence, the restrictions for page Page with view-only restriction for Wiki Reader look like this:

Restrictions of Page "Page with view-only restriction for Wiki Reader" in Confluence

Here’s the resulting permissions for the migrated SharePoint page:

Permissions of the Migrated SharePoint Page

Looking at the principals and permission levels this is what happened:

  • Confluence account “wiki.reader” was mapped to the “Wiki Reader” AD account and got Read permissions which corresponds to the Confluence view restriction
  • Confluence account “admin” was mapped to both the “Heinrich Admin Ulbricht” and the “Wiki SpaceAdmin” accounts and got Contribute permissions which corresponds to the Confluence edit permission
  • “WikiTraccs Admin” is the migration account and got Full Control permissions (the migration account is always added)

The basis for this permission configuration had been layed in step 2 when you configured the principal mappings.

Tracking permission migration progress

WikiTraccs logs the result of each page permission migration in the Page Transactions list, that is located in each migration target site in SharePoint.

For our sample migration this looks like this:

Permission Migration Results

There are several reasons why migrating Confluence page restrictions to SharePoint might fail.

The good thing is that a range of permission migration failures can be fixed easily. The permission migration can be run multiple times and will retry failed migrations. This can be repeated until all resolvable errors have been resolved.

Going back to our sample migration you might have noticed that (in the last screenshot) two permission migrations where not successful. For two pages the result is cannot merge hierarchical group restrictions when calculating merged page restrictions which means that for those pages restrictions could not be migrated.

The next section takes a deeper look at what WikiTraccs currently can and cannot do when it comes to migrating permissions.

Capabilities and limitations with regard to migrating permissions

WikiTraccs currently has two types of limitations when it comes to permission migrations: not-implemented features and nearly-impossible-to-add features.

But first, here is what WikiTraccs will do:

  • apply Confluence user and group page restrictions to SharePoint modern pages, when no hierarchy of page restrictions is involved
  • apply hierarchical page restrictions from Confluence to SharePoint modern pages in certain narrow circumstances (e.g. only users are involved)
  • provide a mapping opportunity for each Confluence principal to one or more Entra ID accounts and SharePoint groups
  • map the Confluence view and edit restrictions to corresponding SharePoint permission levels via a hard-wired logic

Features that might be useful in the future, but are not currently implemented:

  • using other group types than SharePoint groups as mapping target
  • provide fallbacks for when a mapping is missing or empty
  • configurable behavior for failed permission migrations (should the SharePoint page be restricted or not?)
  • more control over the permission migration scope (single pages, spaces, …)
  • migrating space and global permissions (those are currently not migrated and need to be set manually on the SharePoint site or sub site level)
  • allowing to configure SharePoint permission levels to be used in the target page (currently the out-of-the-box permission levels are used)
  • regularly updating SharePoint permission based on a configurable schedule

Features that will be hard or impossible to add:

  • migrating arbitrary hierarchies of page restrictions

Re-apply permissions after changing principal mappings

You can change the principal mapping that you configured in STEP 2, even during or after a permission migration.

To do so, proceed as follows:

  1. in the WikiTraccs SharePoint site, change principal mappings via the Confluence User and Group Mappings list
  2. in each migration target SharePoint site, delete entries from the Page Transactions table for pages that should have their permission configuration updated; otherwise WikiTraccs won’t update those pages
  3. in WikiTraccs, choose Permission Migration mode and start the migration

WikiTraccs will now apply page permissions again, using the already migrated information about Confluence page restrictions, and the updated principal mapping.

Summary

With the next release WikiTraccs adds the ability to migrate page restrictions from Confluence to SharePoint.

You’ll be able to configure which Confluence users and groups correspond to which SharePoint users and groups. WikiTraccs uses this information when applying unique permissions to SharePoint pages.

This release marks a milestone from which further development will be driven by your feedback. WikiTraccs could support several additional scenarios and development effort will be directed to areas with the most demand.

Furthermore, user and group mappings will be the basis for the migration of page metadata like author and editor.

Give it a try

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

Or get in touch via email if you are interested in a demo. Give it 45 minutes and you’ll be up to speed on how WikiTraccs can help you.

WikiTraccs Quick Start Video out now!

By Heinrich Ulbricht |

You can have your first migration running in less than 30 minutes.

This quick start video is all you need:

Download FREE WikiTraccs now

New release - UI overhaul

This covers the latest release 0.0.222 and its changes.
By Heinrich Ulbricht |

The user interface got some additions

The WikiTraccs.GUI user interface has been changed.

The settings have been grouped into steps: First configure the source, then configure the target, then test the configuration, and then start the migration.

Some configuration options are gone. You now use a SharePoint list to configure the Confluence spaces to migrate. This list shows basic information about all Confluence spaces and is filled by WikiTraccs.

Note: The idea behind using SharePoint lists for configuration has been described in more detail here: A new approach to configuring WikiTraccs

A big improvement are the progress indicators. You no longer have to rely on the console output of WikiTraccs to see progress. Instead, you get a progress bar for overall page progress and the progress of each migrating Confluence space:

Migration progress

Laying the foundation for user and group mapping, and permission migration

Starting with the current WikiTraccs release 0.0.222, you need to create a SharePoint site dedicated to WikiTraccs. This is the “WikiTraccs site”. You use this site to configure WikiTraccs, like choosing the spaces to migrate. And WikiTraccs uses the site to store metadata about the migration.

This site also holds two SharePoint lists, Confluence User and Group Mapping and Confluence Permission Snapshots. You will notice that those will be filled while migrating.

The current release does not yet support user or group mappings, or permission migration. But a future release might make use of this data.

Fixes and improvements

When migrating pages with large file attachments WikiTraccs could run into timeouts. This has been fixed.

Parallel file downloads have been added. WikiTraccs now loads two attachment files from Confluence at the same time, optimizing for large and small files.

The list of known edge cases in Confluence page content transformation has been expanded.

The retrieval of Jira issue information has been improved for pages with a large amount of linked Jira issues.

Summary

This release is a big step and lays the foundation to add two big missing features: user and group mapping, and permission migration. I’m excited for the next releases as they will bring WikiTraccs further to what one would expect from a migration tool.

Give WikiTraccs a try and check out its transformation capabilities!

Quick start guide >>

Start today with WikiTraccs’ free Trial Version:

Download FREE WikiTraccs now

I’m also eager to get feedback, so get in touch when you try it: Contact.

Measuring page migration success

This post is about the metrics that WikiTraccs provides about migrated Confluence pages.
By Heinrich Ulbricht |

Which metrics measure page migration success?

Each Confluence page consists of content, formatting, layout, attachments, links, mentions and more that has to be handled when transforming the page to SharePoint.

WikiTraccs calculates the following metrics for each migrated page:

  • the percentage of characters in the page that was migrated
  • the number of unknown macros
  • the number of links that could not be resolved
  • the number of migrated images
  • the number of user references in the page that could not be resolved
  • the number of transformation errors

Those numbers are saved as page metadata.

A SharePoint view for the Site Pages library can be used to visualize those numbers. Here is a migration result indicating success:

Successful page migrations

Source content issues

Below image shows the result for a page where not everything could be migrated. Not all images could be transferred. And there were two links to inaccessible pages:

Missing images and inaccessible pages

Errors like missing images and inaccessible content can often be solved by fixing permissions or broken content in the source Confluence system.

Also note the “3” in the “Crystal Ball Transformations” column. This means there were 3 macros that WikiTraccs doesn’t know yet. It used a generic transformation approach for those macros.

Transformation issues

Sometimes WikiTraccs cannot handle content properly (for whatever reason):

Migration errors

Above image shows that 12 elements in a page could not be transformed and only 51% of the page’s text content made it to the SharePoint page.

Those issues can be caused by faulty Confluence pages triggering transformation errors. There are already dozens of special cases and quirks that WikiTraccs works around. But there will always be cases that are new and need to be looked into.

For such a page, click on “View Entries” to see the content that cause the transformation issue. And ultimately a good thing to do might be opening an issue on GitHub.

Summary

In this post we looked at the metrics WikiTraccs uses to highlight migration success and migration issues. Everything being green is a good indication of a successful migration.

WikiTraccs counts content characters in each Confluence page and again counts characters in the target SharePoint pages. The result will be reported as “Text Transferred Percent”. This percentage is a good indicator if content is missing or not.

A new approach to configuring WikiTraccs

This post is about configuring WikiTraccs with SharePoint lists, a different approach to the GUI-based one planned so far.
By Heinrich Ulbricht |

So far my plan was to establish WikiTraccs.GUI as a visual frontend for configuring WikiTraccs.Console.

But I decided to change that approach a bit. WikiTraccs.GUI will still be application you start transformations with. But the configuration will mainly be done in SharePoint.

How is SharePoint used to configure WikiTraccs?

WikiTraccs stores information about the migration into SharePoint lists. You will create a site collection for WikiTraccs to use. This could be called “WikiTraccs Store” and holds data during the migration. It can be deleted after the migration.

When starting WikiTraccs it will create several lists there. One is the Confluence Space Inventory list. This list stores information about all spaces in Confluence, like space name and space key. But it also allows you to select the spaces to be migrated:

Confluence Space Inventory List in SharePoint

Above image shows the Confluence Space Inventory list that shows some spaces from a publicly available Confluence instance.

In the image on the right side, marked with a red rectangle, are two columns that allow you to:

  1. mark a space for migration via Yes/No column
  2. specify the target site for the migration via a text column to put the target site URL in

More columns might follow as needed. (Note: the column names are still technical and are yet to be named properly.)

Why use SharePoint for configuration?

One benefit of using SharePoint lists for configuration is that they already provide a way to display tabular data, like the space inventory. This data can be sorted and filtered out of the box.

List data can be exported to and imported from Excel files for others to review. So the list of spaces could be given to stakeholders to decide which spaces should be migrated. Then they are imported again and WikiTraccs migrates only the selected spaces.

Using SharePoint as a user interface also means there is less potential for programming errors in WikiTraccs since the interface is owned by Microsft.

SharePoint lists provide a familiar user interface, if users are already used to working with SharePoint. There is no new UI that has to be learned.

The data can be shared with select stakeholders by using SharePoint list or list item permissions.

You are free to run WikiTraccs on any machine, even multiple ones, and change the machine at will. Every instance of WikiTraccs will operate on the same configuration.

And last but not least you have the SharePoint Search at your disposal to locate information you need.

Wrap up

That’s it for the latest update. What do you think about using SharePoint lists for configuring a migration? Get in contact and let me know!

There are more lists that are relevant to WikiTraccs that will be covered in future blog posts:

  • Confluence User and Group Mapping
  • Confluence Permission Snapshots

As the names suggest those are relevant for mapping Confluence users and groups to SharePoint and to ensure the permissions and metadata can be rebuilt properly.

Announcing WikiTraccs

WikiTraccs migrates content from Confluence to SharePoint Online
By Heinrich Ulbricht |

I’m delighted to announce the first public release of WikiTraccs.

What is WikiTraccs?

WikiTraccs is a migration tool for Confluence to SharePoint Online migrations.

Which problem does it solve and who needs it?

WikiTraccs makes migrating content from Atlassian Confluence to SharePoint Online easier. It contains hundreds of transformation rules for a wide range of Confluence formattings, structures and macros.

A migration from Confluence might be beneficial for:

  • users of Confluence Server, since Atlassian will eventually phase out Server, urging users to migrate to Confluence Data Center or Confluence Cloud
  • users of Confluence Data Center, because it only buys some time before migrating to the Atlassian cloud might be inevitable
  • users of Confluence Cloud, because of license costs

Often Microsoft 365 licenses are available already, covering the use of SharePoint Online modern pages to display wiki content. In this case SharePoint Online is a potential target for the migration.

Is it ready for production?

No, not yet. The current release is an early access version. This means the basics work but a lot is still to be done.

The focus of this first release is to migrate content and structure of Confluence pages as reliable as possible. This includes:

  • Text
  • Formatting like bold, italics, underline etc.
  • Text colors and background colors
  • Headings
  • Task lists
  • Emoticons
  • Complex tables
  • Images, internal and external
  • Mentions
  • Page and attachment links, on the same page and to different pages and spaces
  • Layouts with multiple columns and rows
  • Macros - a wide range is supported out of the box, for unknown ones generic rules are applied

It has been tested on thousands of Confluence pages and dozens of gigabytes of images and attachments. Since every Confluence is unique with regard to its content there will be cases not covered. But those will be covered over time as feedback comes in.

WikiTraccs keeps track of every word that is present in a source Confluence page and checks if it is present in the target SharePoint page as well. It highlights pages where this is not the case. Thus pages with lacking transformation success can be identified easily and immediately.

The Feature Overview page will eventually cover all supported and not yet supported types of Confluence content and metadata.

You can also read more about how WikiTraccs works in How does WikiTraccs work?.

Which Confluence versions are supported?

WikiTraccs so far has been tested mostly with current releases of Confluence Server 7. It also works with Confluence Cloud but has not been optimized in this direction.

How do I get started?

Have a look at How to get started?

If you want to get in touch have a look at the options you have for logging issues, start discussions or just give feedback.

What’s the meaning of “WikiTraccs”?

“WikiTraccs” is short for “Wiki Transformation Accelerators”. WikiTraccs for Confluence should indeed accelerate things compared to a manual migration.

There are a lot of interesting topics to be covered which will be done in a future posts!