Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.
This Ultimate Guide has everything you need to know for a successful Jive to Office 365 migration. It draws on over ten years of experience with Jive, Microsoft and migrating customers from Jive to Microsoft. 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, Office 365 Groups, Microsoft Teams, and OneNote (and moving to SharePoint on-prem and not just SharePoint Online). As such, we’ve opted to use the phrase “Migrating Jive to Office 365” for this Guide as opposed to just Migrating Jive to SharePoint. For this eBook, we’ll just use Office 365 as the overall term for the different offerings and places where we migrate content from Jive.
The audience for this eBook is anyone wanting to learn more about successfully migrating their Intranet from Jive to Microsoft.
Here’s the backstory on how ThreeWill got involved in doing Jive to Microsoft migrations. The backstory will help you understand how we arrived at a place where we’re helping clients make the move successfully.
- Jive hired ThreeWill to build their SharePoint Connector (2008)
- Jive white-labeled our services to deploy the connector to over 100 enterprise customers
- Jive acquired a company in 2011 (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
- We’ve worked with over 40 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.
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. 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
- 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 Office 365
From our experience, most clients say it’s a combination of these reasons (but, almost everyone includes #4).
One of the main reasons why we’ve been helping many clients make a move from Jive to Microsoft 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 broad overlap with Microsoft’s offerings. Microsoft has announced over 100 million active Office 365 users (announced by Satya Nadella on April 27th, 2017) 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 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.
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 Office 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 (Office 365 / SharePoint / Yammer / Teams / Planner).
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.
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 Office 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 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.
With Office 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 (Office 365), you start seeing some interesting possibilities which 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 (Office 365).
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 make the move.
We need to get off Jive by a certain date, how early should we begin this process?
We recommend that you 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-6 months in advance depending on the size of the migration.
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, explore the options for migration approaches, and establish a budget to implement your migration.
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, Office 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 Office 365 / SharePoint 2013/16 once the migration completes. Lastly, this workshop will feed into setting a high-level roadmap, with the supporting approach, estimate, and an initial project plan for the migration.
Often a primary business driver for migration of the Jive content is license renewal fee avoidance before the renewal date. Any migration solution will consider and include the ability to extract, and backup Jive content for retrieval before your license expires.
What’s a sample agenda for the 2-day workshop?
|Morning||9:00||0.5||Introductions and Workshop Goals||Roundtable||Initiative|
|O365 / SharePoint Vision and Objectives||Feedback|
|9:30||1||Current State Review – Jive and O365 / SharePoint|
|10:45||0.5||Migration Process Overview/Migration Services||Briefing||Initiative|
|11:15||0.75||ThreeWill Migration Services Capability|
|Content Mapping Overview Diagram|
|Sample Before/After Content|
|Afternoon||1:00||1||Content Coverage – Details||Briefing||Initiative|
|Roles and Responsibilities||Feedback|
|2:45||0.75||Detailed Migration Process Overview||Briefing||Project Execution|
|Morning||9:00||0.25||Review Workshop Goals and Day 1 Summary||Roundtable||Project Execution|
|9:15||1||Migration Planning Worksheet||Feedback|
|Migration Strategy and Approach|
|10:30||0.5||Site Structure Mapping||Feedback||Project Execution|
|11:00||1||Place and Content-Type Mapping – I|
|Afternoon||1:00||1||Place and Content-Type Mapping – II||Feedback||Project Execution|
|2:45||0.5||Workshop Recap||Round table||Project Execution|
1 Session Type:
Feedback – ThreeWill-led session to elicit feedback from the client team
Briefing – ThreeWill presents content, responds to questions from the client team
Roundtable – Discussion session, all participants invited to contribute
What are the deliverables for the workshop?
The deliverables for the workshop are:
- High-level roadmap with the supporting approach and dates
- Product backlog with estimates for migration (and migration tool enhancements – if it applies)
- Initial project plan for the migration
Who needs to attend the workshop?
We suggest including:
- Business Sponsor(s)
- Jive Admin(s)
- SharePoint Admin(s)
- Client Project Manager
- Other Key Stakeholders that will be impacted by the migration
How long does a typical migration project last?
A typical migration has a pilot migration and a production migration. Smaller migrations typically take 3-4 weeks. Larger migrations typically take 3-4 months. The amount of time depends on the amount and types of content – we have made our migration tool multi-threaded to maximize the amount of content we can move.
What are typical costs for the implementation phase of the migration?
Typical costs range from about $25,000 USD for smaller migrations to over $300,000 USD 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.
What types of Jive content can you migrate?
Great question – this list will need to be updated but here is where we currently stand:
- Binary Files
- Collaborative Documents
- Videos (with some caveats depending on how you are using videos)
- Jive Comments
- Jive Messages
- Links in Jive Content and Jive User Profile Pages (updated to point to SharePoint content)
- Created / Modified timestamps and Modified By / Created By values
- Jive Content like Tags and Categories are archived (but not migrated)
- Group Member Security (Owners/Members of Jive Groups)
What types of Jive content can’t you migrate?
- Status Updates
- Private Messages
- Shared Links
- Jive Overview Pages
- Profile Properties
- Personal Documents (Collaborative or Binary)
- Space Member Security (Owners/Members from Jive Spaces)
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.
We do archive many of the content types to a SQL Server database (including polls, tasks and calendar events). This way this information could be accessed a later date.
Can you migrate secret and private spaces?
Yes. And, we will work with your organization to validate migration of content to these groups in a way that maintains confidentiality.
What process do you use for migrations?
For more Frequently Asked Questions – please visit this page.
One of the first things we like to do when working with prospective customers is to create an Action Plan (especially when there is a target date to be off of Jive). Here’s a typical action plan based on our experience – it might seem like some of these timelines are longer than expected, but they reflect the reality of what we’ve seen (we are typically working with larger clients so, usually, the paperwork is what is slowing us down).
Tentative Action Plan for Transition from Jive to Microsoft
+2 weeks – Decide on and schedule 2-day Migration Workshop
+1 month – Begin getting NDA/MSA/SOW in place for the Workshop and get date for Workshop tentatively set
+6 weeks – Pre-Migration Workshop meeting and finalize paperwork
+2 months – Migration Workshop and POC (migrate a couple of places)
+2 months – Client completes mapping document (where Jive content is going to in Office 365)
+3 months – Get SOW in place for migration with Project Plan
+3 months (2-4 weeks) – Pilot Migration and Data Extraction
+4 months (typically three weeks per 1k places) – Production Migration and Final Acceptance
+5 months – Contingency Time
+5 months – Off Jive
We’ve done smaller migrations in less time (the smallest was around six weeks total) and have sped up the process with clients that can make decisions and get paperwork in place quicker. Some things, like communication to and feedback from department heads and end users, require time not just from the team and are dependent on others. Note that the timeline can be extended if you engage us to enhance our migration capabilities to support a Jive content type that is not currently supported. Note the supported content types are documented in this eBook.
ThreeWill’s Migrator is a Jive to SharePoint Migration Suite of Utilities from ThreeWill that provides a way for you to migrate from Jive to SharePoint / Office 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 Migrator and Migrator Trial Version.
ThreeWill Migrator Overview – 23 Minute Walkthrough
ThreeWill Migrator Trial Version Overview – 5 Minute Walkthrough
Diagram #1 – Migration Process Client Involvement Overview
Diagram #2 – Detailed Migration Process Overview
The Equip phase shows some basic information about server hardware that we recommend for performing a typical migration. Diagram #2 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 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’s time to do the production-level batch planning (see Batch phase below).
The prepare phase is where we begin work on a technical proof-of-concept (POC) and Pilot migrations. A POC-based migration accounts for code and process-level enhancements to the utilities (if required). The goals for a POC-based 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 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 mean 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 in 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. 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.
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, 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 the content count of what was uploaded into SharePoint to ensure there is nothing missing. See Step 7 for more details.
Early in the migration project, you will want to perform a proof of concept (POC) 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 POC 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 – or at least to test moving to the new environment. Ideally, this group of individuals is a good cross-section of the organization and can be flexible while you work through the kinks in the migration process.
The pilot process is intended to test the “water through the pipes” of the entire process. This clearly needs to involve migrating various types of Jive places and content, but it also needs to test communications, support processes, and issue remediation processes.
With end-to-end tests of these processes, issues found during 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 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 techniques for handling them either proactively (maybe through automation or manual tweaks in the process) or after-the-fact.
Each Jive to Microsoft migration is unique. There are many configurations and customizations that you can do to either Jive or SharePoint / Office 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, but 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, adding risk to those parts of the processes that are not being exercised until full-on production migration.
Making sure that content has migrated successfully is an important step in the process, but first, we need to define what success is for the migration. Before issues occur (and they will occur), we feel that a critical element to mitigate runaway costs or a long calendar extension to the project is to set proper expectations for migrated content.
When migrating from one SharePoint environment to another (esp. Office 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 as well as what the responsibilities are for site owners and users.
When migrating from Jive to Microsoft, 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 Office 365.
The workshop, covered in Step 2, is when we start these policy and content type mapping discussions. During POC 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 POC and Pilot can be used make this even more clear. They can also be used to improve processes during the actual migration and 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 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 in both the source and target to make sure that the counts match. In cases where they do not, we investigate and remediate 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.
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)
- Embedded content (images, videos)
Each link to Jive content must be transformed to its new location (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, but some slip through the cracks. That’s why our utilities also have a check for broken links which is performed immediately after the content is migrated. Any issues are flagged and can be remediated before the migrated content is released to site owners and users.
A key step in the proper transforming of Jive links is to know the mapping of all Jive places prior to migrating any sites. 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.
Integration with Other Systems
If your migration is going straight from Jive to SharePoint on-prem or SharePoint Online, then this does not apply. In many cases, though, we have clients that want to migrate to systems or applications outside of SharePoint. Videos are one primary area where another system may be involved by migrating to a file server, another video management system, Office 365 video portal, or Microsoft Stream. In addition to video-centric systems, others can be involved as well such as Yammer, Microsoft Teams, and Azure AD. These may have very custom requirements and processes that are part of the migration. The remediation of these can vary greatly and needs to be planned for as part of the migration process.
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 and may want to use the corporate help-desk system if one is already in place.
If 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 and only migrate content that is needed going forward. This can reduce clutter in the newer environment and can vastly reduce the migration effort and schedule if enough content is archived.
The first step is to 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.
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.
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, and we review how the data is organized. This way this information could be accessed a later date.
Step Ten – Questions to Ask Your Service Provider
Here’s a list of questions (with answers for ThreeWill) that we suggest you ask when talking to service providers about migrating from Jive to Microsoft. There are some simple ways to perform a very crude migration of content from Jive to Microsoft and companies can be misled to enter a migration project that has poor outcomes where, in some cases, content needs to be re-migrated in a second attempt. To avoid making an uninformed decision, we recommend asking the following questions of the targeted service provider that would perform your Jive to Microsoft Migration:
Question – How do you handle the transformation of all the Links/URL’s in Jive as all the content moves to new URLs and destinations in SharePoint / Office 365? Do you transform links to people and places as well?
ThreeWill’s Answer – We have a dedicated action in our utilities for handling link transformation. The link types include people-referencing links, place-referencing links, and content (content type) referencing links. We use regular expression patterns to scan content, capture links in our inventory database along with the replacement link. The replacement link is produced based on the type and dedicated business logic. We retain the original content in our database and represent all replacement links in a separate “Transformed Content” field that is used for SharePoint. This allows us to know exactly what links were found and replaced. We also retain all the original content from Jive.
We have other utilities to scan the migrated SharePoint content and search for broken or lingering Jive links; as well as a way to repair these broken/Jive links in-place in SharePoint. This link repair/replacement process does not disrupt the created/created by and modified/modified by values.
To properly handle links to people, we work with each customer to determine the target profile page and work to ensure a user’s profile can be properly represented in the target environment.
To properly handle links to places, we rely on our destination mapping methodology/formulas to properly construct the target place URL.
Question – How do you handle migration of Jive security groups and associated permissions for both Groups and Spaces? How do you preserve the security around Private and Secret Groups?
ThreeWill’s Answer – During the inventory process, we pull all Jive people and places into a database. This process also involves capturing ALL security groups via the Jive API. We do a deep pull of each security group also to capture members/administrators.
As we are pulling Jive places into inventory, we check to see if we are working with a Jive group or a Jive space.
If we are working with a Jive group, we pull all the group members/owners into a specific table of our database.
If we are working with a Jive space, we pull the respective “Applied Entitlements” (which are at the content type level and related to the previously pulled security groups).
This allows us to represent security for both groups/spaces and makes it possible for us to do detailed reporting and planning for how permissions will be applied in the target environment. We have a default way to apply permissions to the target SharePoint sites but typically work with each migration customer to further define the rules for applying permissions.
Question – How do you migrate comments associated with all of the different content types in Jive? How are these comments stored in SharePoint / Office 365?
ThreeWill’s Answer – We capture all comments and retain the threaded relationship of comments in the database. Comments are transformed (as described above) in the same way as content.
We have a couple of different options related to how comments are migrated. One way is to incorporate all comments into the actual content pages (wiki pages in SharePoint). These comments are fixed (more of an archive).
Another way is to put all comments into a Yammer thread that can be surfaced as a web part of SharePoint.
Overall, the challenge is that SharePoint does not really support the rich commenting in the same way that Jive does so we have to work with each migration customer to determine the best way to make comments useful/manageable.
Question – How do you migrate all of the different types of video content in Jive – attached, embedded, etc.?
ThreeWill’s Answer – We are able to pull video content that has been uploaded to Jive (and may or may not be hosted by a third party). Typically, we create a video asset library in SharePoint and leverage a separate media streaming server/environment for handling video streaming. If the videos are consistently small enough, the video can be stored directly in SharePoint,but typically we have found it best to reference videos from a media server/platform. This is another area where we work through individual customer requirements to determine the best video solution.
For embedded videos, we capture the embed details so that the respective video and be embedded in the target SharePoint site.
Question – How do you migrate all image content to SharePoint / Office 365 and how do you maintain the linkage/references to these images once they are stored in SharePoint / Office 365?
ThreeWill’s Answer – All images and referenced binary content (attachments and binary file content like Word documents, Excel spreadsheets, etc. are organized and consistently stored in a dedicated SharePoint document library. Referencing content, which may be a wiki page, blog post, discussion list item or reply all reference images, attachments, etc. are also stored in this dedicated SharePoint document library.
Question – Do you maintain the author/editor of the content when it is migrated to SharePoint / Office 365?
ThreeWill’s Answer – Yes. We do maintain the author/editor in all places where possible. In the case where a person has left the company and/or cannot be found in the target SharePoint environment, we also work with each migration customer to determine the best profile to represent ownership.
Question – Do you maintain the created/modified timestamps of the content when it is migrated to SharePoint / Office 365?
ThreeWill’s Answer – Yes. When organizations make a manual move of content, this is one of the key limitations. Content’s timestamp is key to understanding the value of the content. Content created 2 weeks ago vs. 2 years ago can be a key indicator of the relevance of the content.
Question – How do you handle changes that occur in Jive during the migration? Do you have a delta/incremental migration?
ThreeWill’s Answer – Yes. We capture the date/time that content is pulled from Jive AND when it is actually uploaded into SharePoint. Our utilities can pull deltas (additions and changes) since content, comments, message, etc. were last changed in Jive and can focus just on transforming/uploading the specific delta-based content.
This allows us to pull content from Jive, upload it to SharePoint in batches and during specific hours. We leverage our delta capability to pull, transform, and upload content right before a site is targeted to go “live.” Since working with deltas involves a much smaller amount of content than the complete set of content, we can leverage the delta process to best align with migration scheduling/release.
Question – What is your process for mapping Jive places to SharePoint sites? Do you have the ability to bundle several Jive places in a single SharePoint site collection or split a Jive space hierarchy into several SharePoint site collections?
ThreeWill’s Answer – We produce a consolidated view of all places with a roll up on content details into a spreadsheet we call the Inventory. This Inventory spreadsheet has additional fields for SharePoint site collection, sub-site, and managed path values. We leverage formulas and the Jive place-based URL to build the required site collections and paths to all target SharePoint sites. This detail can be manipulated and customized across the board based on customer requirements. We can also customize for individual sites. This constitutes the mapping that is put into our SQL Server-based inventory database. The transform and upload operations (as described in the above items) leverages this mapping information to reference content as it lives in SharePoint accurately.
Here are some more questions to ask – we’d love to discuss these (and more) when you’re talking to us about the migration or in the workshop.
- How do you determine what specific places are part of a Jive environment? Basically, how do you capture your inventory?
- How do you determine what places should and should not be migrated?
- Are you able to forecast how long a migration will take?
- If I want to customize or re-organize my content during the migration planning, what options do I have?
- Are you able to coordinate and collaborate with 3rd party vendors during migration planning and delivery?
- Can you provide multiple customer references from companies that you have successfully migrated from Jive to Microsoft?
You’ve now got a better understanding of the steps required for migrating your Intranet from Jive to Microsoft. Notice how important the approach is to the migration and how many steps are about reducing risk (for example, doing a pilot first to test out all your processes).
If you’re looking to migrate your Intranet from Jive to Microsoft and looking for a partner to help you pull this off successfully, please learn more about our service offering – https://threewill.com/services/jive-to-sharepoint-migrations/ and download the trial edition of Migrator – https://threewill.com/assets/migrator-jive-to-sharepoint-migration-utility/migrator-trial-version-installation-guide/. If you’re in a time crunch and ready to get an estimate for help with a migration, please take our pre-migration questionnaire – https://threewill.com/next-steps/pre-migration-questionnaire/.
Thank you for taking the time to read this guide.
Initial Post from Pete Skelly (Nov 2014) – https://threewill.com/migrating-from-jive-sharepoint-yammer/
Business Case from Danny Ryan (Feb 2015) – https://threewill.com/business-case-moving-intranet-jive-office-365/
Podcast Interview on Jive to SharePoint Migration Tool (Nov 2015) – https://threewill.com/jive-to-sharepoint-migration-tool/
Ludicrous Mode – Update on the Tool (Mar 2016) – https://threewill.com/ludicrous-mode-update-on-the-jive-to-sharepoint-migration-tool/
Podcast Interview Update with Chris (Aug 2016) – https://threewill.com/prepare-to-migrate-from-jive-to-sharepoint-with-this-new-tool/
Migrator Deep Dive with Demo (Aug 2016) – https://threewill.com/deep-dive-into-migrator-jive-sharepoint-migration-tool/
Migrating from Jive to Office 365 Webinar (March 2017) – https://threewill.com/migrating-from-jive-to-office-365-webinar/
Why Move Content from Jive to Office 365? (July 2017) – https://threewill.com/move-content-jive-office-365/
Guidelines for Costs to Migrate from Jive to Microsoft – https://threewill.com/guidelines-for-jive-to-microsoft-costs/
ThreeWill Migrator Overview – 23 Minute Walkthrough
ThreeWill Migrator Trial Version Overview – 5 Minute Walkthrough
Services Page – https://threewill.com/services/jive-to-sharepoint-migrations/
- Other Benefits? Leave a comment at https://threewill.com/business-case-moving-intranet-jive-office-365/. ↑
- We have a new blog post on guidelines for typical costs – https://threewill.com/guidelines-for-jive-to-microsoft-costs/ ↑