Share and Enjoy !

In 2009 ThreeWill worked directly with Jive’s engineering team to create a SharePoint connector for Jive. As our client’s needs changed, ThreeWill began migrating customers from Jive to SharePoint (and subsequently Microsoft 365). As our clients went through these complex platform migrations, we identified repeatable content mapping patterns, as well as the need to support the “modern user experience” in M365. This inspired ThreeWill to create specific tools and processes for cloud migrations. In this blog series, we highlight some of these capabilities. All posts in this series can be found here: Jive Migration Highlights.

Transforming Links and Embedded Images

Migration of content not only involves getting the physical bits of data from one environment to another but often that content needs to be transformed in some way. Jive content typically has HTML for the content body (or uploaded file description) and can also include images, links, comments, and more. Jive stores and references these items in a well-defined way that is different than Microsoft 365.  Transformation accounts for where all these items will be stored and referenced in the target system.  This is particularly important for links because many times content contains links that will be invalid after the migration is complete and the old system is retired. In this blog post, you’ll learn about the different types of links we see in Jive migrations and why it is important to transform them.

Type of Links

First, let’s review the types of links that users might create. For the purposes of this article (and our migrations) we focus on links that are:

  1. Within Jive content – collaborative document, blog post, discussion, etc.,
  2. Within a comment/response on a piece of content, or
  3. On a home/landing page such as in a Formatted Text widget

We are not concerned with links within a physical file (e.g., within a Word document or PDF file) as we don’t want to change physical files. Here are the types of links we see on content, comments, and landing pages:

  • External Links – Maybe the most obvious type of link is to content that lives outside of Jive. We call these an “external link”. The trick with these is sometimes they show as a purely external link (e.g., and sometimes they are more disguised (e.g.,
  • @Mentions – Another typical link that users create is when they @mention another user, more likely in a comment, but it can also be within a piece of content. That link goes to the individual’s profile. You can also use the same approach to @mention a Jive place (space, group, or project) or a piece of content.
  • Embedded Images – It may not show as a link with underlined text, but anytime an image shows in a piece of content, that is really a link to the image within a <img> tag. These occur a lot as well. There are various flavors of embedded images. Some of these reference “external images” on the Internet, while many are just uploaded while the user authors the content/comment. In addition, the user may be referencing what Jive calls a static image which are reusable images that are pre-defined for the place.
  • Embedded Videos – Similar to embedded images, users will add embedded videos to content or even comments. This can also have various flavors where the video may be “external” such as YouTube or Vimeo, it may be a video content item in the same place (or a different place), and it may be something that was uploaded on the fly (e.g., while responding to a discussion item).
  • Attachments – We see this less often, but there are times when users attach files to their content and then copy/paste the link to the attachment and place it within the body of their content (or sometimes put it on a comment).
  • Landing Pages – Jive allows for up to 5 home/landing pages per place. You can reference those landing pages from within content.
  • Other Jive Links – Finally, there is just a bucket of other links that don’t fall neatly into any of the above categories. This can happen when a user navigates to a particular part of the Jive UI and copies the link from the address bar of the browser and puts it in a piece of content or within a comment. An example I like to use here is if the user were to go to a Jive search results page and copy that link (e.g.,*).

A Plethora of Links

So, what’s the big deal? Is it really that important to transform these links?

Our clients think so and their data backs that up. Jive users not only create a lot of content, but they also use links a lot more than you might think. We don’t keep track of this from client to client, but using one client as an example, we are seeing:

That’s a lot of links.

The table above shows the number of links per 10,000 Jive content items. On average, each content item along with its associated comments/responses has about four links. Three of those four are external or a Jive embedded image and the other one is scattered across the various other types of links.

Granted, this is just from one of our clients, and we have certainly learned that each Jive instance is different so your mileage may vary, but we are pretty confident that there will be plenty of links in your Jive instance. The author of the content put the link there for a reason, so you’ll want it to be transformed properly.

Good News – You’re Covered

If you use ThreeWill to migrate your content, we cover all the scenarios mentioned above except for the “other Jive links” scenario, and we even have a fallback approach for that as well.

In over seven years of migrating Jive content, we have continually enhanced our migration utilities to handle all of these scenarios. Some of them are more complex than they might seem as each link type needs its own logic as does each “flavor”, and sometimes there are “sub-flavors” as well. In addition, we need to migrate the physical images and videos that are embedded within the content so we can reference those as links in the new environment and allow Jive to be retired after the migration.

When a link references to content in another place (or references an actual place), we handle that as well. This requires that the place rationalization (content disposition and mapping) be done for all Jive places before we start the migration. Don’t worry, we walk each client through this process. We need to know which Jive places are being migrated, if any content is being filtered out of the migration (e.g., not migrating “old” content), and where those places are migrating to (the target SharePoint site URL). We take all of this into account to determine where the link will go, even if the link references a place that hasn’t migrated yet.

If for some reason the link cannot be resolved (it references to content that is not being migrated or references one of those “other links”), we link to something we call the “Not Migrated” page. This can live anywhere, but typically lives in SharePoint, and is an opportunity for you to provide helpful information to your users to describe how they got there and why the content was not migrated. There is a “Not Migrated” image as well for any <img> tags that reference images that are not migrating.


I hope this was an informative discussion on the various types of links that can be found in Jive migrations and why you should care about them being transformed properly. If you have Jive content you want migrated, I hope you will contact ThreeWill. As one client told me very recently:

“People were pleasantly surprised that the [Jive] links are now translated into SharePoint links.”


Share and Enjoy !