Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has spent nearly a decade helping clients transform and migrate their content from one platform to another (typically to Microsoft 365) with a focus on the more complex scenarios. Prior to his transformation focus, Kirk led several key SharePoint integrations at ThreeWill including Jive, Polycom, and Confluence.
[Note: this post was originally published in December 2017 and was most recently updated in March 2023.]
Introduction to Jive to Microsoft 365 Migrations
This Ultimate Guide provides the high-level information you need when you are researching how to successfully accomplish a Jive to Microsoft 365 Migration.
It draws on over ten years of experience from ThreeWill with Jive, Microsoft 365 (especially SharePoint and Microsoft Teams), and migrating customers from Jive to Microsoft 365. This guide gives insights for organizations wanting to prepare for an upcoming migration.
With the new offerings from Microsoft, including Microsoft Teams, we’re seeing content from Jive go to more than just SharePoint. We are also seeing customers wanting Jive content to go to Yammer, Microsoft 365 Groups, Microsoft Teams, and OneNote. As such, we’ve opted to use the phrase “Jive to Microsoft 365 Migration” for this Guide. We see that “Migrating Jive to SharePoint” doesn’t capture the full understanding. For this Guide, we’ll just use Microsoft 365 as the overall term for the different offerings and places where we migrate content from Jive.
Audience
The audience for this Ultimate Guide is anyone wanting to learn more about successfully migrating their Intranet from Jive to Microsoft 365.
Backstory and Introduction
To begin, here is the backstory on how ThreeWill got involved in doing Jive to Microsoft 365 migrations. The backstory will help you understand how we arrived at a place where we’re helping clients make the move successfully.
- In 2008, Jive hired ThreeWill to build their SharePoint Connector
- Jive white-labeled our services to deploy the connector to over 100 enterprise customers
- In 2011, Jive acquired a company (Offisync) and decided to take the Microsoft strategy in a different direction and transferred the connector to ThreeWill
- Given our experience with Jive/Microsoft, we started getting contacted in 2012 by companies to migrate from Jive to Microsoft 365
- We’ve worked with over 100 companies to help them make the move
- We’ve built a suite of utilities and processes to help migrate customers successfully
With Jive’s acquisition in 2017 by Aurea, we’ve seen an increase in demand for these migrations. For clients wanting to educate themselves on how to make this migration successful, we’ve created this guide on the steps to do so.
Define Vision and Business Case
Before we create the business case, you’ll want to make sure you understand the vision, or the “why,” for moving from Jive to Microsoft 365.
Based on our conversations with clients, here are some common business cases where companies make a move:
- Strategically align with Microsoft as the core collaboration platform and possibly your primary intranet
- Unify the collaboration experience for the organization by having one place to go to work together
- Consolidate resources and focus on building maturity on one key platform
- Stop paying double for collaboration because you have both Jive and Microsoft 365
From our experience, most clients say it’s a combination of these reasons (but, almost every one includes #4).
One of the main reasons why we’ve been helping many clients make a move from Jive to Office 36 over the last five years is there is a clear business case with hard costs and soft benefits.
The obvious hard cost is the annual subscription costs for Jive when there is a broad overlap with Microsoft’s offerings. Microsoft has announced over 345 million active Microsoft 365 users (as of November 2022) so many organizations are already using Microsoft for collaboration. Many of the business cases that we have worked on with clients have justified migrating from the hard costs alone, often seeing an ROI within months.
With regards to soft benefits, here’s our initial list of the top 5 benefits.
Speed of Innovation
For many years, Jive ran rings around SharePoint because of the three-year update cycle SharePoint had at the time. Three years is an eternity when it comes to collaboration, especially social. With the acquisition of Yammer and probably even more important the adoption of continuous delivery, Microsoft has little to no innovation gap compared to its smaller competitors.
Clear Roadmap
The sales tactic of, “It’s coming in an upcoming version (and it doesn’t come for years),” is no longer being employed. Kudos to the Microsoft 365 team for putting out a clear roadmap – we appreciate this level of transparency from a software company. Also, Microsoft has leveraged the community to provide input on the priority of features through UserVoice forums (Microsoft 365 / SharePoint / Yammer / Teams / Planner).
Office Anywhere
Microsoft has been putting out solid versions of Office on iOS and Android. They are embracing other platforms, and this strategy is succeeding. Employees can BYOD and Microsoft is enabling their productivity – regardless of their choice of device.
SCHEDULE A CALL TODAY TO BEGIN YOUR JIVE MIGRATION!
CEO Clarity
Here’s a quote from Satya Nadella (TechCrunch Nov 2014 article) –
I just think about three things. There are a few other efforts we do, and I’ve been very clear about those efforts and why they exist, and why we are proud of them. But, there are three products in all of this. There is Windows, there is Microsoft 365, and there is Azure. That’s it. Everything else to me is, of course, you can call them features, you can call them parts of that, and even there there’s complexity. Do we need to tame it and make sure that we’re not inundated by lots and lots of things? But, from a business model, from what moves the needle for both usage and our revenue, those are the three big things that we are very, very focused on.
Unified Stack
With Microsoft 365, you get social features (like Jive), document sharing features (like Dropbox, Box), and IM (Skype for Business) on top of all the other commodity services you get like SharePoint and Exchange.
With all these services in one platform (Microsoft 365), you start seeing some interesting possibilities. These possibilities leverage all the signals that are tracked in the Office Graph. Apps like Delve and Microsoft Teams start to show you the power of bringing all your collaboration to one platform (Microsoft 365).
Educate Yourself on FAQs
Generally, well-educated clients are our best clients. We’ve compiled a list of frequently asked questions that we have heard when talking to companies about making the move.
Why work with ThreeWill to move from Jive to SharePoint/Microsoft 365?
Some of the reasons you should work with our team on this initiative are:
- ThreeWill has successfully migrated other customers off of Jive in a timely manner and can provide references
- We have an extensive background in both the Jive and SharePoint / Microsoft 365 APIs from our experience with building commercial connectors and applications for both platforms
- To make the whole process go smoothly, we have built a migration utility (thousands of hours of development time)
- Doing these types of migrations is a one-time project and therefore you should focus your internal teams on other initiatives where they can apply their experience multiple times
- Using lower-cost outsourcing teams that will be doing this for the first time adds risk to meeting deadlines
We need to get off Jive by a certain date, how early should we begin this process?
It is ideal to reach out to us to schedule the workshop 8-10 months before your expiration date. We may not need all that time, but we have a backlog of migrations and will need to get the workshop scheduled 2-3 months in advance.
What are the three phases of these projects?
These projects are done in three phases:
- Jive Migration Workshop
- Implementation (including POC, Pilot, and Production migrations)
- Sustainment (Post migration support/additional needs like Branding)
What is the purpose of the Jive Migration Workshop?
The purpose of this Jive Migration Workshop is to allow you and ThreeWill to review the business and technical requirements for your Jive migration, and explore the migration approaches and options.
The workshop will cover a detailed review of the migration process. From this review, we identify key decisions that you will need to make related to the migration. We will a) review the current state of both Jive, Microsoft 365 / SharePoint, and any applicable legacy environments, b) review the requirements and drivers for Jive migration, and c) determine the requirements and desired state of Microsoft 365 / SharePoint 2013/16 once the migration is completed.
Often times a primary business driver for migration of the Jive content is license renewal fee avoidance prior to the renewal date. Any migration solution will consider and include the ability to extract and backup Jive content for retrieval before your license expires.
Who needs to attend the workshop?
We suggest including:
- Business Sponsor(s)
- Jive Admin(s)
- Microsoft 365 Admin(s)
- Client Project Manager
- Other Key Stakeholders that will be impacted by the migration
CONTACT THREEWILL TO SCHEDULE YOUR JIVE MIGRATION WORKSHOP TODAY!
How quickly does a typical migration project last?
A typical migration has a pilot migration and a production migration. Smaller migrations typically take 6-8 weeks. Larger migrations typically take 4-6 months. The amount of time depends on the amount and types of content – we have made the tool multi-threaded to maximize the amount of content we can move.
What are the typical costs for the implementation phase of the migration?
Typical costs range from about $50,000 USD for smaller migrations to over $300,000 for larger and more complex migrations. We have been focusing on helping customers with larger Jive communities that have a lot of intellectual property stored on Jive.
If we are just migrating content types that we currently support that has a significant impact on cost. Reach out to us for more details.
What types of Jive content can you migrate?
Great question – this list will need to be updated but here is where we currently stand:
- Documents
- Discussions
- Binary Files (files uploaded to Jive) including Photos
- Collaborative Documents (files written in Jive’s HTML editor)
- Blog Posts
- Calendars / Events
- Polls
- Videos (with some caveats depending on how you are using videos)
- Jive Comments (includes discussion messages)
- Links in Jive Content and Jive User Profile Pages (updated to point to – – SharePoint content)
- Created / Modified timestamps
- Created By / Author (but not Modified By / Editor)
- Group Member Security (Owners/Members of Jive Groups)
- Personal Content (binary files, discussion, collaborative documents)
- Tags and Categories (managed metadata or semi-colon delimited text field)
- Profile Images
- Space Member Security
What types of Jive content can’t you migrate?
- Tasks
- Status Updates
- Private Messages
- Shared Links
- Bookmarks
- Announcements
- Streams
- Jive Overview Pages
- Tiles
- Follows
- Profile Properties
- Ideas
- Comments to Yammer or MS Teams
- Videos to Microsoft Stream (but we can migrate to the Video Portal)
- Likes
- External Users
- Restrict Authors
- Blog Post Banners
But, as any good consulting firm will say, anything can be done for a price. If you need to migrate one of these content types let us know during the workshop. This list is changing all the time. We will update you at the workshop on the latest content types that we can migrate.
Can you migrate secret and private groups?
Yes. And, we will work with your organization to validate the migration of content to these groups in a way that maintains confidentiality.
Is there anything that you typically do after the implementation phase of the migration?
It’s pretty common for us to help customers soften the edges of SharePoint and make it more familiar to end users. Also, it’s pretty common for us to set up a Sustainment Agreement to support future needs.
Understand the Tools
ThreeWill brings a suite of utilities that we have built through the years that provides a way for you to migrate from Jive to SharePoint / Microsoft 365 successfully. We created it so you don’t have to lose the years of corporate knowledge locked up inside of your Jive communities.
The best way to learn about these tools is to watch a walkthrough. Click the images below to watch a walkthrough of the utilities if you want to learn more about them.
ThreeWill Suite of Utilities Overview – 23-Minute Walkthrough
ThreeWill Insights Tool Overview – 5-Minute Walkthrough
Understand the Process
Equip
We typically set up the migration environment using either a ThreeWill or a customer Azure subscription that contains dedicated migration servers and a supporting SQL Server database as well as a shared storage location for log and binary files. If needed, we can build the migration environment on internal servers within the customer’s network, but most customers prefer the dedicated Azure subscription that manages resources for the migration project.
The Equip phase also includes setting up the ThreeWill Utilities and testing to ensure the Utilities can connect to both the customer’s specific Jive (source) and SharePoint (destination) locations.
Inventory
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 suitable to indicate the breadth and size of a Jive migration. This 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’s time to do the production-level batch planning (see Batch phase below).
Prepare
The prepare phase is where we begin work on a technical Burn-In Test and Pilot migrations. A POC-based migration accounts for code and process-level enhancements to the utilities (if required).
A Burn-In Test migration accounts for code and process-level enhancements to the utilities (if required). The goals for a Burn-In Test migration include ensuring access to the necessary systems is in place, permissions are configured appropriately, the utilities work as expected, and the migration process is solid from a developer/technical perspective.
A goal of a Pilot-based migration is typical to involve the business and key stakeholders and to make sure the end result of the 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 mean determining the rules and conditions for where a place in Jive will ultimately be found in SharePoint.
Batch
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. Likewise, 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 its pass in determining what is in and out of scope for 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. These batches can be based on a set number of Jive Places (typically 50) or a set count of content so that migration processing time is more predictable. These batches will be used to orchestrate the sequence of a migration.
Migrate
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 Jive Places 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 the destination environment. This includes but is not limited to revising content links (i.e., 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 environment. This upload operation uploads all content targeted to the destination environment. It 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. They also ensure that all content can be accounted for. Typically, the content count from Jive is compared against the content count of what was uploaded into SharePoint. This is to ensure there is nothing missing. See Step 7 for more details.
Burn-In Test and Pilot Migration
Early in the migration project, you will want to perform a Burn-In Test (BIT) migration of content to validate that the migration utilities can successfully move data from the source environment to the target environment. During these tests, you may uncover some gaps in what the utilities can do for some specific sites or test cases in your organization. Additional BIT migrations can be done later to validate any automation or customizations you are putting in place around the migration utilities.
Once customizations are complete and supporting processes are defined it is time for a pilot migration. A pilot migration involves getting a set of users and sites to agree to be part of the early adopters to move to the new environment. This, or at least to test moving to the new environment. Ideally, this group of individuals is a good cross-section of the organization. This group may need to be flexible while you work through the kinks in the migration process.
The BIT is intended to test the “water through the pipes” of the entire process. This process needs to involve migrating various types of Jive places and content. Additionally, it also needs to test communications, support processes, and issue remediation processes.
With end-to-end tests of these processes, issues found during BIT or pilot can be addressed before large-scale production migrations occur. Otherwise, issues are found when the spigots are fully open, and it can be hard to update your processes if the helpdesk and issue remediation is consuming a lot of bandwidth.
The pilot process can tell you how effective you are with your communications. Are your policies and run book sufficient for your Site Owners? Are the users able to use your self-help documentation? Is your support organization able to use the knowledgebase documentation? Are banner and email communications effective?
Once the initial testing is done, the pilot process can further vet the migration utilities and any customization or automation. Ideally, the number of pilot sites is large enough that you expand the variability beyond the initial POCs and learn about more improvements for your content migration process.
In addition to testing different types of sites and content, the pilot should include actual users to review the results of the migration. Their feedback is crucial as they represent all the individuals that use the system after it is migrated. You need to make sure the pilot participants are willing and able to provide feedback in a timely manner. It is very easy for those users to get caught up in their daily activities and not take the time to pitch in. Getting feedback too late from pilot participants can impact the schedule.
After content is migrated, the pilot process helps uncover holes in your support and issue remediation process. Is your ticketing system ready for migration? Does your helpdesk or first line of support have proper instructions on how to handle incoming issues? Can they properly hand off issues to Tier 2 or 3 support? Your triage process will likely be improved during the pilot. New types of issues may be discovered and as well as techniques for handling them. This is done either proactively (maybe through automation or manual tweaks in the process) or after the fact.
Each Jive to Microsoft 365 migration is unique. There are many configurations and customizations that you can do to either Jive or SharePoint / Microsoft 365. The pilot process can help answer and resolve many issues that show up in migrations in a more controlled way. For more complex migrations, running at least 2 pilots is suggested. Early planning is key to allow for the time to prepare for the pilots and make course corrections with information gathered during them. Without including the entire process during the pilots, the value will be limited to only those aspects of the process that are in the pilots. This adds risk to those parts of the processes that are not being exercised until full-on production migration.
Verify and Remediate
Making sure that content has migrated successfully is an important step in the process. However, first, we need to define what success is for the migration. Before issues occur, proper expectations for migrated content must be set. We feel that this is a critical element to mitigate runaway costs or a long calendar extension for the project.
When migrating from one SharePoint environment to another (esp. Microsoft 365), we feel that setting up and communicating migration policies is key. These basically define what is supported and what is not supported as part of the migration. They also define what the responsibilities are for site owners and users.
When migrating from Jive to Microsoft 365, we do something similar but tend to refer to this as content-type mapping. Since we are migrating from one technology platform to another, the content types are different. Some may not have an obvious landing place in SharePoint or Microsoft 365.
The workshop is when we start the policy and content-type mapping discussions. During BIT and Pilot (Step 6), these expectations are validated by the migration team, site owners, and end users.
Once there is a good understanding and agreement of what constitutes successfully migrated content, the BIT and Pilot can be used make this even more clear. They can also be used to improve processes during the actual migration. Additionally, they can be used to improve the processes and documentation (e.g., self-help) that feed into remediation.
Many issues can be handled by the migration team, but some will fall on the site owners and users. Issues tend to fall into these categories:
- Content remediation
- Link remediation
- Integration with other systems
Content Remediation
Content remediation refers to issues where content is not migrated or is only partially migrated. As part of our migration process, we check counts of content across the various content types. This includes in both the source and target to make sure that the counts match. In cases where they do not, we investigate and remediate. This happens before the migrated content is released to site owners and users.
In addition to verifying content counts, we do spot checks on content and can remediate if issues are found there. However, more of that will lie on the shoulders of the site owners.
Link Remediation
Content in Jive can contain links to various to external URLs as well as other items within Jive. The external URLs are migrated as-is with the exception that sometimes there are Jive-based redirects in the URLs that must be removed. Links to content within Jive must be given a lot more care. There can be links to:
- Content (files, videos, documents, discussions, blog posts, etc.)
- Places (spaces, groups, projects, blogs)
- People
- Attachments
- Embedded content (images, videos)
Each link to Jive content must be transformed to its new location. This is typically within SharePoint unless that content is not being migrated. If it is not being migrated we transform the link into one that points to a “not migrated” page or image.
Our utilities handle transforming the vast majority of these links which is a huge value. It is important to know the mapping of all Jive places prior to migrating any sites. This is a key step in the proper transformation of Jive links. If we don’t know where a Jive place will land, we can’t transform links on any content that references that place. Those links may migrate well before the place they are referencing migrates. Mapping all places ahead of time removes this problem.
Define the Support Process
In particular, a large migration requires a well-defined support process that has been communicated and tested thoroughly, beginning with the Pilot testing. The support process must, in all cases, complete in-incident resolution and address the following issues:
- Inputs from multiple sources: Some issues can be discovered by the migration utilities or by the internal migration team. Other issues will be reported by site owners and users through a service desk or other communication methods.
- Closed documentation feedback loop: As incidents are resolved, support documentation (knowledgebase, self-help, policies, run books) should be reviewed and updated as needed. This ensures future incidents can be resolved more efficiently and opportunities to improve the migration process are more easily identifiable.
- Escalation path: In efforts to resolve incidents, support resources will need a process to raise issues with migration engineers, developers, and other team members. This requires a well-defined escalation path with a return-to-support process.
- Clear path to resolution: All support processes for incident management should have a clear path to incident resolution, minimizing opportunities for issues to go unresolved.
Here is a simplified flow diagram of how the support process may look. Larger migrations will need to have a ticketing system. It may be ideal to use the corporate help desk system if one is already in place.
Use an Archive Strategy
Sometimes there is a lot of Jive content to migrate. An archive strategy can be a key component to keeping a cap on the budget and the overall migration time. The general idea is to archive content that is no longer needed or actively used. You only migrate content that is needed going forward. This can reduce clutter in the newer environment, the migration effort, and the schedule if enough content is archived.
Archive Criteria
First, determine the guidelines or rules for what will be archived or deleted instead of being migrated. Some factors that may influence this decision include:
- Recent activity (or lack thereof)
- Amount of content – e.g., a user created a blog, created 1 or 2 posts, and then stopped updating the content
- Known business circumstances – e.g., divisions that have spun off or teams that no longer exist
- Compliance reasons – governance, eDiscovery, audit, etc.
Additionally, you will also want to decide on the granularity of what is archived or deleted. Once the factors are agreed upon, this can be fed into the inventory and mapping exercises as discussed in Step Five.
Archive Database
All content that we migrate is in a SQL Server database or migration server file system. These are provided as an archive database and file system at the end of the project. We also review how the data is organized. This way the information can be accessed at a later date.
As mentioned in the FAQ, we even archive some of the content types that are not migrated including ideas, tasks, and more.
Conclusion and Next Steps for your Jive to Microsoft 365 Migration
In conclusion, thank you for taking the time to read this guide. You’ve now got a better understanding of the steps required for migrating your Intranet from Jive to Microsoft 365. Notice how important the approach is to the migration and how many steps are about reducing risk. For example, do a pilot first to test out all your processes.
