Jive to Microsoft Migration eBook Excerpt

Jive to Microsoft Migration Step 5 of 9 – Understand the Process


The Equip phase shows some basic information about server hardware that we recommend for performing a typical migration.   The diagram shows two servers/VMs.  This is not required.  At least one dedicated server is required and two is recommended.  One is required to allow a “migration engineer” an environment to perform the work for a migration.  In some of the larger migrations, it is helpful to have more than one migration server dedicated to pulling content from Jive or pushing content to SharePoint.  It is also helpful to have multiple servers if there is a need for multiple migrations engineers to have access at the same time.


The inventory phase is one of the most important parts of the migration.  This is where we pull the people, places, and high-level content from Jive.   We have the concept of a “shallow” pull into inventory and a “deep” pull into inventory.   A “shallow” pull is where we make minimal calls to the Jive REST-based API to capture representations of People, Places, and Content.   This level of content is generally suitable to indicate the breadth and size of a Jive migration and helps to perform initial planning (leading into the Prepare section).   We sometimes also perform a “deep” pull which makes additional calls to the Jive REST-based API for each representation of People, Places, and Content.   This includes retrieving the roles of a Person, the members of each Place, and comments for each Content item.   A deep pull takes longer to execute and is typically performed when it time to do the production-level batch planning (see Batch phase below).


The prepare phase is where we begin work on proof-of-concept (POC) and Pilot migrations.  A POC-based migration accounts for code and process-level enhancements to the utilities (if required).  The goal for a POC-based migration is to make sure the utilities work as expected and the migration process is solid from a developer/technical perspective.

A goal of a Pilot-based migration is typically to involve the business and key stakeholders and to make sure the end-result of a migration works as expected.  We solicit feedback from a well-defined pilot group and may iterate/perform a migration multiple times to account for the feedback.  The feedback is typically prioritized and addressed according to a statement of work.

Another part of the prepare phase is to establish the basic patterns of mapping places.  Mapping places means determining the rules and conditions for where a place in Jive will ultimately be found in SharePoint.


The batch phase is where the overall inventory of places and content to migrate is analyzed.  During the analysis, the business helps to determine what will and what will not be migrated.  Typically, we work with the business and key stakeholders to help define criteria for what is and is not to be migrated.  An example would be to exclude the migration of Jive places where content has not been updated in the past eighteen months.  We also work with the business to determine if there are any “custom” mappings.  This covers scenarios where two or more Jive places may be combined into a single SharePoint location OR maybe the target URL/location for a Jive place needs to be a bit different from the others in SharePoint.

Once the business has made their pass at determining what is in and out of scope for a migration AND has specified custom mappings, the migration engineer performs the next part of the batch phase.  This next part is where places are grouped together into batches of 50 places at a time.  These batches will be used to orchestrate the sequence of a migration.


The migrate phase is where the actual migration of content from Jive to SharePoint takes place.  The migration engineer will work with the batches of 50 places (typically) at a time as defined in the batch phase above.  The migration engineer will monitor the following primary operations for each place in a batch.   A log is created for each of these operations and it is the responsibility of the migration engineer to review the log and address any issues that may occur.

  • Get Content – A deep pull of content (including the pull of binaries) is performed for each of the places specified in a batch. This part of the process pulls in all content either into the Inventory database or into the file system, depending on the content type.
  • Transform Content – After content is pulled from Jive, the transform operation prepares the content to be stored in SharePoint. This includes but is not limited to revising content links (links to content in Jive changed to links to content in SharePoint), revising image locations, and revising references to people/profiles.
  • Upload Content – Once content has been transformed, it is now ready to be uploaded to the destination SharePoint environment. This upload operation uploads all content targeted for SharePoint, attempts to set the original author and creation/modification dates to match what was in Jive.  The upload operation also updates the internal counts to be used for the Verify phase.  This phase is repeated until all batches are complete.

Verify (and Remediate)

The verify phase is where the migration engineer accounts for any issues/errors found in the log output from the migrate phase and ensures that all content can be accounted for.   Typically, content count from Jive is compared against content count of what was uploaded into SharePoint to ensure there is nothing missing.

The full book will be released later this year – let us know you’d like to be notified when it’s released by joining this list.

Chris EdwardsJive to Microsoft Migration eBook Excerpt

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.