Hey Matt, well and whoa. This is a big question. I have not had this experience personally. But I can only imagine that it would require a lot of work and might not even be possible to handle duplicate users registered with both communities, transfer of points, preservation of linked content within posts. As far as I know, the only way to accomplish such a thing might require an engagement with our professional services team. If you wanted to do it yourself manually, you could figure out what spaces you want to have migrated, recreate the place in the new community, and reupload the content. You'd lose all of the activity related to that content though and there would still be the question of duplicate users, transfer of points, preservation of linked content. This is definitely one of those situations you want to avoid going in.
It might also make sense it to weave the two communities together from an interface perspective, rather than merging, depending on the situation. So that there is persistent navigation (like we have in the black band at the top of JiveWorks) between the two communities. You might be able to get a sassy developer to program a search tile that could search both sites as long as the info is accessible. Maybe even get a SSO tool for your communities so that people don't have to juggle two logins. That's my 2 cents at least.
One more thing, Matt. You might want to also post this question in Jive Support directly. If there is a technically a way to accomplish this, they would know. Posting the question there rather than sharing it would require an answer from that team.
Hey Libby. Thanks for the reply. I know it is quite a feat. I've just been asked to investigate this. I don't think keeping both communities around long term is an option but there may be some flexibility on how some things are handled like users and points. The content is the most important, but I want to take an informed approach in case there is a way to handle everything as a best practice. I'm hoping that I am not a Pioneer here and there have been at least a handful of other customers somewhere that have done this before. Thanks for the advice on posting to the Jive Support space. External Communities seemed to be the most logical place to start. I will leave the post here for a bit and if I don't get any bites I'll move it over.
You might want to leave the post here to get the "community opinion" and create a more straight-forward "is this possible" question in Jive Support. I can tell you that I know other customers have done this because I can see the secret content in our internal community showing this has happened in the past. What I can't tell you is HOW they did it, or WHAT the experience was.
Yeah, this is a big topic. The functionality is there (at least for on premise instances), but we were never able to get it to work correctly in Jive 5/7/8. In our case, gated communities, user registrations were not a factor. The biggest issue we kept running into was data inconsistency (i.e. some Jive objects lost). If memory serves me well with Jive 9, I think there is a "batch move" capability now which would probably mitigate/eliminate data inconsistency as well as change user registration issues to a more black-and-white solution.
Matt, this is a complex operation. Jive's Professional Services team performs these migrations regularly. The team has developed code and expertise over the course of many years to efficiently solve all the issues you mention. Unfortunately, the "bulk move" that Rob mentions is only for moving content within a single community.
I would suggest asking your account manager for an initial quote with Jive Professional Services to understand the scope of taking that route.
1 person found this helpful
JCS Consulting has done this both for Jive communities and for heterogeneous legacy communities (merging up to five different community platforms onto one Jive platform).
As everybody has pointed out it is non-trivial but can be done using established methodologies and tools.
I'd be happy to get on the phone with you and give you a verbal high-level overview of what is involved - my cell phone and Email are on my profile.
Tracy and John - Thank you both for the responses. This makes me feel a lot better that I'm not the first on this mission. I'll be reaching out in the coming weeks under separate cover for a better understanding.
In the meantime, if anyone else on the end user side has been through this process, please add your input, gotchas, and lessons learned.
I have not. Thanks for passing on the link. I will carve out some time to watch soon.
1 person found this helpful
We went through this process last year where we migrated a Jive Cloud instance into Jive 8 hosted instance due to a company merger. There are definitely hurdles and we had some issues due to account duplication. For us, the email address was the key identifier for user accounts. What we did was merge their instance into a space on our instance to keep the content organization intact. However, there had to be content and URL mapping for documents. We went through a couple dry runs before the cutover which helped a lot to find issues/inconsistencies. But, as many people have mentioned on this thread, this is something that your TAM and Jive PS can assess and provide expectations and then a plan to merge and migrate the content. Good luck!
2 people found this helpful
Hi Matt, I'm with Social Edge Consulting and I have been performing a lot of migrations over the last 18 months. Below is some info that I hope will be useful to you.
> I'm looking for an overview of the process and especially lessons learned
We perform most of our migrations using the REST API, and orchestrated with some scripting.
With the REST API you can:
- You can create content, comments, likes, votes, etc.
- You can back-date the create date on content.
- You can migrate content as the original user (via the Core V3 API - Run-As Feature & Signed Add-Ons)
Things you will want to be aware of:
- Migrating videos typically can't be done via REST.
- You are usually better off re-creating the spaces/groups manually. It is possible to recreate Jive Places using REST, but it won't help with configuring tiles.
- Ideas can't be backdated (but all other content types can), which also means that you won't be able to back-date the comments on Ideas.
- You typically won't have full control over the last-modified date. The REST API allows you to set this date on creation of content, but if you need to update that same content the last-modified date can't be set.
> Has anyone gone through the process of moving one entirely
> separate Jive community into another?
We do a lot of migrations, but most involve migrating content into Jive from other platforms. However we did have a client that went through this recently. Technology wise we handle a Jive to Jive migration in the same way that we would handle a migration from another platform.
> Off the top of my head I'm questioning how to handle duplicate users registered with both communities
I would start by first identifying how many duplicate users you have. If it is as few, you may want to decide how to handle each on an individual basis. If there are a lot of them you will usually want to pick one of the Jive instances as the "master", and when you merge a user profile you would use the data on that Jive instance over the other. Once you have a sense of how to do this logically it is just a matter of scripting that logic into code.
> transfer of points
Jive doesn't provide a REST API to transfer points, although in some cases it is possible depending on which gamification tool you are using. In most cases though we simply let gamification do it's thing. What I mean is, we re-post the content, comments, likes, votes, etc. as the original user, and the Jive gamification system is triggered normally and gives the user points for those actions. E.g. we migrate 10 of Bob's comments as Bob, and he will get points for those actions. The benefit here is that if the gamification settings are different in the two communities (e.g. one gives 20 pts. for a comment, the other gives 10) this allows you to normalize the points. For posting content as the user we make use of the Core V3 API - Run-As Feature & Signed Add-Ons feature.
> preservation of linked content within posts, etc.
When I develop my scripts for a migration they work like this.
1. Grab an export of the content to be migrated. Make sure that it includes the URLs to the content.
2. Import the content into the target Jive instance, the result of which are new URLs for the content.
3. Go back and update any content that had a link, using the original URLs from #1 and the new URLs from #2 as a mapping.
Typically we do this only for content, but it is also possible to do this for @mentions and other links as well.
My recommendation here is to scan (via code) all of the content that is being moved and generate a report on all links. You can then review the list to see what you are up against before deciding how to approach it. I typically generate a similar report for images.
If you have any other questions let me know, or you can DM me if you want to have a phone conversation.
Robert - Thank you for the thorough reply. This is so helpful. One follow up question I have is typically how long would a migration take with your method if you start from scratch (investigation, data collection, build and execute scripts, testing and troubleshooting)?
3 people found this helpful
For a migration of content using Jive's REST API (just to be specific), it all depends on the details, so there is no single number that I could provide. As for our process, we start with a basic questionnaire followed up by a call with the client to dig into the details of the request. And then from that we can create an estimate for the work.
Overall I feel like the average is about 40-60 hours, spread across a few calendar weeks. But like I said, it depends on the details, and some are more and some less. Also, that effort includes all of those things you mentioned (analysis, scripting, execution, testing) along with meetings, several dry-runs (to both dev and one to prod), and "tweaks" to the data. A "tweak" could be a reorganization of the data to different "places", or marking older questions as "Assumed Answered", or injecting additional HTML into the content.
The things that have the biggest affect on the effort is:
- The number of content types being migrated (users, documents, discussions, ideas, etc.). More content types means more scripting.
- The number of content items. E.g. Moving 100k content items requires more effort than 5k.
I find that every migration project is a little different, and each client has slightly different needs. So instead of having a pre-build Drupal-to-Jive migration tool we use a generic tool that we built in-house and then supplement it with scripting. This allows me to let the client drive the conversation on how they want the the content migrated instead of me telling the client, "this is what our tool does".
Anyway, if you has a specific project that you wanted to discuss, let me know.
Wow, Robert! Thanks for the thorough response. I really appreciate you chiming in to this conversation!
Thanks, Rob! #migrationmaster