Migrating from Jive to Microsoft 365 Webinar from February 2017

Danny serves as Vice President of Client Development at ThreeWill. His primary responsibilities are to make sure that we are building partnerships with the right clients and getting out the message about how we can help clients.

Chris Edwards

Chris is a Senior Software Engineer at ThreeWill. His area of focus is consulting in the development of Microsoft .NET and SharePoint technologies. His primary role has been development lead in recent projects. Project roles have ranged from Development/Technical Lead to Development Resource.

Kirk Liemohn

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.

Find this Podcast “Migrating from Jive to Microsoft 365 Webinar from February 2017” on the ThreeWill Soundcloud, Stitcher, and iTunes.

Ultimate Guide to a Jive to Microsoft 365 Migration

Transcript

Danny:	Welcome to this Jive to Microsoft 365 webinar. I appreciate you taking your time out of your busy day to come join us and talk about this subject. What we wanted to talk about today was sort of ten things that folks should know about migrating from Jive to SharePoint Online. In general, I’ll just say SharePoint Online meaning a part of Microsoft 365. I have two of my experts. I’ll call you guys experts, is that okay?
Kirk:	You can call Chris an expert.
Danny:	Oh, I have one expert here. I have Chris Edwards, who is a Senior Software Engineer for ThreeWill, and he is the chief architect of the initial version of the tool, and sort of was the grandfather of the migration tool and has helped it grow through the years. We also have Kirk Liemohn here with us. Kirk is a Principal Software Engineer. Kirk is the practice lead for our migration practice. Kirk has been very involved in various types of migrations, and more recently has been doing some job migrations himself, right?
Kirk:	That’s right.
Danny:	Awesome. I felt like getting us kicked off with, and maybe let me do a couple of logistical things before we do this. If you’ve got any questions, you can ask some questions in the go-to-webinar interface and I’ll look over there and check for them every once in awhile. If we’ve got some time in the end, which we probably will. I’m assuming this won’t go for the full hour. I’ll check those questions and ask you guys on the fly. I’ll make sure they’re not too tough questions. You guys were both looking at me like, “You didn’t pay me enough to do that.”
Kirk:	Bring it on, bring it on.
Danny:	We’ll see. If you have any questions, ask them. We’d love to have some interaction with you guys as you’re watching the webinar. So first off, I thought the, there’s a book that’s called “Begin With Why.” Why don’t I start with the why question. Why are companies doing this? Why are they moving from Jive to Microsoft 365/SharePoint Online? Kirk?
Kirk:	Sure, I’ll start, if Chris wants to add stuff he can. I think the main one is to save on costs. So, Jive is not cheap, not that SharePoint Online is super cheap, but Jive is not cheap. It has a recurring cost every year, and a lot of times companies want to go to SharePoint, they might already have SharePoint in house, or they might already have SharePoint Online. Of course, SharePoint Online, a lot of people think is relatively cheap. So I think when you look at that cost standpoint, you see, “Oh, well can we do a lot of what Jive does in SharePoint?” You can do quite a bit of it. So they think, “Well maybe we should save on costs by having everything in SharePoint. And another aspect of that is if they’re going to SharePoint Online, they see a lot of what it has to offer. There’s kind of new features coming out over time with teams and Delve, and just different types of things that are coming out, groups, those things. So they want to take advantage of that. They think, “Well, if we just start having that as kind of our main place to collaborate and not have a separate Jive environment, then we can hopefully take advantage of more of those features that are out there at SharePoint Online.”
Danny:	And there’s even, I mean there’s a lot of redundant features with Yammer too, with people seeing what Jive does with the whole activity feed. I think probably a lot of people are saying, “Well do we want to use Yammers with our way of interacting with each other socially?”
Kirk:	Yes.
Danny:	Yeah?
Kirk:	Yeah.
Danny:	It’s probably they’re, they also see a lot of, it seems like a lot of the features that are coming down the pipe from Microsoft 365 seems to be getting faster, not slower. I know for us it’s one of those things, and this, initially, when you were looking at Jive versus SharePoint, it was, Jive was coming up with quarterly updates, so they were pushing software out quicker, and SharePoint had the three-year cycles. And it was like you’d wait every three years to get your new set of features, but I think in a lot of ways it’s reversed a little bit. You’re getting pushed out more features from SharePoint. So you’re not having to wait the three years. You’re constantly getting updates, so as far as innovation goes, there’s a lot of things that Microsoft is really pushing with regards to SharePoint Online. Yammer seems to be pretty-
Chris:	Nah, Yammer is not changing that much I don’t think.
Danny:	Yeah, it’s pretty stable. Tommy and I talked about that a lot. We think the Yammer team probably had more to do with changing how they deliver software than the actual Yammer software itself.
Kirk:	Right.
Danny:	You’re really seeing a lot of people saying, “Well, I want to take advantage of the latest software, or whatever the latest software trends are,” I turned into Elmer Fudd there. The latest trends are in software, and we’re seeing a lot of those come from Microsoft 365.
Kirk:	Yep.
Danny:	There’s also, folks, if you search on our site, or Google business case Jive three wheel, you’ll see a blog post that I put out which was sort of the business case behind why I see people doing this. That gets updated all the time, as far as what the story is around that. Numero two, let’s go with, with these projects, we like starting things with a workshop. Describe to me what goes on during one of these workshops.
Kirk:	Yeah, and Chris, if you want to chime in, feel free, but I’ll start out, this is Kirk so. The first thing I think we want to do is understand what the vision of the client is, what do they want to get out of this, why they want to move, what is it they want to move. And then, after you kind of understand that overall vision, then you want to dig in deeper, so you understand their current environment. What do they have currently in Jive, what version of Jive are they using? Is it the one that’s up in the cloud? There’s hosted versions of Jive, there’s on-prem versions of Jive. And ideally, before we even do the workshop, and this has happened many times, there’s sometimes it doesn’t happen before the workshop, we can do an inventory of what they have in Jive before the workshop.
	That’s the ideal scenario. And if we do that, we can review what we know about their inventory. Our inventory will give them counts of different types of contents, counts of places, and we can kind of slice and dice that different ways, and that’s very, very useful. So if we see, for example, they’re heavy users of Jive collaborative documents, then we can kind of tailor the migration, or at least tailor our discussion in the workshop on here’s what happens with a Jive collaborative document when you migrate. We want to understand what customizations they have. Do they use heavy branding in Jive? Is that what they kind of want in SharePoint? Do they use Jive plug-ins, or widgets, or tiles? Those are important points to discover. And with all this stuff, you need to understand user identities and how that’s going to transfer from Jive to SharePoint. Typically, you have the same email address as your log-in. If you’re going to SharePoint Online especially you’ll use an email address, but Jive can or doesn’t have to. And so you want to understand if that’s going to match and how that’s going to work.
	So you also want to understand their current state in SharePoint. Are they going to a Greenfield SharePoint? Are they going to SharePoint on-prem, Online? What version of SharePoint? Do they have a lot of site collections already? How do they do search in SharePoint, if they use it already? And of course, user identity is there as well. I’m going to continue talking, I’ve got more things to talk about. In this workshop, you want to show them a demo, at least screenshots of what the tool can do. So we’ve got a set of tools we’ll talk about, I’m sure, and these, we want to show them what, start setting expectations early of what the tool can and can not do. And what are the supported types of contents from Jive that we can migrate, and what are the types that aren’t supported, and does that meet their needs? And finally, with the workshop, we want to come out of that, getting a good understanding of scope. What is it they want to migrate. They aren’t going to have all the answers right away. What is it they want to migrate, what types of content they want to migrate, how quickly they want to migrate, and do they have anything that they want migrated that our utility doesn’t cover, or certain aspects of it that it doesn’t cover. So that will help us come up with a timeline and budget for the whole project.
Danny:	Nice. That’s usually, I know one of the first things I ask folks to fill out, if possible, is a pre-migration form that’s up on our website, and one of the things that drives along these projects is the timeline, because typically you have a hard-date that’s out there that you’re trying to get people migrated over by for that date. And we like to be eight to ten months out before that date, but more realistically, you guys have seen, it’s been, you know, we’ve got a date set three to four, or even sometimes less than that. And so you’re almost trying to decide, you know, really trying to deal with, normally our projects aren’t this way, but you have a hard, basically you have to do something by a certain date. You have to make sure that key things are done by that certain date, and that probably modifies a little bit as far as how we go after these projects.
	But just interesting to see that that’s typically for us, the timeline is driving a lot of this. Now, from our workshops that we’ve done with the Jive stuff, have you noticed any, have people been using a lot of plug-ins? I know way back when, we created an app for Jive. It was like a SharePoint list app for Jive. Are people, you know, do they have a lot of customizations and are they wanting to move those customizations over, or is it pretty much we just want the core content and that’s all we’re interested in moving?
Chris:	From what we’ve seen, there’s been very little customizations of Jive that we’ve had to be concerned about.
Danny:	Okay.
Chris:	For the most part it’s the pure content, the documents, the discussions, the heavy content that people don’t want to lose. That’s really what we’re trying to retain in SharePoint.
Kirk:	But I’ll add that our, what I’m working on now, they care about these homepages and these overview pages, and tiles, and widgets that Jive has that can be on these pages, and these are very custom things. So that’s significant customizations to be concerned with.
Chris:	We’ve thought about some of that stuff and how we deal with it. Every customer is going to look at that a little bit differently.
Danny:	One of the things I don’t see, you probably also talk about, I know with some the migrations, we’re not only just moving them over to SharePoint, but we’re also, they’re using something like BrightStarr’s Unily, or some other sort of UI that’s on top of SharePoint as well. It’s probably, you’re starting to set some of those expectations as well during the workshop.
Kirk:	Yeah, that’s a very good point. We need to understand if there’s other parties involved that you care about, some of the third-party missions, Unily. Do you care about Yammer? Do you have a different media server or something for your videos? We’ve definitely seen that more than once. So those are things that do need to come up during the workshop so we understand what the real requirements are.
Danny:	So we come out of that with a scope, timeline, budget, decision to be made about going after this project, and then the phases are sort of the workshop, and then we have a pilot phase, and then a production phase, and then a sustainment type of phase that we go into. Good stuff. Next question about our own utility. I was calling it a tool earlier. I can’t call it a product, because it’s not a product. Tell me about this utility that we use for migrating customers.
Chris:	Actually, we’ve got a set of utilities that we like to use. The first one I think is actually available for download on the website, the migrator utility. That’s kind of the initial one we like to get folks, essentially in the Windows-based utility, someone can put in their Jive URL, put in their username and password, and essentially hit the run button, and it goes off, and it basically uses the same public rest-API that Jive puts out there that our other utilities use. Then it gives us a sense, is there any issues with running commands, running the API with your username. Is there any issues with running that? We find issues quickly. But it also gives us a list, an account of how many places, how many we basically, how many repositories or places that a particular customer has in their Jive. So it gives us an overall size. What are the counts of different types of groups and spaces, and projects, blogs, those are the main containers or places, if you will, in Jive.
Danny:	That’s the trial version of Migrator, which is downloadable off of our website, correct?
Chris:	Correct. That’s kind of the initial utility most folks will see, just to kind of get that initial sizing. The main utility that we have is JtoSP, for Jive to SharePoint. It’s a console-based utility, it’s originally written to keep things simple, very console-based. Doesn’t need a UI, because it’s designed to focus in on purely getting content out of Jive and getting content into SharePoint. What it actually does, quite a bit of the work of our process. One of the things it does, I mentioned the public API from Jive. It does leverage Jive’s rest-based API, so I use the public API, which is important. One of the first things we go after, and we kind of mentioned the workshop earlier, one of the key things it goes after is it produces an inventory of detail from Jive. Things like a list of all the people that are in Jive, all the places, again, places are the groups, spaces, projects, blogs. Then, within the places, it actually does what’s called a shallow pull of content for those places.
	And I’ll leave the term shallow, deep, I’ll kind of explain that here in just a minute. The whole idea is that we want to be able to get that content in a form that can be presented in the workshop or presented to the customer, and actually really detail out when content was last touched per place, how much content is really out there, really kind of helps us understand how to plan for the migration itself. Shallow is basically saying, “I want to go after the content.” By shallow means it just pulls, at the API level, it just basically pulls some of the basic information about the places. It doesn’t go down deep and do multiple calls. It doesn’t like, if you’ve got a person, it may find that person, but it may not find what roles that person is a part of. It doesn’t make the extra calls to do that. It’s designed to do a quick hit against Jive to find that information so we can do
Danny:	And the output of this is an Excel spreadsheet for the shallow?
Chris:	Yeah, so that’s part of it. The primary output is it builds our database.
Danny:	Okay.
Chris:	One of the things we do, you kind of mentioned earlier about this whole timeline aspect. A lot of customers come to us during the last minute trying to migrate off of Jive, right? What we try to do is we pull this content, this inventory content into the Jive, into a SQL server database, and into the file system. And we do that so that we can quickly get the content out of Jive. Let’s say someone is being turned off in the next week of Jive. We can get that content in our database in the file system, and then we’ve got what we need to do the migration.
Danny:	And that’s doing a deep or shallow?
Chris:	Well that’s more of the deep side, but the shallow pull is going to get that inventory piece. The deep pull that you’re talking about, that’s when we go after and get all visible binaries. That’s where we get all the sub-calls. Like, as I mentioned earlier, we go get a person, we get their roles, we get all the different aspects of it. But I mentioned this, because more from an architectural perspective is that we are able to use this utility to go after, produce this database, produce the file system. We can go after that stuff first, get everything off of Jive, and if for some reason they’re shut off in the next day or two, we’ve done everything we need to do for the migration. It kind of ties into, oh someone’s, they need to get this done quickly, we have the ability to do it.
Danny:	So a pull usually takes a couple of hours, a day?
Chris:	It really depends on how many places. It can take days.
Kirk:	Yeah, it can take days.
Chris:	It can take days depending on how many places we’re talking about and how much content we’re talking about. But we’ve got ways of kind of going after that. The utility does try to do things in parallel, does try to do things as efficiently as possible to pull that information off of Jive. So that’s one aspect of what the utility does, this JtoSP utility. Another aspect is what it is also designed to do is it’ll, it’ll take that inventory, let’s assume the customer has gone through and done what’s called a mapping exercise. You mentioned the spreadsheet earlier. We do produce a spreadsheet for that inventory that kind of says, “Here’s all the stuff, all the places that are out there. Here the customer needs to see this inventory.” The customer typically goes to and says, “I want these particular places, and I want them to be mapped to this place in SharePoint.” There’s an exercise we work on with the customer on to do that, so that mapping exercise. Then, the utility takes that mapping and says, “Okay, I need to validate, do these SharePoint sites, these target SharePoint sites we’re going to push content to, do they exist?” The utility verifies that where we are intending to push content, does the site exist, and do I need to push permissions or adjust permissions on these sites, it can do all that work.
	And then, two other main pieces of activity that this thing does. We do what’s called a transform phase. So we take the content, as it was pulled from Jive, and we do what’s called a transform. What that basically means is saying it’s preparing the content to be pushed to the SharePoint. So you may find in this content, you’ll find a lot of links to, from Jive content to other Jive content, or links to Jive profile information. Things that reference Jive in general, we take and convert that to SharePoint versions, or SharePoint speak. A Jive person profile URL may go to now to a Yammer profile, or it may go to a specific SharePoint URL that we care about to represent that person, as well as all of the documentation and all of the links get converted into something that SharePoint understands.
Danny:	Nice. I love how each time you said transform; you were doing it like a robot.
Chris:	Yeah, you like that you can’t see the phone, but I’m moving. I’m moving as I’m talking here.
Danny:	You can’t see it but, we were doing a bit of transforming with his hands in the air.
Chris:	Transformers, no.
Danny:	Sorry, go ahead. Number four.
Chris:	Yeah and so the last main thing that the utility does, and I know this is a lot of information, the last main thing is it can take in this prepared content, and it actually will push it to SharePoint. And so it actually, that’s when the actual content makes it’s way. A couple other variations on this. We are able to do what’s called deltas. So let’s say we push this content to SharePoint, and folks are still using the same place for their content in Jive. We may want to stage this up in SharePoint. We can do what’s called a ‘true up’ or a delta, which basically says, “Okay, right before we’re ready to switch it over to using SharePoint, give me whatever deltas and whatever changes have taken place in Jive, let’s get them into SharePoint. So we can kind of hit it multiple times to make sure it’s in sync, and then someone can turn off Jive.
Danny:	Brilliant.
Chris:	So that’s there. And there’s a few other miscellaneous actions that probably more detailed than anyone really cares about in this particular call. Some other utilities that we do, we have a couple, actually three PowerShell utilities that we use. One is called New Sights, and it’s really helper PowerShell that kind of helps customers basically provision their SharePoint site collections, things that we’re going to be targeting for the deployment from Jive to SharePoint. Folks don’t necessarily have to use this. It’s just something we provide, and we provide scripts that basically provision those site collections. And then, we’ve got another set of utilities that kind of work hand-in-hand. One is called Validate Hyperlink. It’s also a PowerShell. And Replace Hyperlinks.
	So, Validate Hyperlinks, what it does is it goes after, after we’ve migrated, post-migration, pushed up to SharePoint, we run this Validate Hyperlink to say, “Okay, all of the links that are present in the content, we look at all the images, all the links, do all they jive? Do they all work?” term in there. Do they all work and do they not rely on Jive anymore? Do they work without Jive in the mix? If they don’t, we find the report for those that are failing, and we use the Replace Hyperlinks utility to make fixes. That’s kind of our remediation efforts. That’s our main remediation, and then we go through, there’s another set of processes, more processes and queries that we use to validate counts and make sure that things that were in Jive are now in SharePoint. We make sure that the counts match and things match up properly. That’s the gist of it.
Kirk:	Just to mention there that, a huge thing that this tool does is dealing with links that you have inside of Jive. So if you’re writing a Jive collaborative document, it’s very, very normal for people to create a link in there that points to some other Jive content that’s not that, that’s you know, it can be pointing to another Jive collaborative document, or a Jive blog post, or something. And something within Jive, the moment it does that, our utility, that’s part of the transformation process Chris was talking about, it transforms those URLs to be the URL that’s going to be or already is in SharePoint. It can be inside of a totally separate Jive place, going to a different SharePoint site collection or site. But that’s what these links are all, they’re all fixed for.
Chris:	Clean all that up.
Danny:	Impressive. Well done. I know this has grown through the years. It’s sort of the tool, you know, starting off, it started a long time ago, and it’s sort of growing, but it’s amazing how far along it’s gotten. So good work there. So for you, Kirk, what type of contents, we’ve been talking a little around this, but what are the types of contents that we migrate?
Kirk:	Yeah well, first off, Chris has already alluded to the different types of places in Jive. There’s spaces, groups, projects, and blogs. There’s some differences with those and how they work, but inside of those, you can have what we call content, or sort of first-level content. The big ones are collaborative documents, which are kind of like a Wiki page in SharePoint if you aren’t familiar with Jive. There are binary files, which are just files like word documents or PDFs or Excel files. There’s also videos and photos, and then there is discussions, so it can be similar to like a Yammer discussion, or a SharePoint discussion, list discussion, those types of things, that’s in Jive, and then, blog posts. And we migrate all of those.
	So those are the big content types. And there’re some other minor content types that we currently don’t, but those are the big ones that people use a lot. And we do migrate those, and then, within each of those you can have comments or messages. For whatever reason Jive basically says if you’re commenting on a discussion it’s called a message. But you’ve got comments on these blogs or collaborative documents, or what have you, and we migrate those. You might have attachments or embedded images on them. We will migrate, if we’re migrating a whole Jive group, we’ll migrate the members of that group, and put people into basically different SharePoint groups for that SharePoint site. I just talked about links, so we migrate those links that way to Jive content so they’re now transformed to the new SharePoint links. And then, things like timestamps, items, and the created-by, modified-by, those types of things.
Danny:	Those are migrated?
Kirk:	Yeah, yes.
Chris:	Yep.
Kirk:	So when you’re looking at SharePoint, and you see the blog post was created by so-and-so at such-and-such time, that’s going to be when it was created in Jive. And you know there’s cases where the user may not map over for whatever reason, maybe it’s a user that’s now left the company, they’re no longer an active directory, so there’s some weird scenarios like that you have to get around, but for the 99.9% of them, things are going to migrate over with the user and the timestamp. And then we will archive some things that we don’t migrate as well, an example of that is Jive has the concept of categories and tags. We archive that, so we have that information, currently we don’t migrate it.
Danny:	Okay, let me do the last little part. The part that we don’t migrate, I’m going to do this like a lawyer speak at the end. This is the very last part of the commercial right now. Won’t migrate-
Kirk:	We’ll both say it. Many times, our customers don’t care about these things, and these are usually not used a whole lot. An example, one of these items, I think, is a poll, sorry, I’ll let you say it.
Danny:	No, no, no, go ahead.
Kirk:	[crosstalk] like polls, the last inventory I was on, I think in their whole Jive, I could be saying this wrong, but I think they had two polls. You know, they didn’t have many of them, but polls might be the wrong one, but they had a very small number of one of them.
Danny:	Are they stored in the SQL server database, or are any of these things available for later on? If they need to go.
Kirk:	Some of them are, yeah.
Danny:	If someone said, “We had a poll, what did we ask in that poll?” Or yeah, those sorts of things? So some of them are.
Chris:	Why don’t you rattle off the list?
Danny:	Sure, okay, here we go. We’re going to see how fast I can do this. Ready, on your mark, get set. Polls, tasks, calendars, status updates, private messages, shared links, bookmarks, announcements, streams, overview pages, home pages, tile switches, category stacks, properties, personal documents, space, members, security. Ding!
Chris:	Of that list.
Danny:	We’ll migrate any of these for the right price.
Chris:	But we are capturing.
Danny:	If somebody needs to migrate this, we need to add it to the tool, then we can add it to the tool. It’s just a lot of these, the value of doing the migration hasn’t been worth the cost, right? That’s typically what we’re talking through.
Chris:	Well, it comes down to, and I think we’re probably going to talk about this in more detail later is that SharePoint and Jive are not the same animal. Right? These things don’t really mean as much, or don’t mean actually anything in SharePoint, right? And a lot of them are, like for the case of a poll, that’s very time-sensitive, you know, a lot of times these things are done, they’re done. They’re completed, they’re done.
Kirk:	Status updates are the same way.
Chris:	Status updates we actually do capture in the database. We do capture tasks in the database and the categories we capture in the database.
Kirk:	Shared links.
Chris:	Yeah, yeah. Shared links as well. Those we actually archive, if you will, or capture them. We just don’t have any mechanism at this point to play them forward in SharePoint, because they really don’t translate into SharePoint. There are ways of representing them there, but nothing has been compelling enough to our customers to say, “Yeah, I want to go ahead and do that.”
Danny:	It looks like we’ve branched over into question number five, which is, “Do we create an archive?”
Chris:	Yep.
Danny:	Basically we do.
Chris:	We do. That’s kind of what I alluded to earlier is, the way the utility, the way the whole architecture has been designed is that the archive is kind of banked in. So when we pull content out of Jive, when we do that deep pull of content, we can essentially do that for all places. And essentially, what that does is it puts it into a SQL server database, and for all the binary files, things like images, word documents like Kirk said earlier, Excel files, PDFs, that sort of thing, they’re stored in the file system in a very structured way. The database actually has pointers to those files. Typically what we do is we put all that together, we ensure that the customer has enough space to be able to retain all thos information, and that we can potentially walk through it with the customer, so they can understand how the database is organized, what the schema is of the database, how do we actually find these collaborative documents, or these discussions, or individual images. If someone wanted to know how to go after that. Maybe they didn’t migrate something to SharePoint, but they’ll want to actually look at some content that was pulled out of Jive at a later date. How do they go about doing that? So we sit down with a customer and show them actually how to access the database and be able to find that content in the database and their files.
Danny:	So we sell them the database at the end of the project, right?
Chris:	We just hand it over? What is wrong with us.
Kirk:	It’s already there. It’s already done paid for.
Danny:	Yeah you done pay for it, cool.
Chris:	So that’s how that’s done. Again, we try to get the content. We want to be able to do stuff with it and be able to migrate it, but at the same time, why not use that same phase to archive it, so same process.
Danny:	Question six, good, we’re half, we’re 30 minutes in. We may use up the full hour. Nice, okay, that’s fine. But this one I was sort of queuing it up a little bit earlier, which is the different phases of the project. I mentioned, workshop, which we covered in some detail, and then the pilot, and then the production, and then sustainment. Tell me more about these.
Kirk:	Sure. First off, before the workshop, we like to do an inventory, as I mentioned. That, sometimes there could be issues getting connectivity to work, and stuff like that. So that can take two to three days sometimes. If there’s no connectivity issues, it can be a day, basically, it’s not as bad, but many times, there’s connectivity issues. And that’s just because of the security and how things are set up for some of our clients, but it just depends. And then, the workshop itself is two to three days. We want to sit down with you and discuss what this is going to be. It’s a lot of, like I’ve seen three, four hour sessions as one way of doing it.
Chris:	Not two full days. Not two to three full days.
Kirk:	No, they aren’t full days, right yeah. And it helps us, as we learn something from the first day, maybe we can show you different parts of a demo or something the next day. Then, after that workshop, that’s when we’re going to kind of come up with our scope and budget, hopefully. And one of those things that may be part of that and may be in scope is maybe updates to our tool. So that takes time, right? And what those updates are totally depends. You rattle off that long list of items that are not supported right now, and you get the big ones that we think people really care about, and those other ones, maybe they’ve got an idea of where they want that to go.
	And We could talk about what that would mean. So then, after that, or at some point, it could be before or after those tool updates. If there’s significant updates, we’ll want to actually do more than one PoC, but at some point we need to do a proof of concept. And that may take a week or two. That’s going to verify, access, complete access to Jive and SharePoint. We’re basically going to be running sample migration of several places from Jive to SharePoint, and we’re going to basically, end to end, we’re going to see what happens.
	And then, some people will get to see that from the client. They’ll want to take a look at that PoC and what the output is. But after that is a pilot, and that’s where you really get the business users and get them to, get their input. That’s usually a couple of weeks to do a pilot. That pilot may have iterations within itself, right? So a pilot, you might do one, you really want customer’s eyeballs on that. You want to make sure that people are seeing what they expect to see. Do they agree with it. Is there any issues, is any content missing. Really make sure there’s nothing that’s going to surprise the end-users of this particular. And if there is, and a lot of times there’s stuff that we have to tweak or adjust, we typically do another iteration of a pilot to make sure things are corrected just so they’re happy. It’s all part of the process.
	Yep and then finally is production. Now, if there are a lot of tool updates and there can be like multiple pilots and multiple PoCs. You can be certain that we’ve seen that, but in production that’s where you kind of want to be full on moving stuff from Jive to SharePoint. But you know, if you’re going to SharePoint Online, SharePoint Online can throttle you if you’re going too fast, so. And Jive’s going to have some limitations on how quickly you can hold their content as well so Chris talked before about a shallow pull. We also, when we do a deep pull right when we’re about to go to move a Jive place from Jive to SharePoint. So that’s when we pull from Jive further, if we don’t pull everything way before hand. If you want like the latest update to Jive when you’re moving someone over, you’d do that last minute. And that time totally depends, you know. I think of, one way of measuring is say 300 to 500 places, Jive places, per week, but we’ve seen, I know we’ve seen one place that took, I would say it was three days. That’s just to move one place. Now you can do stuff in parallel, but that was a huge place. It depends. when we get inventory we’ll have a better idea of what’s possible.
Chris:	And I guess the key thing here too is that it comes down to that timing, right. You want to have enough time to be able to move this stuff, you know, from our transform database and then into SharePoint. Sometimes it takes a while because of the throttling, because of other things that can affect your performance. The nice thing though is that we’ve got the time, we move this stuff into SharePoint. We let folks tweak the tires a little bit. We can do that delta process with that true up process to kind of bring over the changes, so that allows that kind of like, “Let’s get everything up to speed. Let’s get everything in place.” And maybe the weekend before you’re converting over, you do your true up process and flip switch. There’s ways to do it now.
Danny:	I know, sorry this is a bit sideways, but I know some of the customers, they get it sort of as the wrapping up, using Jive to get a back up of their Jive database and have we ever looked at, have we ever had to use that sort of as the thing that we’re pointing to to migrate data at all?
Chris:	The actual Jive database?
Danny:	Yes, the actual Jive database so pointing that the, that database as opposed to a rest API.
Chris:	No.
Danny:	We haven’t had to do that?
Chris:	No, that’s more of a, you know, we typically recommend that other guys still ask Jive for that back up just to have that.
Danny:	Just to have it around?
Chris:	Something extra. Yep, just to have it. Cause that allows them to spin Jive back up, right? If they ever, for some reason needed to. It’s more of that extra guard. But, no, we’ve never had to.
Danny:	I just wonder if that ever is going to be the situation for us with in depth occurring to us. Who knows? We haven’t had to exercise it quite yet.
Chris:	Well so, this is from an experience perspective we originally, this set utilities was usually written for us to do our own Three Will migration.
Danny:	It’s where all good things come. You scratch your own back.
Chris:	Right, so when we were first doing this we had the . We did miss some stuff, right? We didn’t catch everything so I had to go into the Jive database back up and learn how to do that.
Danny:	Oh really? Interesting.
Chris:	So I’ve got some experience doing that, but we’ve tried to, we’ve worked hard to not have to do that. I’ll tell you that much.
Kirk:	And if Jive Cloud you’re not going to have access, direct access to that database, so.
Chris:	You definitely have to have
Danny:	Yeah you would have to have them create the archive.
Kirk:	I don’t know what that process it, but they’ll do it for you.
Chris:	If possible, but we try hard to make sure that that’s not necessary.
Kirk:	But one thing we do do, is we have to had projects before, and I know Chris has done this directly, is we come back to a client and they say, “You know what, we want these other 500 places to be migrated now, I know you didn’t migrate them before, but you archived them, so you can migrate them, yeah, right?” And then we say, “Yes we can.” Cause as long as you got our database, the database migration tool uses, then we can migrate to SharePoint later as long as we did archive that content.
Danny:	Nice, that’s great to know. It’s good to know you don’t lose it, that it’s still available for you. So I get the easy one, of course I give the easiest question to myself, right, which is how much does it cost to do these migrations. Simple answer, we do the workshop is a fixed price, right now it’s $7500, subject to change, I’m going to have my own lawyer speak to that, it might go up, especially if we’re getting large backlogs of these workshops then we may end up increasing that price. The typical migration, since we’re doing a bunch of these, the average size of these, is the cost for the pilot and the production phases is around $150,000, so what that tells me is that typically we’re working with mid to large size Jive implementations. For the smaller implementations I usually will coach them through or talk them through doing some manual migrations or, “Do you really need this.” Or we’ve been somewhat staying away from them and looking at only some of the larger clients who need to do these migrations.
	So if you ask me right away, which a lot of people do, they ask me, “Can you give me a quote for doing this number of sites.” If we don’t have the time to do the workshop first, which the workshop gives us an updated estimate, I’ll just tell them, “Use 150K as the number.” Given the limit to the amount of time, and especially we end up, that’s around 1000 places when we’re working with that. If it’s more I’ll end up jacking that number up, but at a high level that’s what I want people just to have sort of an overall sense of what the budget is, and if that’s too high of a budget and doesn’t seem to make sense, it’s probably cause you have a smaller implementation of Jive and I completely understand, but I think we’re more focused around large implementations, right. So done with that one. What are some of the, and if you need to create a business case for this, or talk through why people have done this and some of the benefits, or want to talk to a customer about the benefits of doing this, we have all of those things so feel free to reach out to me through the contact us page, we can hook you up with the right people.
	What are some of the biggest takeaways from these type of migrations? And I guess this is open to the two of you guys, from doing these for now years, what have you seen as, are some big take aways?
Chris:	So I mean I would say one of the big things is just to understand that Jive, I mean I’ve said this already before on this call, Jive and SharePoint are just not the same. They are different animals, they have a lot of the same elements to them. It is a, SharePoint offers a great opportunity to consolidate a lot of this Jive content, but they’re definitely not the same. So you have to make sure you plan for, understand your content types very well so that you know kind of where the stuff is going to go. And that comes down to, I know we’re going to talk a little bit more about this, but it comes down to just time. Give yourself time to understand this stuff. I can keep going, Kirk, unless you want to-
Kirk:	Well along those lines, you just need examples. Jive has something called streams, SharePoint doesn’t have really that concept per say. Jive has shared content where you can share stuff from one place to another but it only exists in one place but it’s just available from two places. SharePoint doesn’t really have that, I mean they have links but ideas, missed ideas on the dot cover list that think some cool ideas. SharePoint-
Chris:	And you usually don’t see that, you just pretty often end up seeing that really affecting.
Kirk:	So they’re not, like for like is a term I heard a lot and I don’t like it. They are not like for like.
Danny:	We don’t like “like for like.”
Kirk:	Yeah, it is apples and oranges. There’s some stuff that makes a lot of sense to move over and there’s some stuff that just doesn’t work well, you’re trying to force it in when you want to put it in SharePoint. And if it’s something that’s very important for you, then you got to really think hard about, “Well does this even make sense for us to move to SharePoint.” Or, “What are we going to do with this content we need, we can’t do this with SharePoint.” Segway to.. So you really have to think hard about those things if they’re important to you. So I mean we can talk about-[crosstalk].
Danny:	Other takeaways you guys have?
Chris:	I mean we’ve got one here, but there’s another, there’s opportunity to let us clean up the content too. When you’re moving from a system that’s been around for a while, there’s going to be some content to.. a lot. And there’s things that may make sense to bring together from multiple places, multiple spaces in Jive into one location in SharePoint, it’s basically a consolidation exercise. So this is an opportunity to be able to do some of that, not that you have to, but it is an opportunity for us to take advantage of if you indeed want to do that.
Kirk:	Yeah and finally when you do these migrations you’ve got to make sure you’re communicating with, not only IT, but the users and I mentioned this before on SharePoint-SharePoint migrations, just you want to get your stakeholders involved. Everyone needs to be notified as to what’s going on here. And we’ll say it several times, communication is key. I mean you’re moving people’s around, so people don’t tend to like it when you move their stuff and so you want to make sure they, everyone’s on the same page, everyone knows what’s going on and we have ways just kind of helping with that as well. So some of the stuff we can kind of share in the workshop and also in the actual migration, how do you actually, when do you communicate with folks, how often do you do so, we have techniques that help with that.
Danny:	I think that’s good that you mention that, I mean one of our brand promises is around control which is we want the client to feel like they’re in control of what’s going on. I think a lot of this types of things are important cause it feels, it does feel like you’re moving somebody’s, you’re moving the place where they collaborate from one place to another and it can, we can do these projects technically correct, but if we don’t get the communication piece down and also along with that communication, the expectation management from folks, then it can definitely fail. You can do a perfect technical implementation but then it fails if you don’t get the communication and expectation management right. Yeah if they expect to see what, “Here’s what it looks like in Jive, I expect it to look exactly the same in SharePoint.” That’s the wrong expectation.
	I know we’ve also, along those lines, we to address that issue, have done stuff where we’re working with the Unily’s of the world or other products to make it a little bit more Jive like and also done, I know some of the clients had us do some branding or some things to make it feel a little bit less jarring as you make the move. So I think if that’s something that’s important to you, that’s something we would talk about as well, is if this expectation of moving from this to this doesn’t work, what are the things that we can do to make it work for you guys.
	All righty, number nine, getting there. What advice would you give someone who was looking at this, this is probably similar to insights, but what advice would you give to someone who’s doing this? Besides, “Don’t do this alone.”
Kirk:	One you kind of already mentioned, is starting early and make sure that we have time to make this happen for you. If we are rushed too much, then we’re going to have to start cutting corners. “Oh, maybe we won’t move over this type of content.” Or, “These places that haven’t been touched in the last year, we won’t move those because you’re giving us a month to do things.”
Danny:	If you come to us a month ahead, it’s like my kids say, “You get what you get, and you don’t throw a fit.”
Kirk:	So you want to start early.
Chris:	And we mentioned the communication portion, it goes back to that again, we’re going to keep reiterating the same thing. I have another thought related to this one, but I lost it so I’ll let you pick it up.
Kirk:	That’s fine, yeah I mean we’ve gone over communication. I mean the other one that we’ve already talked about several times is a proof of concept and a pilot, these are key pieces of our process and we can’t cut those. And they’re going to happen whether you say they need to happen or not, because we’ve got to basically prove that we can communicate in your environment and pull stuff from Jive and push into SharePoint. And then we got to actually do a site or two that we get some feedback from before we start the full on migration. So that’s got to happen, and we need to plan for it, we need to make sure you’re aware of that part of the overall timeline.
Chris:	Yep, and then a couple of other things. So understand the content types. So you really need to understand what Jive content types are out there. What are people really using them for. What are they using, what are they using them for, understand what your actual user base is doing in Jive, right? So that really kind of in the work shop we try to find out, “Okay do we need to have the customers, do we need to make customizations to SharePoint and or the migration utilities to be able to handle those .. or those very specific use cases.” I think customizations to the tool, I mean realistically someone can go and build, cause we use the public Jive REST API, someone could go build something that’s very, something similar to this. But I mean there’s quite a bit to understand and it’s very easy if you’re not careful to make mistakes, based on how they structure their things back out of Jive and you’ll, you can build it yourself I guess is what I’m saying, but you’ll run into some in that process.
Danny:	I already have two examples of where someone once tried to build out the tool themselves and they failed. So it’s not, I’m not saying it can’t be done, it can be done.
Chris:	Oh yeah, it’s a public API, so yeah.
Danny:	But there’s been years we’ve been doing things with Jive, for now over five, six, I don’t know how many years, we probably been longer than that. Probably seven years where we’ve been exercising stuff with first building the connector and just sort of working with it through the years that there’s a lot of built in knowledge that has gone into it as well.
Chris:	I mean it’s kind of giving us just a little plug for why would you choose us to do this, I mean we’ve done it. We’ve pulled, we’ve migrated quite a few customers now and we’ve got some experience and the code has been poked at quite a bit.
Danny:	And I didn’t go through this earlier with the cost, is that we end up packaging in the cost of the tool into our services and so when you’re engaging us, you’re engaging us, what I want to say is for a solution, which is to migrate you from Jive to SharePoint Online and we end up, the pricing for all of this, we’re not a product company, we are working with a product company right now to see about transitioning what we have as a tool over to them, so it could be bought more like it’s a tool, but we’re in the middle of doing that right now. As it stands right now, you’re engaging us, our expertise, our tools that we have, and hiring us to do this migration and the pricing is based off of what our services cost is.
	Last one, we’re 10 minutes left, we have one question left. Well done guys. You’re working on a, and I also saw a question, which I’ll have a question for you as well, which is great, wonderful to see that. If anybody else has questions, please go ahead and ask them through the go-to-webinar interface. You’re working on a white paper, I’m plugging your work, white paper here, plugging it. You’re working on a white paper back complex migrations, how do these types of project, the Jive migrations, influence what you’re writing in the white paper?
Kirk:	So the white paper is focusing on SharePoint to SharePoint migration, but there’s plenty of similarities between when you go SharePoint to SharePoint and when you go from Jive to SharePoint. And they’re usually the big idea or process type of thing, so your overall process has to, you want to start with a workshop, cause we want to understand what you’re all about, what you need, where you are today and we want you to understand what we can do for you and what some of the caveats are and maybe what things we can’t do for you.
	And you know I’ve talked about PoC and pilot several times already over the last hour, that’s true in both cases, and it’s extremely important and we talk about those and all of this in the white paper. And just we might word things differently in terms of our process when we’re doing SharePoint to SharePoint we tend to use terms like assess, plan, verify, and execute. But those transition over to the same stuff we’re doing here. And as Chris has said several times, the need to communicate is top on the list and that’s true in the white paper as well. That’s pretty much it.
Danny:	So guys, couple of questions for you, and the first is, “Do you guys have an intranet in a box, that’s atop SharePoint Online that we can map and migrate our selective Jive content into.” Great question and up to this point the answer is no to that, we don’t have something where we’ve built something on top, basically an intranet in a box on top of SharePoint, the reason being there’s probably four, five, maybe six different options that are out there that we’d love to talk you through as far as what’s available out there on the market place for this sort of intranet on top of SharePoint. We’ve mentioned one that we’ve been working with on a couple of projects, which is BrightStar’s Unily. There’s also other intranet in a box products that we’ve been talking to those companies as well. So rather than having something that competes with those, we’ll work with whichever one you want to select and so we will go through the whole process, as part of the workshop we’ll talk through the process of, “How do we migrate that content.” Maybe not just into SharePoint but also into some other data stores, so some other places that you want to have the content go into.
	So, great question, one of those things that we’ll be, we will work with another third party to, if you want to build out, use one of the intranet in a box products, then we’ll sort of work with you to select the right one if you want some help with that, or just point you to the ones, and I’ll actually follow up with an e-mail on what some of those options are. I’ve been meaning to write a blog post on what’s on there, I know there’s a CMS Wire paper that’s out there as well that has sort of the different options. Great question and good, the answer is you don’t have to use what we, if we did create something, you don’t have to use what we created. We will do some, after we’re done with the project, we can do some customization, we’re all about that so if you want to make some changes to the way that SharePoint works, we can do, I know some good people who can do that for you.
	Great question Scott thanks for asking that and I’ll also follow up with you on an e-mail with that. Another question from Tom, “What are the biggest user issues from moving from Jive to SharePoint, for example, training, management, use.”
Kirk:	Well people are used to using Jive in a certain way when they’re using Jive, and then SharePoint you don’t use things the same way. It’s just a different look, and so yeah there’s definitely some user training aspect to this where you want users to understand how to use SharePoint, what their stuff is going to look like once it’s in SharePoint, I would think that’s a big deal. From an IT perspective, totally different way of managing the product too. SharePoint’s got a lot more to think about.
Chris:	I mean it’s also an opportunity to unite with your users and get in front of them and say, “Okay we’re switching to something, we’re moving your, but we’re switching into something that’s really powerful that’s going to give you a lot of capability.” Most users find SharePoint pretty easy to pick up and use, you don’t have an issue with that. But it gives you an opportunity to actually schedule some time with your users and get in front of them and say, “This is where the stuff is going to, this is how you actually take advantage of this now.” There may be things you couldn’t even do before but you can do now.
Danny:	And this may go along well with communication, which is as your rolling this out, for years we’ve written about SharePoint best practices, sort of how do you do this the right way and what we see in different organizations. And it really is a competency thing, which is, you want to grow the competency of the organization as far as how it manages the information inside the organization. And if you’re using SharePoint as a platform to do that, there is, there’re training aspects of it. There’s just, what ends up happening in a lot of these larger communities is you have power users that end up showing up, you have different people who are really take initiative in building out their own solutions on SharePoint and you just have to nurture and cultivate those people and really grow it into something that everybody is using.
	And so we have probably 10’s of blog posts that are out there as far as training types of things that you can do for building applications, and Microsoft has lots of materials on that as well, but you’re moving somebody to a new platform which is a very powerful platform, but with that it requires training and building up an internal competency around it.
	I appreciate, looks like that’s the last question, I appreciate everybody taking the time to do this. I will, I’ve been recording this, I’ll send out the recording of this to everyone so that you have it. And it’ll be up on our website as well so that you can share with others who might not have been able to attend this. Chris, Kirk, you guys, phenomenal job, well done. I look forward to doing more of these with you guys. I think it’s giving people a choice, they don’t have to feel like they’re locked in and that they have a choice that if they want to keep what is important corporate IP, that knowledge that we have within our organization, that they can take it with them. That’s a really empowering type of thing, so I appreciate what you guys are doing.
Chris:	Thanks.
Kirk:	Thanks.
Danny:	Thank you everybody for listening, feel free, you can always reach out to me if you go to the contact us page on our website. That comes to me and I’ll get back to you really soon and if there are any other questions or anything else, feel free to reach out to me. And I appreciate you taking the time to do this and have a wonderful day, thank you so much, bye bye.