Share and Enjoy !


Migrations are a fact of life for many software products.   Updates to existing products you have implemented often require migrations to current versions, and if you have been in the SharePoint world for any length of time, you know the drill. Many enterprise customers are moving to Microsoft 365 and related services, including SharePoint and Yammer, to streamline their IT services footprint.  But what about migrating from one product to a completely different product?   An increase in customers moving from previous versions of SharePoint to Microsoft 365 and SharePoint 2013 on-premises is obvious, right? But we are also experiencing an increase in customers investigating migrating from Jive to SharePoint + Yammer.

With an increase in customers asking about what is involved in migrating from Jive to SharePoint + Yammer,  I thought I would quickly describe our processes and some decisions points surrounding migrating from Jive to SharePoint + Yammer.  Now, I am not here to argue the merits or shortcomings of Jive, SharePoint, or Yammer – that’s a post for a different day (or maybe never..). This is purely a discussion about our experience with migrating content from Jive to SharePoint and Yammer if your business is investigating a migration or has already made a decision to migrate.

Jive Content Inventory

First, an inventory of all users, places, (Spaces, Groups, Projects, …) and content (discussions, files, attachments,…) in Jive must be completed. Determining what people, places, and content exists is critical to determining where and how this content will be migrated.  We have developed processes and utilities that enable us to interrogate on premises or cloud Jive implementations and export all of the metadata associated with Jive content.  The interrogation and metadata extraction is all pulled into a SQL Server database to enable iterative mapping and migration passes.  This enables us to export the metadata, provide the information to a client, and then facilitate filtering and sorting the data .  Once we have reviewed the data with the client, we can create a mapping and migration strategy based on the structure, volume, and type of the existing content.

Content Mapping

As with any migration, you want to identify mandatory and optional items to migrate. Part of any migration effort from disparate systems typically involves a mapping of content from one system or product’s entities to the other.  In the case of Jive to SharePoint + Yammer, you’ll need to determine the original Jive structure (based on the inventory already performed) and the intended SharePoint site structure.  Specifically, you’ll need to map the content from containers (e.g. a Technology Group in Jive) to SharePoint containers (e.g. a Technology team site).  In our experience, mapping typically falls into 3 high level categories:

  1. Jive place to SharePoint web + Yammer group – the intention here is to move a Jive Space, Group or Project to an analogous SharePoint web in it’s entirety.  Conversations within or around content in Jive must also be mapped to Yammer groups.
  2. Jive place(s) content to SharePoint document library – the intention here is to consolidate content including binary documents (Excel, Word, PDF, …), Jive Documents, conversations, and more into a target document library or wiki’s and Yammer conversations.
  3. Jive place(s) content to lists – the intention here is to move content from a Jive space into a list(s) and documents or other content into document libraries, wiki content, and links (e.g. Project tasks migrate to a Task list).
Jive to SharePoint Mappings

Jive to SharePoint Mappings

Content Migration

Finally, migrating content to SharePoint + Yammer can be done in a variety of ways depending on whether you are moving to SharePoint 2013 on premises or in Microsoft 365.  For our clients, we have been building up a set of tools and utilities to automate the process, independent of target location.  As the image above depicts, content from a Jive Space may be moved to SharePoint in the following ways:

  • 1 : 1 –  moving all data from a Jive place data into a SharePoint web (one to one)
  • Many : 1 – selective migration of content from Jive place(s) into SharePoint webs or document libraries

Typically, one of the above approaches prevails, but there could be a many to many scenario.  Although possible, this is something we have not experienced yet (let us know if this is your situation, we’d love to help).  However,  if Jive and SharePoint were implemented in an enterprise, in our experience there was typically some parity of Jive places to SharePoint sites/webs designed as part of the social integration strategy.  At a finer grain level, actual content migration my take the following forms:

  • moving Jive binary document content into a document library in SharePoint (e.g. Excel, Word, PDF, etc.)
  • moving Jive (native) collaborative documents into SharePoint Wiki’s
  • moving converted Jive (native) collaborative documents (PDF’s) to document libraries
  • moving conversations associated with documents to wiki pages
  • moving conversations associated with documents to Yammer conversations
  • moving tags and rating data to managed metadata or list columns

The options above are some for the more common fine grain content mappings, but there are others.  Based on our experience, the collapsing of the two products creates business decisions and technical options which are often at odds.  For example, converting all conversations around document content in Jive to Yammer conversations and linking these to the content in SharePoint is technically feasible, but organizational and business decisions have typically ruled this option out in favor of speed or simplicity of content migration.

Decision Points

The inventory and mapping processes are usually straight forward, but as mentioned there can be areas which are more complicated.  I always like to say “people are messy, technology is easy”. However, this is a case where technically things can get messy too. Jive, SharePoint and Yammer are different products, based on different platforms, with very different purposes.  Product implementation differences mean you may need to make some tradeoffs and weigh some benefits and drawbacks when migrating.  Below are three of the most common tradeoffs required during migration from Jive to SharePoint + Yammer:

  1. Content Conversion – Converting some types of Jive content to SharePoint content is a simple conversion, but there are cases where Jive content simply may not map easily to SharePoint or Yammer content.  In these cases, the business may need to decide on how much they are willing to spend to convert these data types.  Sometimes, deciding to simply exporting a PDF of the content is enough.  There will be decisions about what content to keep, what content to migrate and what content requires a cost benefit analysis to migrate.  One size does not fit all here!
  2. Content Relevance – The content, conversation or outcomes within Jive may no longer be relevant or required to migrate to SharePoint + Yammer.  In some cases, there is no need to migrate the content at all.  In other cases, the conversation and collaboration around the content is not relevant, but the outcome (e.g. a report or sales template) might be sufficient to migrate.  Deciding if the primary content item (document, conversation, etc.) is relevant or if the primary and secondary content (conversation, tags, ratings, etc.) are relevant can greatly increase the mapping effort and overall duration of the migration.
  3. Metadata Migration – For some organizations, maintaining meta-data like author information, creation and modifications dates, tags or ratings from Jive may be essential for historical or compliance reasons.  But in many organizations the need to map the associated user accounts, actual creator or modifier, or creating and managing the SharePoint Managed Metadata to map to may be cost prohibitive. In this case, deciding on migrating metadata associated with Jive content might be more about risk avoidance than return on investment.


There are a variety of reasons for migrating from Jive to SharePoint + Yammer, including reducing licensing costs, reducing maintenance, increasing operations efficiencies, deeper Microsoft 365 integration, and more. As I mentioned, my intention here is to describe the process we use for assisting migrating customers interested in moving from Jive to SharePoint +Yammer, not to get into a flame war about which solution is “better”.  The process used is important, and we even used what was described above to migrate our own internal content from Jive to Sharepoint + Yammer.  Whatever the reason you may be making the switch from Jive to SharePoint + Yammer,  if you have questions or comments, feel free to comment below or contact us. We’d love to hear some thoughts on what might be done differently, better, or just have an opportunity to help.

Share and Enjoy !

Related Content: