jive-to-microsoft-migration-costs.jpg

Guidelines for Jive to Microsoft Migration Costs

We’ve been doing a lot of ROM Estimates for Jive to Microsoft costs for clients for budgeting purposes.  Since we’ve been getting this question a lot (budgeting for Jive Migrations in 2018), I worked with Bruce Harple and Kirk Liemohn (our Migrations Practice Lead) to come up with some rules of thumb for creating ROM budgets for migrations (see below).

Typical Costs for a Jive Migration

  • Small – 9.5K workshop plus 30 to 50K implementation
  • Medium – 9.5K workshop plus 50 to 150K implementation
  • Large – 9.5K workshop plus 150K to 500K implementation
  • XL – 9.5K workshop plus 500K+ implementation

Typical Characteristics of a Jive Migration

  • Small – Fewer than 500 places (spaces, groups, and blogs), no new content types and no new destination types for content
  • Medium – 500 – 5000 places, no new content types and no new destination types for content
  • Large – 1000 to 15,000 places, target 1-5 additional content types/destination types
  • XL – 2,000 to 30,000+ places, target 5-10 additional content types/destination types

Please note –

Let me know what questions you have in the comments below.

A full eBook on Jive to Microsoft Migrations will be released later this year – let us know you’d like to be notified when it’s released by joining this list.

read more
Danny RyanGuidelines for Jive to Microsoft Migration Costs
questions-to-ask.jpg

Jive to Microsoft Migration eBook Excerpt – Questions to Ask Your Service Provider

Here’s a list of questions (with answers for ThreeWill) that we suggest that you ask when talking to service providers about migrating from Jive to Microsoft.

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 SP/O365?  Do you transform links to people and places as well?

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.

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?

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 to also 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.

How do you migrate comments associated with all of the different content types in Jive?  How are these comments stored in SP/O365?

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 in 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.

How do you migrate all of the different types of video content in Jive – attached, embedded, etc?

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.

How do you migrate all image content to SP/O365 and how do you maintain the linkage/references to these images once they are stored in SP/O365?

All images and referenced binary content (attachments, binary file content (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. that have been stored in this dedicated SharePoint document library.

Do you maintain the author/editor of the content when it is migrated to SP/O365?

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.

Do you maintain the created/modified timestamps of the content when it is migrated to SP/O365?

Yes.  When organizations do 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.

How do you handle changes that occur in Jive during the migration?  Do you have a delta/incremental migration?

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.

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?

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 as 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 accurately reference content as it lives in SharePoint.

Additional Questions

Here are some more questions to ask – we’d love to discuss these (and more) when you’re talking to us about the migration.

  1. How do you determine what specific places are part of a Jive environment?   Basically, how do you capture your inventory?
  2. How do you determine what places should and should not be migrated?
  3. Are you able to forecast how long a migration will take?
  4. If I want to customize or re-organize my content during the migration planning, what options do I have?
  5. Are you able to coordinate and collaborate with 3rd party vendors during migration planning and delivery?
  6. Can you provide multiple customer references for companies that you have successfully migrated from Jive to Microsoft?

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

read more
Bruce HarpleJive to Microsoft Migration eBook Excerpt – Questions to Ask Your Service Provider
winter-is-coming.jpg

Jive to Microsoft Migration eBook Excerpt – Preparing for the Migration

Jive to Microsoft Migration Step 3 of 9 – Preparing for the Migration

With Over 6 Months to Jive Cut-Off Date

If you have over 6 months of time before you Jive Cut-Off, that is good… you can breathe, but be aware that the time will fade away quickly!

Here are some things to work on to be best prepared for a smooth migration.

  • Work with ThreeWill to run a detailed or “deep” inventory of Jive. (Inventory is described in more detail under Step 5 – Understand the Process)
  • Determine what the target/destination platform will be for the content to migrated.
    • Is the destination SharePoint Online (Office 365)?
    • Is the destination on-premises SharePoint?
    • Is the destination something different… maybe even a hybrid of SharePoint with another platform
  • Are you planning to use Yammer? If so, will this be for all users or a sub-set of users?
  • Work with ThreeWill to set up the process to regularly refresh the inventory to account for additions, updates, and deletes for people, places, and content.

Capturing the Jive inventory also involves the creation of a master inventory spreadsheet.  This spreadsheet is used for additional analysis and planning.  It is important to make it available for all parties involved as an authoritative source of information.  It should not be passed around in email as the information can quickly become stale and/or misrepresented.

  • Review the inventory spreadsheet and analyze the list of Jive places to determine what is and is not to be migrated.

The additional analysis typically consists of identifying fields, such as place/content last modified date, content count, etc. to help determine if a Jive place should be migrated OR simply archived.

  • Determine the specific customizations that need to be done on the destination platform.
    • What are the must-have customizations vs. the nice-to-have or optional customizations?
    • Is a third-party involved? If so, they will need to understand how to work with the Jive inventory.  It is important to pull in the third-party as soon as possible to begin planning as a group.
  • Work with ThreeWill and any third parties to perform one or more proof-of-concept (POC) migrations. Each POC represents the need to prove out one or more technical requirements.  The audience is typically limited to the primary groups involved in the migration.
  • Work with ThreeWill and any third parties to perform one or more Pilot migrations. This is where representation from “the business” is pulled into help review the output from a small-scale migration.

The Pilot audience helps by reviewing the migrated output and providing feedback.  This feedback is used to help refine and correct issues, set expectations, and really help to scale up the production migration.

With Under 6 Months to Jive Cut-Off Date

If you have less than 6 months until the Jive cut-off date, it is important to set realistic expectations for the projected outcome of the migration.

ThreeWill recommends to not take on a complete overhaul of the destination platform.  It is best to keep the migration separate and simple in the scope of overall vision for company collaboration.

Here are some things to work on to keep things as simple as possible and prepare for migration.

  • Work with ThreeWill to run a detailed or “deep” inventory of Jive. (Inventory is described in more detail under Step 5 – Understand the Process)
  • Determine what the target/destination platform will be for the content to migrated
    • Is the destination SharePoint Online (Office 365)?
    • Is the destination on-premises SharePoint?
    • Is the destination something different… maybe even a hybrid of SharePoint with another platform.

Since the time for migration is limited, we recommend that the platform be kept simple; no customizations or perhaps limited customizations.  If you are planning to migrate to SharePoint Online (Office 365), it important to obtain licensing for all users and ensure the user base has been configured; all users should have a consistent Office 365 account.

  • Are you planning to use Yammer? If so, will this be for all users or a sub-set of users?
  • Work with ThreeWill to perform one or more proof-of-concept (POC) migrations. Each POC represents the need to prove out one or more technical requirements.  The audience is typically limited to the primary groups involved with the migration.
  • Work with ThreeWill to perform at least one Pilot migration. This is where representation from “the business” is pulled into help review the output from a small-scale migration.

The Pilot audience helps by reviewing the migrated output and providing feedback.  This feedback is used to help refine and correct issues, set expectations, and really help to scale up the production migration.

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

read more
Chris EdwardsJive to Microsoft Migration eBook Excerpt – Preparing for the Migration
SharePoint-Intranet-in-a-Box.png

The SharePoint Intranet-in-a-Box Market – Interview with Sam Marshall

Danny Ryan

Co-Host – Danny Ryan

Bio – LinkedIn – Twitter

Sam Marshall

Guest – Sam Marshall

Bio – LinkedIn – Twitter

Tommy Ryan

Co-Host – Tommy Ryan

Bio – LinkedIn – Twitter

Danny:Hello. This is Danny Ryan and welcome to the Two Bald Brothers and a Microphone Podcast. I’m here with Tommy Ryan. How are you doing Tommy?

 

Tommy:I’m doing great Danny. Looking forward to today. Talking about SharePoint intranet-in-a-box.

 

Danny:Awesome. Yes, yes and interview number two. Today we have Sam Marshall from ClearBox from over in the UK. How are you doing Sam?

 

Sam:Hi there. I’m very well thank you. I’m looking forward to it, too.

 

Danny:Awesome, awesome. Today we’ve got a great conversation that a lot of people are talking about. I know it’s come up for us quite a bit. I wanted to talk about … with Sam, he’s got a company that really focuses in on the decision process around what you should be using for your digital workplace. Sam, you’re gonna correct me if I say anything wrong here, right?

 

Sam:Oh for sure. Yeah.

 

Danny:Good. So Sam has a lot of options as far as workshops that he runs. Also, at the end of the podcast, we’ll go through a report that he has available for people who are interested in the products that are out there. I’ve given sort of a high level for you there Sam, but just tell me a little bit more about what your company does.

 

Sam:Yeah, thank you Danny. We’re based in the UK. This year’s our 10 year anniversary. We focus on digital workplace, strategy, things like intranet adoption, intranet governance, getting the right team in place. Basically, we do everything about intranet apart from the actual technology. So, we don’t sell any products, we don’t build things on top of share points, we’re really focused on the needs of the business user and the analogy I make is … it’s a bit like once a company’s installed a load of gym equipment, you then need to say, “Well okay, what’s the training program for our team? What is it we’re going to do with this equipment to achieve our goals?” and that’s quite a nuanced thing to help people think through because you carry on with the analogy, if you’ve got a bunch of marathon runners, they’re going to use the gym equipment in a certain way and do certain routines, but if you got a bunch of Olympic power lifters, then they’re probably completely different equipment and follow an entire different program.

 

We come across this a lot with Office 365, but you get so much stuff just with that license. The trick that we try and help companies think through is, what do we need out of this goodie bag that would work for us and what can we safely ignore?

 

Myself, I-

 

Danny:What’s your-

 

Sam:Yeah, go on.

 

Danny:Yeah. What’s your background … I was just inter … just going to ask you probably what you were just going to say, but tell me more about your background?

 

Sam:You’re going to cue me up perfectly, and I interrupted you by segueing in to it myself.

 

I’ll give you the funny answer. I studied baboon behavior as a psychology graduate, and then I specialized in Artificial Intelligence, building like a robot. If that isn’t the perfect background for intranet, I don’t know what is.

 

It turns out that the baboons are like robot’s pays as well, as getting involved in things like SharePoints. A man’s got to eat, you know.

 

In between that, the serious answer is I did a lot around knowledge management and working with internal communicators. That’s what got me into intranet and things like SharePoint cause I think the technology to me isn’t that interesting, but the things that people do with it and how it affects the digital workplace, that’s fascinating.

 

Tommy:In saying that, if you honed in on SharePoint and Office 365 as that platform, or are there other platforms outside of that? I know you advise people on Intranets and the box that interacts with SharePoint, but are there other platforms that you get involved with?

 

Sam:Yes. We’ve always made a point of saying “We are technology neutral,” because we don’t see that as the biggest challenge. We have worked with clients who are using open source systems like, Drupal, and also some of the ready-made non-SharePoint platforms like, Interact, which is a big player in the UK and I think also getting more visibility in the US. But, in fact it’s probably 80% of our clients have already made the decision that the answer is Office 365 and they come to us saying, “Now Sam, can you tell us what the question should have been so that we can justify the answer, Office 365.” We run with that. We have no problem with the technology choices that we make.

 

Tommy:Okay.

 

Danny:Awesome. What … just sort of getting into our conversation here, which is … and it has to do with really the build versus buy decision, what’s been happening over the last couple of years with regards to, in particular with SharePoint online, but also some of the other products that have been coming around. What and … How did you get into this whole idea of doing this, the SharePoint in a box report? Give me a little bit more background, was it just a lot of people were asking you for what the options were out there? Tell me a little bit more about that.

 

Sam:Yeah, yeah, in part. So maybe we should explain a little bit what this intranet in a box is and what report is that we’ve done. So intranet in a box products are things that you install on top of SharePoint, or alongside SharePoint, or within your Office 365 environment, and they kind of take the bare bones of SharePoint and give you a lot more of what you would normally expect to see in an Intranet. So, for example, that hero image, the news publishing, maybe a much nicer looking feel. So recently, something that worked well on mobile, that wasn’t available from SharePoint 2013. We saw a big growth in companies who have maybe been doing this for years as an agency, taking a whole bunch of requirements, and responding to an RFQ, and then building it again and again for different clients.

 

And I suppose each one of these companies said, “Do you know what? Why are we building yet another Carousel web-part from scratch when 90% of the requests ask for the same thing. Why don’t we turn that into some kind of product so people can buy it and take an accelerated approach to getting the intranet that they want. And as ClearBox, we noticed this was happening, and thought well, we’re in a pretty good position to be the neutral guide for people on this because we’re never gonna sell any of these products, but we do have a really good understanding of what it is that companies are looking for. We’ve worked with everything from small charities of a couple hundred employees, all the way up to the Unilevers of this world that have 50 or even 100,000 employees, so we see the range of requirements.

 

A couple of years ago, we’re talking end of 2015, we took a look at the market and said “Let’s do a free download where we look at six of these products, and we’ll do like a buyers guide. We’ll do a star rating of the strengths and weaknesses and have a look, at least let people who are interested in sourcing one of these understand what’s available.” So we did that, and we got a really good response, and we got lots of indignant vendors knocking at our door saying “How come you picked them, and you didn’t pick us. We’re really great as well. When’s the next faction of the report going out?” So we thought, yeah okay, that’s a fair question, let’s do this again. So we put out an appeal for participation, and we had 26 vendors respond. And I’m starting to think “Okay, so this is something we should really take seriously.”

 

So we produced a paid-for research report, it’s like 250 pages. Every product, we put them through like eight different common scenarios, so things like publishing news, supporting communities, two-way conversations, analytics, and we evaluated them consistently across each one of these and said to the vendors, “Show us how your product would fulfill this scenario.” So it was a little bit like a mock RFP, where you might come up with some use cases and ask for a demo of those use cases.

 

Since we did that, we find yet more indignant vendors knocking on the door, who yet again felt excluded by this, but also some really good feedback from the vendors who had taken part, saying “Yeah, we’ve got lots of new things to show, we’d like you to do an update of the report.” So we’re just oiling the wheels to start again for this year and, so far, we’ve had, I think, 48 companies that want to be listed.

 

Danny:My goodness.

 

Sam:So this is a very, very active market area. And I think really interesting because what’s driving it from a company point of view, a lot of our clients say we’ve got this steer from CIO, we want to buy, not build everything in IT. Wherever we can, we want software as a service, or we want it to be cloud based, because we’ve been so often in the past with SharePoint, where we invested hundreds, if not millions of dollars in this custom solution. Microsoft broke it all and it cost us hundreds, if not millions, of dollars more to fix it. Can we push that headache onto an external company who will not just keep in-step with Microsoft plans for us, but in-step with maybe a whole cohort of customers, and therefore spread the cost.

 

I think not only is there a boom from the supply side, but there’s also a real boom from the customer interest happening as well.

 

Danny:Looking at that report Sam, it’s incredible. So detailed and it’s something that I think a lot of people like to see and kind of compare it as rating it as a Consumer Reports-type of view, where you’re comparing some of the same parameters.

 

Sam:Thank you, a lot of ibuprofen went into that report, I can tell you.

 

Danny:Yeah. You can tell there’s someone that has attention to detail or obsessive-compulsive maybe behavior there.

 

Sam:It wasn’t just me, I had a team of eight obsessive-compulsive working for me as well.

 

Danny:Okay, nice. Yeah. And I can see … it’s interesting to see the amount of folks that are in this space. You probably don’t know this, but you wonder what’s the market opportunity, you know, what does the space look like, and all these companies that are going into creating an intranet in a box, how are they rationalizing that. Are they product companies that go into it saying “We see this space, it’s got a market potential of this, and we’re going to go after that market and go after this niche in that market,” or is it consulting companies that built the same customizations over and over again and that productize that and try to spin off a product side. I assume you see a mix of those and do you have any comments on what makes a good intranet in a box company that can be successful endeavoring in this space?

 

Sam:It’s a really good question because it has a lot of signs of an immature market, and what I mean by that, is last year on the whole, pretty much everyone doing this is coming at it from the consulting side and moving into being a product company.

 

Danny:Interesting.

 

Sam:I don’t see many product companies who are saying “We want our product in this space, alongside all the other products that we’ve got.” And what that means is that there’s a really challenge for a consulting mindset company to change the way they work to support a product that might mean multiple releases and help desks and all the other things that you would expect when you buy a license that don’t fit that project mindset of doing consulting where there’s a clear endpoint, and anything you want after that is another contract or a kind of bespoke support engagement.

 

Danny:Right.

 

Sam:So to answer your question about what makes it good, in a box vendor, it’s the ones who’ve really, I think, segregated their business so they have a team that’s dedicated to look after the product and just thinking about the product roadmap, irrespective of there necessarily being a sale behind every feature that they add. So it’s not like they’re saying “Oh we’re going to do this because a big client has asked for it,” they’re doing it cause it’s the right thing to do and they’ve got that vision of where they want to set the product, as a way to generate the sales.

 

Tommy:What you see is a sampling of companies that haven’t made that segregation, is that maybe the guy that developed a feature that you’ve raised a ticket on cause it’s not working right, is pulled off from a client project for the next three months, and that poor guy’s going to have a real tension in terms of how does he allocate his time to looking after the conflicting needs.

 

Danny:Interesting.

 

Sam:If I can share a little secret on the podcast, and everybody listening has got to promise not to repeat it. I’m joking. There are a few companies that got in touch saying “Please can we be in your report,” and they couldn’t even provide a website link cause they hadn’t got the website live, you know, the product was that fresh. We’ve had a little chat with them, said “Come back next year when there’s more to show,” because I think part of what people investigating this area need to be aware of, is some of these products, I don’t think, will last, and that’s part of what we’re trying to help do, is understand how robust is this offering. Cause if you back a product where the vendor walks away from the market in 18 months, then you’re no better off than if you built it in house, you got that same headache, in terms of upgrade groups.

 

Danny:Yeah, that’s an interesting thing, and as I was looking through the report, I see when the company was founded, it’s so and so IT consultancy. Is there any measures around, say, maturity and, let’s say, process product capabilities that can give a client a certain sense of assurance that they’re going to be around two years from now versus they’re just kind of dipping their toe in the water. How do companies sort that out and do you help them with that?

 

Sam:We do and there’s a couple of checkpoints within that. So one is how committed is this company to the product roots, and the other one is how stable is the company itself. So, you know, the company might live on, but they might say “Yeah, we’re walking away from looking at this product anymore,” and you’re still high and dry.

 

Danny:Right.

 

Sam:In terms of the company stability, I always say to clients, just make sure your procurement is doing it’s due diligence in terms of looking at the vendor financials, the Number of employees they’ve got, and the track record of companies of a similar scale to yourself. The usual revenue credit check-type stuff you do.

 

Danny:Right, right.

 

Sam:In terms of the product maturity, in the report we list when the first release of the product was, we list how often they release it. In the new version, we’ve asked what’s the typical customer size, and also what’s your largest customer size, and most of them have also given us the names of reference companies. And all of those are good reflections of a healthy product, I think.

 

Danny:Mm-hmm (affirmative), mm-hmm (affirmative). That’s good. It’s interesting your answer to the profile of a company that it’s, you know, primarily consultancies, you wonder is there the market there for it where product companies maybe do a market-level research versus saying “Oh we’ve got code for this,” it’s more of is there a market established that we know we can invest so many dollars in product to convert so much business. Do you think … do you have a sense of why traditional product companies are not entering this market?

 

Sam:Well, it’s a busy market, isn’t it.

 

Danny:Yeah, yeah, maybe they see it’s too packed.

 

Sam:Not necessarily, the SharePoint space has traditionally been dominated by the partner model, and there aren’t so many companies that have got established SharePoint products who, perhaps, understand the intranet world, you know, that whole publishing model. They’re much more on things like the transactional BI or the back [inaudible 00:17:31] tools.

 

Danny:Right.

 

Sam:You know, you think about metalogix or K2 on Intact, I don’t think any of those have anything else that’s similar to what an intranet would do. I mean what are your guys’ thoughts on this cause you’ve, I know, have been exploring this space as well.

 

Danny:I can maybe say a little bit about that Tommy and I are very interested to learn sort of about … and this is probably because we’ve been in business for quite a while and have tried launching a couple products of our own, we’re not planning on launching nay intranets in a box or anything along that/ those lines. I think one of the things that Tommy and I have recognized that it is truly a different type of business, and in order to be successful, we’re at the point where we say it’s got to be a separate company doing a product, it can’t be us. So we’ve recognized that and so we’ve been very cautious about entering into any sort of product type of business. In fact, I’ve got up on our website, we’ve recently … we did some integration products with Salesforce, and we’ve recently retired those because it’s just … we just don’t … we can’t … it’s not the right business for us.

 

What I’m interested … if I can … I’m interested right now because of traditionally the … number one the SIs, how would they handle … cause typically with these different intranet and box products, they’re selling both the product and the services along with it, what are … cause we’re an SI that doesn’t have this, are they typically just building? Are you seeing them build on top of SharePoint or are they … and we’ve partnered with … there’s been some companies that we’ve worked with that, in particular, where they’re moving from Jive, which is a social platform, to Office 365, we have some expertise where we’ve been pulled in to do the migration where we’ve got some expertise in several of these products.

 

But how are SIs … what are they … are they deciding I’m just gonna build on or how are they handling this whole situation?

 

Sam:I see a big growth in the more established in a box products, setting up partner and resell and networks. So I’m guessing these guys are aligning themselves to specialize in one or two in a box products and saying “Yeah, we can meet 80% of a client’s requirements by adopting this product,” and then we’ll fulfill the other 20% as bespoke. But it allows them to deliver a solution way quicker than they could have done before. So some of the in a box vendors, in particular Powell 365 and Kamina, are really geared up to deliver through SIs, rather than you would go directly to them for the solution.

 

Danny:Gotcha, gotcha.

 

Sam:And again, I see that as an encouraging sign of maturity, that the product is something they can build out a partner network through. The less mature ones, you could argue it’s not really a product because it’s actually a set of code libraries and you always need the in-house consults and the expertise to turn it into a delivered intranet solution.

 

Danny:Yup. Tommy, were you gonna say something? I think I cut you off a little earlier, I’m sorry.

 

Tommy:I want to say Sam was asking what do we see as that marketplace and why are there intranet in the box solutions out there. We started in the SharePoint space back in 2006/2007, and it’s when Microsoft really touted SharePoint as a platform, a customizable platform, and gave a lot of knobs to turn as developers, and as SharePoint is maturing, and as Microsoft is going to the cloud, you can see SharePoint becoming more commoditized and going into the cloud, being in a multi-tenant environment, it’s really not suited well for some of the customizations you would do in the past. So you have organizations that want those better look than feels and they can’t work within the constraints of what Office 365 puts in place, so they want to extend that capability and have more control, and that’s working with these companies that are providing more the functionality that might not ever get there in Office 365 or maybe doesn’t get there soon enough, where they’d rather get there sooner by buying it than building it, knowing that things might change underneath them with Office 365.

 

And I think also, it’s been the space around Microsoft where Microsoft kinda put out share point and said “It’s here, it’s got some core capabilities, do with it what you want and think about the possibilities of what you can do with the intranet.” That can be paralyzing to a lot of organizations, and buying something out of the box, like what we experienced with people buying Jive, is it’s a polished product versus a platform play, and a lot of organizations kind of like that and went in that direction. I think these intranet in a box companies are seeing that people want the reliability of having SharePoint storing the data, being that backend, and then have the nice shiny upfront with something that Microsoft is not necessarily known for, but getting better at. You’re seeing things that are coming out that make you about Microsoft. It’s becoming “more modern” in their UIs, but with a company that size, they’re always going to be probably a step or step and a half behind what these smaller companies are able to do with web technologies.

 

Danny:Yeah.

 

Tommy:And that’s just my kind of high-level view of, you know, why is this space being created, and it’s not totally surprising that it’s coming primarily from SIs doing this. But it is, I think, a sign of, like you said Sam, maturity, the market, where it is coming from, shared code libraries, that are coming from projects, from SIs versus you have a product company saying “There’s an addressable market, there’s a gap here, we want to address it and we feel confident that people are going to spend the money here.” We’re surprised … it might because we’re doing a lot of Jive to Sharepoint point migrations, but we’re surprised in the number of companies that are choosing the intranet in a box option, because it will put your data inside other CMS systems. We’ve seen with some of these systems, they’re not just storing everything in SharePoint, they have to have their own CMS to give the kind of capabilities that they add on top of SharePoint, then maybe they just store the file in SharePoint but the blogs are sitting in their own CMS system inside of SharePoint.

 

Sam:I mean I absolutely agree with your analysis, Tommy, but that point about where your data sits … there’s only three or four where it resides in a separate CMS. So we’re working with a client at the moment where it’s an absolute prerequisite that the data stays entirely within the Office 365 tenant.

 

Tommy:Right.

 

Sam:There’s about 20 options where that’s definitely the case, they … some of them it’s really just web parts and styling that they’re adding, they’re not taking the data outside of your own client at all.

 

Tommy:Yeah. That’s what I would want as a customer, but also some of the sexier ones are not necessarily using SharePoint as a store cause it complicates things. A blog in SharePoint, that data structure’s totally different than what you would want to do from scratch to create a blog interface.

 

Sam:Yeah. It’s understandable cause often the brief from the client is can you make SharePoint look not like SharePoint?

 

Tommy:Right.

 

Sam:So what you’ve do is get another CMS and patch it in the [inaudible 00:26:20]. When you do that-

 

Danny:Sometimes-

 

Sam:The big trade off is that it becomes an uncomfortable hop back into anything Office 365. So if you look at something like flow and say “Ah it’s great, can’t we use flow as part of what we’re doing with this separate CMS?” The answer’s always gonna be no because the CMS won’t have that level of integration.

 

Tommy:Mm-hmm (affirmative). Mm-hmm (affirmative).

 

Danny:So I would be remiss if we didn’t talk about … sort of the hot topic and the elephant in the room, which is communication sites. Sam, I was fortunate enough to listen in on a webinar, and I think this is an interesting thing cause as a feature … sort of as maybe a feature set, this is one of the things that SharePoint and box companies were addressing, which was the modern experience working well on mobile devices, and we’ve seen this year, Microsoft release this. What … give me … what does that mean to folks, how does that … what’s your general take on what’s happening right now, in particular with communication sites?

 

Sam:Yeah, so communication site’s really interesting, really good to see because, I think, it reflects that Microsoft is definitely getting the UX message that it’s so important, and they frankly just haven’t got it right for many years. Communication sites are fantastic when you need to create something that’s attractive, around a single topic. But it is still a micro-site, in effect. So, right now, we shouldn’t pre-judge cause we know this is just like the first release, and there’s probably lot more to come from Microsoft.

 

Right now, it looks like an intranet homepage, but it really isn’t. And what I mean by that is that it has the hero images, but they’re just images with links behind them, it’s not actually you click on it and you’re taken into a news article unless you manually tie that hero image into a news article. There’s no cross-site publishing, so we find once you get up to 500 employees, or two or three countries, or two or three business sectors that your company operates in, it’s not enough to have separate sites for everything. You want to be able to create a news story and say “Here’s a news story, now zing it out so we can target it to everybody in Canada, but not in the U.S., or everybody who worked in sales, but not in marketing.” And for that, you still need the idea of a news center, a repository of news, and some kind of metadata and personalization, which then does a search, call and pulls them back to show people.

 

That’s not something that I can see coming in comp sites anytime soon. In terms of the in a box marketplace though, Microsoft is definitely gonna make the sales guys work harder cause comp sites look great. Getting from ResX saying “We really need an intranet in a box,” when they can see a comp site becomes harder, it probably means that some of the in a box vendors who were targeting companies of 50 to 200 employees, somewhere like the small to medium enterprise business, they might pull out of this market in time, unless they are really focusing on doing non-communication stuff like transactions, which some of them do very well, indeed.

 

Danny:Interesting.

 

Sam:Yeah. I mean what your take? Do you see your clients excited by communication sites?

 

Danny:From my experience, Sam, I think it’s early on and they’re so buried in everything else that they haven’t fully explored that at this point.

 

Sam:So now it’s class, we’ve got actual lives and actual businesses rather-

 

Danny:Yeah. Definitely. It’s something that makes you pause to say “Okay how does that play into the equation?” The thing that I think Microsoft’s doing well with, but developers in the Microsoft ecosystem might get frustrated, is they’re trying to narrow down the lane a bit, and get more focused around areas in SharePoint to be very good at. I like the concept of segregating into teams and communication sites, and that I think is the 80/20 versus the traditional Microsoft is we’ll try to cover 100% of the space versus honing in and doing very well on the majority. They can go across platforms and devices to expose that in a polished way. I just love seeing teams and that visual overlay on top of a SharePoint team site or Office 365 group.

 

That’s exciting for us to really have a customer go a long way because they’ve gone deep on that topic of a team site versus before, in 2007 and 13, you had 20/ 30 different things to choose from as a starting template. I think that’s different for Microsoft, I think it is speaking to we’re all busy people and we need less choices. It’s interesting that you say there’s 50 intranet in a box selections. I think that’s good news for your company because that just makes that equation even more complicated of okay, am I picking the right one? I don’t have time to evaluate 50 different options. Then you feel at the mercy of which one has the best marketing program to touch me, is the one I’m gonna choose, and maybe that’s not the right selection criteria. I need to make sure I’m thorough and picking the company that best aligns with our needs and our direction.

 

Sam:Yeah. That is so important because once you’ve made that choice, once you’ve committed to it, you really have narrowed down the scope of what you can do. So these in a box products, they make things easier to use by, in effect, reducing some of the choices that you would have if you were On a bare bones SharePoint and could develop anything. I always say to people, “Don’t pick a product and think that you can just tweak this and tweak that,” because you won’t be able to if you want to stay faithful to the vendor’s own roadmap.

 

Danny:Yeah, definitely.

 

Sam:If they become tomorrow a formal requirements gathering exercise, and we’re helping quite a few clients through this at the moment, just to go through an RSP that gets you in the right place to come up with a short list and then choose between them.

 

Danny:Very good.

 

Tommy:Sam, I think we could talk to you for hours here, so I know you’ve got a hard stop. So before we wrap-up, if you don’t mind, I know you mentioned that you might have a discount code for listeners, can you give us a little bit more … some more details on that?

 

Sam:Yeah, sure. So if you head over to our website, which is clearbox.co.uk, I know I’ve got a funny accent, so let me spell that out, that’s c-l-e-a-r-b-o-x, opposite of black box, .co.uk. You will see, right there on our own hero image, a link to the SharePoint intranet in a box reports, and when you go to check out, use the code t-w-o-b-b 20, so that’s t-w-o-b-b, for bald brothers, and 20, cause. T-w-o-b-b 20, and you get 20% off, so the full price is $495 dollars, you’ll get $99 off, making it $398.

 

Danny:That’s awesome.

 

Tommy:Super.

 

Danny:That’s awesome.

 

Tommy:That’s great.

 

Sam:[crosstalk] Right until the end of August so if you’d like, on your summer holiday reading by the pool, the report will certainly help with your siestas. I mean it will certainly give you plenty to read.

 

Danny:That’s wonderful. And maybe, Sam, we can have you back after the next version is out. Tommy and I’d be interested to hear some of the details on that, so that’d be wonderful to have you back.

 

Sam:I’d love to. Once I’ve had a big lie down, I’d love to come back and talk to you more about this topic since you’re really into it.

 

Danny:Super. Well thank you, Sam, thank you Tommy, and thank you, everybody, for listening. Yeah, thanks so much.

 

Sam:Pleasure, thanks very much, guys, for inviting me on. It’s been great.

 

Danny:Alright, cheers.

 

Tommy:Absolutely, take care now.

 

Sam:Bye.

 

Tommy:Thank you, buh-bye.

 

Additional Credits

Podcast Producer – Oliver Penegar
Intro/Outro Music – Daniel Bassett

Remember to use discount code “twobb20” for 20% off!

read more
empty.authorThe SharePoint Intranet-in-a-Box Market – Interview with Sam Marshall
action-plan-1.jpg

Typical Action Plan for Jive to Microsoft Migrations

We’ve been doing Jive to Microsoft (including Office 365/SharePoint) migrations for the last 4-5 years and we’ve got a great process and tooling to help with these migrations.

One of the things I like to do early in the process is to put together an action plan (from Solution Selling).  It’s based on one of the seven habits, Begin with an End in Mind.

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

Now – Download and run Migrator Trial Version and get counts on People and Places and answer questions about migration in Pre-Migration questionnaire

+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 3 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 (I think the smallest was around 6 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.

Important factors to time are if the client is just migrating content types we’ve worked with on previous projects and the number of places that we are moving.

Read more Frequently Asked Questions (has details on things like the 2-day Migration Workshop and content types we can migrate).

read more
Danny RyanTypical Action Plan for Jive to Microsoft Migrations
why-1.jpg

Why Move the Content from Jive into Office 365?

I had this question come up in a recent email…the response went so long that I thought that I should share it in a blog post…

Here’s my .02 on making this decision:

I’ll make the assumption that you’ve decided to move to Office 365.

Why move the content from Jive into Office 365?

  1. The documents, discussions and other corporate IP within your Jive environment would be lost (think of the tens of thousands of hours that went into creating much of that content).
  2. This will impact the adoption of Office 365 because why would they recreate content in Office 365 if there is the risk of it going away again?  End users would probably return back to email as the primary way to collaborate.

Maybe the idea is to start with a clean slate in Office 365.  Actually, cleaning up content before or while we move it is done on every project that we do.  Our tool shows you details about the amount of content along with when it was last accessed so you can decide whether to move the content or not.  You do want to take this opportunity to clean things up – but starting your employees over with blank sites would be disheartening.

Let’s say you just tell people to move over content from Jive to Office 365 on their own.  This could be because it’s difficult to say who should pay for the content migration.  You probably know this, but getting content out of Jive and into Office 365 is not an easy task (especially for business oriented folks).

If the budget is the issue, we could give you a cost model for migrating different departments (say a certain cost for moving over Marketing – they could decide whether it’s worth the cost or not).

Another option is just to move over certain types of content.  For example, just move over binary files.  This would reduce the budget and yet still retain some of the corporate IP.  Our tool actually doesn’t migrate all content types – list is here – https://threewill.com/services/jive-to-sharepoint-migrations/#faq – so we actually have taken this approach with clients.

What’s your take on this?  Leave a comment below…

read more
Danny RyanWhy Move the Content from Jive into Office 365?
Jive-Migration-Process.png

Jive to Microsoft Migration eBook Excerpt

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

Equip

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

Inventory

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

Prepare

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

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

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

Batch

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

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

Migrate

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

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

Verify (and Remediate)

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

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

read more
Chris EdwardsJive to Microsoft Migration eBook Excerpt
complex-sharepoint-migrations.jpg

Is Your Organization Prepared to Do a Complex SharePoint Migration?

Is your organization prepared to do a large and complex migration?  There are a lot of considerations.  Here a few related to organizational preparedness:

  • Experience – Has your organization performed large-scale migrations with SharePoint or other platforms in the past?  If so, you have some valuable experiences to draw upon.  Even an Exchange migration, for example, shares some aspects with a SharePoint migration such as communication and support.  The most analogous experience may be comparing a SharePoint 2010 to SharePoint 2013 migration to a SharePoint 2013 to SharePoint 2016 migration.  Keep in mind that migrating to SharePoint Online has several important differences when compared to migrations involving on-prem SharePoint for the source and target, so be careful not to over-state your experience.
  • Skilled Resource Availability – Does your organization have the people required to handle a large and complex migration?  Skilled individuals are necessary from the core technical migration team through project management, helpdesk, and communications.  In addition, some migrations require doing a lot of work in a relatively short amount of time.  Having enough skilled resources during that time may be a challenge.
  • Helpdesk/Support Preparedness – Do you have a ticketing system that can be used for migration support?  Can the system handle the increased volume that may occur with a large-scale migration?  Do you have the individuals behind the system (Level 1, 2, and 3 support) that can handle the increased load?  Do they have SharePoint skills?
  • Communications – There are several questions to consider regarding communications within your organization.  How does your organization deal with mass communications?  Do you have a complicated or restrictive approval process?  Does your company culture foster the type of communication that will be necessary for site owners and users?  Do you have a good understanding of how to communicate with users and site owners?  Communications is arguably one of the most important aspects of a migration, so these questions should not be taken lightly.
  • Compute Resource Availability – With a large migration, it may require a lot of compute resources to physically move the bits from one environment to another.  This is highly dependent on the method of migration.  For example, using CSOM (Client-side Object Model) to copy content from SharePoint on-prem to SharePoint Online requires a lot more compute resources than the database attach approach that can be done when you are moving from one on-prem farm to another.  Local servers can be used regardless of the approach, but with moves to SharePoint Online, it may make more sense to use Azure virtual machines as it can be physically closer to the SharePoint Online datacenters.
  • Time – Is there a required timeline for completing the migration?  Is the timeline reasonable given all the steps that need to be performed during the migration?
  • Senior Executive Advocates – is the migration supported by senior executives within the company?  Are they aware of some of the tradeoffs that will need to occur as part of the migration?  Do they understand enough of the complexity to defend decisions made in the Policy Document?  Will they defend timeline and scope that are reasonable given the nature of the migration?  Without having support from C-level individuals, the migration may be at risk of being cancelled or put on hold.

If you’re looking at doing a Large and Complex SharePoint Migration, download our recent eBook on this subject.

read more
Kirk LiemohnIs Your Organization Prepared to Do a Complex SharePoint Migration?
webinar-yellow.jpg

Migrating from Jive to Office 365 Webinar

Danny:Welcome to this Jive to SharePoint/Office 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 Office 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 Office 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 Office 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 Office 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.

 

read more
Kirk LiemohnMigrating from Jive to Office 365 Webinar
part-3.jpg

How to Write Copy that Sells – Part 3 – Jive to SharePoint Migrations

Danny Ryan:Hello, and welcome to the Three Will podcast. This is your host, Danny Ryan, and I have Tommy Ryan here with me. How you doing, Tommy?

 

Tommy Ryan:I’m doing well. Good morning, Danny.

 

Danny Ryan:Good morning. It’s a Thursday. We’re getting out. We’re getting a little bit of consistency back in our Thursdays.

 

Tommy Ryan:That’s right.

 

Danny Ryan:All right. Great. Sock check. What you got on this morning? Let me see. That’s nice. You’ve got some stripes, a little variation. That’s good.

 

Tommy Ryan:It’s a grey day.

 

Danny Ryan:It’s a beautiful day outside.

 

Tommy Ryan:It actually is.

 

Danny Ryan:It’s really nice. I love this fall weather that’s coming on. Wanted to, in today’s conversation, just to pick back up. We’ve had a couple of blog posts on a book that I’m reading that’s called, “How to Write Copy that Sells.” It’s a book by Ray Edwards. We went through all of our service offerings and went through the first part of what he calls “The P.A.S.T.O.R. Copywriting Framework.”

 

The “P” in the P.A.S.T.O.R. is person, problem, pain. We took a broad brush at that and looked at all of our service offerings. What I’d like to do today is to hone in on one of them and maybe blow out the rest of the items and talk about how they would apply to our offering around Jive to SharePoint migrations.

 

I’ve taken a little bit of time and crafted out what I think is something that could be … He suggests creating like an initial draft of what that pitch looks like. I started with that. I’m sharing this with Tommy internally, so we, for the person, problem, pain for the Jive to SharePoint, I was focusing in on simplifying and saving money.

 

The question I have is, “Do you pay double for collaboration because you have both Jive and SharePoint?” I think we’ve talked about a couple of different pains. You think … Is that a track? Do you think that’s a good way to start off with the pain, Tom?

 

Tommy Ryan:Yeah, I think that is the pain that people are trying to address. It usually comes from acquisition, a merger, that it wasn’t an intent to have both. It just happens to be that way after a course of an event.

 

Danny Ryan:Mm-hmm. For a copywriter, he high suggests using bullets. After that, I’ve got a bulleted list of things that I think would characterize the pain. The first one being is you have to use a 10-step flow chart every time you want to start a conversation. There are too many options in Jive and SharePoint. That could be a pain that they have.

 

The second one being, if you’re frustrated with not having a fully integrated experience. That’s jumping back-and-forth between the two platforms. If you’re simply looking for an easy way to win the love of the CFO, this is, for a lot of folks, it’s this is what puts them over the top. Removing that reoccuring cost of Jive, you want to do this, but you don’t want to lose all the content that you currently have in Jive.

 

Tommy Ryan:Right. It’s funny, I look at some of these pains and we have other customers that we’re trying to address this in a different way, which is an integration and centralized search that searches across both SharePoint and Jive, ways to surface the Jive’s activity feed in a SharePoint web part. There’s not always one answer to the pain, but this is definitely a path that we see, that’s a common path to address it.

 

Danny Ryan:This is a message for them so we’re queuing in they’ve had one of those issues come up. Then, I’m saying, “This message is just for you. Here’s why. You can stop paying twice for collaboration. You don’t have to pay for both Jive and SharePoint anymore.” That’s what the statement that I’m making out of this is, is that you don’t have to pay twice. That’s framing up the pain and the problem and the person trying to address the person by things that they typically run into.

 

The next step of this is amplify, which is to stress the consequences of what will happen if the problem isn’t solved. I start this on off with, “If you ignore it, it gets worse.” Then, a little bit of a back story there. There was a time when Jive ran circles around SharePoint with its lengthy 3-year product cycles, but that’s not the case anymore. One could make the argument that Microsoft has innovated faster than Jive.

 

What most people do when facing the fact that Jive and SharePoint do so much in common, is try to integrate the two. Jive and SharePoint, either with a connector or manual corporate processes. Go on and say, “For most organizations, that doesn’t work.” Then, I go into, “Jive’s connector, it treats SharePoint more like a data source. The original connector still exists but we’re recommending the customers make a decision between Jive or SharePoint.” Some organizations try and create complicated manual processes that might work for a little while and with a big stick, but over time, people just fall into bad habits.

 

What happens if you do nothing? What happens if you keep doing what you’ve been doing? The Jive bill still show up. Your users will still be confused about where to store content. A search will continue to be a disaster. This is me amplifying things. It’s a little bit of marketing speak, but you know the purpose.

 

Tommy Ryan:I think some of it is not always the case, but it is a case if it’s not managed well. I think one of the statements, the overall tone, I think what you’re saying here, if it’s left to its own course, it can get to be a bigger-and-bigger problem. For most organizations, it’s not worth the management and all the effort to try to bring the two together.

 

There’s going to be cases where they do, where there’s a certain group that feels like it’s valuable to have Jive. Then, they have to address that through an integration pact. For most organizations, it’s hard enough to manage one collaboration platform, let alone two.

 

Danny Ryan:Awesome. That takes care of “Amplify”, which is the “A” in P.A.S.T.O.R. Next is the “S”, which is “Story and Solution”. Tell the story of someone who has solved that problem using your solution or even a solution like yours.

 

Here, I’ve got how we simplify. We’ve got an answer that works. Then, to start the whole thing off with the back story. Three Will was hired by Jive to create the connector, telling where did we fit into this whole picture? We wrote a white paper on making SharePoint social when we described combining SharePoint and Jive together as a first class experience. Then, describing what ended up happening with Jive wanting their own connector. We didn’t want to lose the years of important collaboration. IP that was stored in Jive, so we created a tool to migrate our content over. Then, we started getting contacted by companies that installed the connector to migrate them from Jive to SharePoint.

 

Microsoft acquired Yammer and more companies moved. Office 365 moved to a rapid development cycle and benefited from heavy investments and became one of Microsoft’s most important platforms. This year, we’re getting requests every week from customers to help them with the move. This is giving the story a little bit about how did we get to this place and the fact that we solved the problem ourselves and we’re solving it for other people.

 

Tommy Ryan:I think these things have their life cycle. There’s new technologies that come out there that push Microsoft to innovate and Jive’s definitely one of those that got the attention from a social aspect. I think the story’s not completed yet. There’s always that strain of organizations knowing how to do social write.

 

We tend to always go back to the email way of collaborating. We know it’s not the right way, but it’s the easy way, so it’s trying to strike that balance. If you can simplify your overall infrastructure as it relates to collaboration, that’s one step in that direction to make it easier.

 

Danny Ryan:The next part, the “T” in P.A.S.T.O.R. is for “transformation and testimony”. That is articulate the results that your product or service will bring providing real life testimonials to strengthen your case. The next part I have is, the headline is, “It worked for these people and it will work for you.”

 

One of our first customers was Poolcorp. They’re drive-based internet although highly leveraged within the enterprise was too costly to justify the recurring annual license fees. This decision to unplug and replace was delayed 8 weeks before their annual renew date so meeting the project deadline was a critical success factor. We replaced Jive with SharePoint within that 8 week deadline. We implemented yada, yada, yada, what we did, what they got out of it.

 

Then, the testimony part of it. “Here’s what our business sponsor had to say about the project.” Then, he talks about our initiative to move from Jive to SharePoint, how our strong business case, but was complicated due to the short window for migration completion. We needed a technology partner and could get the job done predictably in that short 6-week period. Additionally, required the new SharePoint internet to look like and navigate like the Jive site in order not to disrupt the field and service teams. Yada, yada, yada.

 

Basically, we did this. He wraps it up. The coup de grace, which was, “We did it on time and under budget.” Then, the last part of this is, I say, “This was one of our smaller migrations. We’ve migrated customers with 10,000 places and terabytes of content.”

 

Tommy Ryan:Yeah. I think one thing … I don’t know how much it needs to be amplified, but something to keep in mind is, when we’re going through this process of migration, there’s value in not just migrating it, but looking at what is your strategy for where content exists in your organization. What is content that’s no longer valuable and cluttering the existing content that is valuable. Getting in the way when you’re trying to find things through search results or navigating through structures. It gives our clients an opportunity to simplify and clean up as they’re moving.

 

Just like when you go move to a new house. Ideally, you spend several months looking through what you have and deciding what you can get rid of. That way, when you go to that move, it’s an easier move. You feel better about not spending so much time on things that are not valuable, that you’re not going to use in your new house. I think that’s something that people don’t spend probably as much time as they should. We continue to encourage our customers to take advantage of that opportunity.

 

Danny Ryan:The “O” in P.A.S.T.O.R. is for “offer”. This says, “Describe exactly what you’re offering for sale, focusing on the transformation instead of the deliverables.” Here, I start this off with, “Now, it’s your turn.” I was putting together this concept of the Jive migration pack, which you get the key to when you download this. You get the key to stop paying for ongoing fees for Jive, month-after-month.

 

Get key content up-and-running in Office 365. Remove the confusion about what goes where. Drive out risks with the migration by using a mature tool with improved process. It all comes as part of the Jive migration pack. We currently have up on the website a trial edition of our migrator tool. Then, I was going to take some of the other resources that we have and basically package them together. Stuff like some of the blog content that we have, an example mapping document. I have an ROI calculation spreadsheet that I typically use with customers.

 

I say, “The Jive migration packet is free. There’s no risk on your side.” This is really getting into marketing stuff, you’ll have to have anything to add to it.

 

The response, which is the “R” in this, asks the customer to buy with a step-by-step instructions and telling them what to do next. The last part of this is, “It’s decision time. You have a choice to make. You’ve been doing what you’ve doing …” Part of this is just trying to get them to move off the dime.

 

Tommy Ryan:Do it in a way that’s easy. For someone, they feel like, “Okay, it’s worth to take this next step and what I get in this next step is worth what I’m giving.” I think we were talking before, “Is it just an email?” or do we provide more structure with, “What’s your environment? What are you trying to accomplish?” Striking that balance. Maybe, it’s best to get an email and start the conversation and not have to have too much structure from the beginning.

 

Danny Ryan:Yep. Yep. I think if it’s just the first step in the process, all we really need is the email address. That gives me enough to follow up contact with them. It’d be nice to have first name, last name, but do we really need to have it. Part of it tells me if they’re really a serious customer, because they’ll use their corporate email address. If they are serious, they’ll use their Gmail address or whatever address if they’re shopping around or if they really don’t want me to know who they are. You can derive a certain amount of information off the email that they’re sharing as well.

 

Tommy Ryan:Right. Right. It’s true.

 

Danny Ryan:This is the one pager on if somebody came to the site and trying to describe their problem or trying to describe how we’ve solved it. We’re trying to describe how we’ve solved it for other people with testimonials. Then, we’re saying, “This is the next step. It’s obvious. You either do this or you don’t do this.”

 

Again, I think really the purpose for this up on our website is to get them to move off the dime. It’s to have them from going, “I’m just doing some research and reading up on what we’ve done to actually starting a conversation with us.” Really, it’s serving the purpose of initiating that conversation and making it very easy for them to do that.

 

Tommy Ryan:Yeah. I think the challenge with this is how much story do you tell versus allowing them to go through those steps quickly to get to a point of a decision. That’s always the trick is striking that balance of how much content do we have versus what do we leave for the conversation after we do have that first initial email that we get and the conversation that we start.

 

Danny Ryan:Yep. Awesome. I appreciate you taking the time to do this, Tommy.

 

Tommy Ryan:Yeah. I know it helps you have a sounding board.

 

Danny Ryan:Yeah, absolutely.

 

Tommy Ryan:We’re recording this as a way to share with others. I mean, there’s other organizations that are trying to go through this same kind of process of, “How do I take the things that we’re passionate about doing for our customers and be able to articulate that in a way that speaks to how people really need to consume and act on websites?” This is an important thing for us. Hopefully, others can learn as we take this journey and improve the way we interact with our customers out on the web.

 

Danny Ryan:Awesome. Thank you so much everybody for listening. Have a wonderful day. Take care. Bye, bye.

 

Tommy Ryan:Bye, bye.

 

read more
Tommy RyanHow to Write Copy that Sells – Part 3 – Jive to SharePoint Migrations
deep-dive.jpg

Deep Dive into Migrator (Jive to SharePoint Migration Tool)

Okay. Just wanted to take a moment and walk you guys through, at a high level, what the Jive to SharePoint migration process looks like. I went ahead and I’ve actually set my background just to show the high level diagram just to explain what these little pieces are so I’m not going to spend a whole lot of time because I know you guys want to see the migration itself.

For the first part, equipment basically the migration process itself typically we would recommend that you have a couple servers or a couple VM’s. It’s not mandatory that you have a couple servers. 1 server or VM will work just fine. Definitely recommend at least a couple processors because what you do is parallel processing to improve the overall performance of the tool, but that’s just the recommendation. Also, basically having a Jive account that has access to everything, at least read access to everything. All the different places that would point to people migrating and a few other things like a decent network connection because we’re going to be hitting Jive pretty hard as well as pushing stuff into SharePoint so we need to be able to have some decent throughput for that.

Then the other thing is a fairly large hard disk or hard drive space so that we can store all the physical binaries that we’re pulling out of Jive and I’ll explain that here in just a minute. The first major thing we do, moving into the process, is we capture the inventory of content from Jive. The idea is that we want to pull the content from Jive into our local SQL Server database and partially into the file system so any of the binaries, the images, things like Word documents and things like that all get pulled into the file system but everything metadata wise, everything that connects the pieces together gets pulled into a sequel database and that inventorying process basically does 3 primary operations.

We do these in sequence. We do a command, what’s called get people, which means we pull all of the individual profiles and people references from Jive into our database and I’ll show that here in just a minute. Get places, it actually pulls all of the individual spaces, groups, projects, and blogs. Place is just a generic term to reference all 4 of those but we pull all the hierarchy into our database as well so we know a complete list of all the different places that are in Jive and then the next thing we do is we do what’s called a shallow pool of get content so for all the places that we pooled into the database, we want to pull that content. Shallow basically means we’re not pulling all the binaries and we’re not going any deeper what the API Jive has allows us to see. We’re just going to pull up the basic content so we can get some counts, so we can have a high level idea of really what’s out there.

Moving on from there, we go in and we look at the output, we produce a spreadsheet typically as a result of this inventory phase and we transition into the para phase where we actually go in and produce a spreadsheet. We go through and define, what are the SharePoint structure? What should it look like based on what we see in the spreadsheet? Do we need to provision any site collections? Are there any managed pass we need to be aware of? Do the basic design of what the SharePoint environment’s going to look like and really leveraging the inventory that we pulled in the previous step. From there, if we’ve got a substantial amount of places to migrate, we typically break things down to some logical groups. If we have a large amount, it’s typically that we do it in groups of 1,000 and work with that at a time.

Then that’s the breakdown of where we were from a client perspective. Internally, a lot of time we’ll work with batches of 50 at a time so we can better manage what we’re actually pulling out of Jive, what we’re actually transforming, what we’re actually pushing into SharePoint and be able to validate, get a little smaller chunk. Overall, though, we try to do things at a large level like 1,000 at a time.

Then we move into more of the migration phase where we’ve got everything planned, we pulled out initial content, now we need to go through and there’s essentially 4 different commands we do for each of the batches and that batches of 50 is what applies here. We validate and if a SharePoint site is not created, we validate and see that it exists. If it doesn’t exist, we have the ability to create that on the fly.

If needed, we need to recreate the SharePoint permissions. Probably won’t get too deep into that in this particular demo but we can definitely talk about if that is something that’s important to you. Get content is also run here. You saw it was run at inventory but it’s also run here again where we actually do a deep pull, so not a shallow pull. We’re doing a deep pull this time to pull the actual content and binaries and everything into the database and file system. Kind of some new commands we’ve got here. Transform content basically what that does, it takes the content we’ve pulled out of Jive and it makes it ready for SharePoint so think of all the URLs, things that pointed to between documents, between places, things may point to Jive, things may point to a user profile in Jive. We take it, scrub, and change all that so that it actually references SharePoint and the SharePoint equivalent.

That’s what goes on in the transform piece. Make sure everything is SharePoint ready. Then the upload content is the final command that says, “Okay, everything that you’ve transformed and you’ve prepared for, let’s go ahead and upload that to the target SharePoint file,” and that’s really what completes the migration.

Then really once we’ve done that, we’ve done our batch of 50 let’s say, we’ve gone through this process, then we go through a validation phase and we check a certain number. We validate counts to make sure things look … With the same count that was in Jive and do we have that in SharePoint, we do some basic inspection to make sure links and things are working properly and then we have some high level checkpoints to go through before we transition to the customer to do a deeper inspection. That’s the high level process.

Really what we’re going to dive into is really the migrate stage. I’ll show you a little bit of the prepare in the batch portion of it but we’ll dive into the migrate so you can see the commands, how they execute. I don’t want to bore you with the inventory process because it takes a while to run some of these and not really conducive to a good demo. That’s basically the high level process. Hopefully that makes sense.

Just real quick, another follow up to the inventory process just so you guys can see the database that we were talking about earlier. Typically we create a Jive to SharePoint database. The first time the tool or utility is run, it will actually create this database for us so as long as we have a valid connection string, it knows how to create the database and the structure. I think I mentioned here earlier that we do a get people, get places, and a get content so just to translate that for you guys, if you come into the database and you’ll see a multiple set of tables here. If you go into the Jive persons, that equates to the get people so if I do a quick select on that, I can see that I’ve got in this case I’m running against the Jive sandbox which is just a generic container or generic Jive environment.

In this case, I’ve got 561 people that I was able to find in the Jive sandbox so that’s the result of get people, it produces this structure. Same thing for get places. If you go to the Jive places, I pulled 1,000 rows there and you’ll see a list of all the different places and if you look here, you’ll see blogs, projects, you’ll see groups, you’ll see spaces so those are the 4 different container types that really make up a place. Here’s all the collection of places we found. Actually found over 1,000 because that is what we’ve limited it to. Let’s see what we actually have here. 1,939 places. That’s what we found in the Jive environment.

Then the next level would be going to Jive content and if I select from that, you’ll see that there’s content here as well. One of the things you’ll notice, you’ll see content and then transformed content. When we actually do the real transform, I think I mentioned to you earlier, that is the process that takes the Jive content, scrubs it, makes it ready for SharePoint so you can see that some of these have already been done. We actually store this transformed content into this particular table as well so that’s that transition from inventory into the actual migration itself. I’m going to stop here and we’ll pick back up with the physical migration.

Okay, so as we go back to our diagram, we’re getting ready to prepare and then create the batches for our particular migration. In this case, we think we’re just going to migrate a couple places just to keep it simple. What I’ll do is I showed you the database. What we do is we actually have a query we run and we produce a resulting spreadsheet from that database. This is where we would hand off to the customer or actually work with the customer to go through their inventory of all the different places. This is very similar to what I just showed you in the database with the Jive places table. It’s got all the place ID’s, it’s got all the place names, everything is in here. The types. Basically a full list of places as well as content counts. How much content is associated to each of the different places based on the types?

Not a whole lot showing up here just because it is the Jive sandbox environment. If I go off to the right, in fact let me do this real quick, I’ve actually got a couple places in here that I’ve set up to be the ones we want to migrate. In this case, I said, “Let’s go ahead and make these our pilot sites,” so a lot of times when we do a migration, we’ll do maybe 10 pilot sites. In this case we’ll just do a couple. I’m doing the Lisa test group 3 and then the Lisa test group 3 blog that lives underneath that particular place.

This is the resulting or this is the source Jive environment that we’re going to be looking at. If I come over here, the reason I wanted to show you this is that this is the spreadsheet that we work with the customer to determine where things are going to go into SharePoint so what I’m doing is I’m saying, “I’m going to use the site’s manage path,” just a standard manage path in SharePoint. We can use custom ones if you’d like. A destination site, in this case it’s my dev site and then I’ve got a structure that I want to use underneath this, current, and then another site underneath that. Lisa test group and the Lisa test group blog so we’ll see how the tool will actually use this information and create these as needed and then actually migrate the content of these particular locations but these are the fields we would actually use and also in the database itself to direct the content, where how it goes from Jive to SharePoint. Here is our source Jive place that we’re going to be starting with, the Lisa test group 3.

Just has a bunch of just test content, things special characters. Just some basic content we’ve used to try a different edge cases and really test the product itself but just wanted to show you that this … How the migration process works so it’s simple for that. There’s 44 pieces of content here. That’s a mixture of Jive documents, document like Word documents, discussions, there’s even a couple of videos in here. I believe there’s blog posts so one of the distinctions here is that blog posts look like they live in the same place in Jive but they actually in reality live in a sub site so what we’re going to do is migrate this place into SharePoint but then we’ll also migrate the corresponding blog and blog post into SharePoint as a separate sub site of a … Called a blog so we’ll look at that here in just a minute but just wanted you to see the structure, how things are in here, and how things are going to look when we go into the SharePoint environment.

Let’s just pick one so we can have something to reference. Lisa’s awesome discussion. Basic details, here’s some headers, some images, some text. We’ll look at the same sort of thing in SharePoint once we’ve done the migration. Now we’ve got the commands up here. Our little cheat sheet of commands for doing a migration for 2 particular places so we’re going to walk through these and I’ll show you how to execute them on the command line itself. I’m going to go ahead and kick this first one off and then I’ll explain what it does.

The first one we’re doing is called validate sites and you can see here, they all start with the same sort of ideas that J2SP, Jive to SharePoint. Dash A says action and validate sites. Validate sites, what it does is it says based on these 2 different places, these place ID’s. Dash I’s are the place ID’s, go ahead and verify to these places based upon our mapping that we talked about earlier, are these places already set up in SharePoint. If they’re not and we have the dash C option, it’ll go ahead and create the places for us so let’s take a look at our log file and see what it did. All right, so we always want to look for true in the log file for this particular command. We can see here it’s got the dev C Edwards. Found that, return true. Then either found or created the dev CA words current AA Lisa test group 3 and the same thing for the blog. Return true in both cases. We found our items, we found our places, which is great. That means we want to move on to the next command, which is to get content.

We talked about getting content earlier with inventory. We kicked this off and I’ll explain what it’s doing. Get content in this case, we’re doing something a little bit different. We’re doing a dash B for binary so we’re pulling the binaries. We’re going deep which basically means if we need to pull categories or other things that are related to content, which requires additional API calls, we do those as well. The dash F says do a full pull so anything that’s changed since it basically doesn’t matter if it’s changed or not, just pull everything again. Dash P says run parallel so if there’s multiple processors in the machine, we can actually take advantage of that and then the dash I for the place ID’s is consistent through all those commands since these are the places we want to pull and then the last part of it, I don’t know if I mentioned earlier is basically just a pipe to a log file so we can actually see what the output was of this command. Actually, if you look at this you can see that it pulled a bunch of content here.

I won’t bore you with all that but it took 29 seconds basically to pull the content for those 2 places so not too bad. Let’s go ahead and run our transform content. Transform content doesn’t take all the command lines options, the other ones did but from above it, just basically takes a list of place ID’s, like I mentioned earlier, what transform content does is it takes the content we pulled from Jive whether it’s in the database or in the file system and makes things ready for SharePoint so it fixes profile URLs, it fixes any link to images, fix link to content, makes sure that everything is related to SharePoint and that’s all that’s addressed here. We’ll let this one run in the background.

Actually, while this is running, we haven’t actually uploaded content yet so this may take a moment to run because we’re still kind of haven’t pushed anything to SharePoint yet, let’s take a quick look at our SharePoint sites. If we come here, some sites. There’s our AA Lisa group, test group 3. We can see here that there’s really nothing in here yet. If we look at the content, there’s 0 documents and really no content’s been uploaded. I can tell by looking at the menu but for you, you can tell there’s nothing in here. It did create the subsite for the blog. AA Lisa test group 3 so we go into that. You’ll see the blog site is being created. Just with the generic empty blog. If I look at the post, there should be nothing in here yet except for the initial blog that gets created when the site’s provisioned. That’s all what we want it to look like. Let’s go ahead and go back to our test group 3.

We’ll leave it set here until we come back to it. Let’s see how our transform’s doing. It looks like the transform finished so let’s go on to our next command, which is the … Oops we don’t need that. Let’s go into our next command, which is the upload content and here’s where we physically begin pushing stuff into Share Point. I hope I pasted that properly. There we go. All right, so here’s where we’re actually physically uploading the content into Share Point and just to prove that, if I come back in here and I go to select contents, you’ll actually see some stuff changing. You can actually see a Wiki page, a Wiki library’s been created now, a discussion’s been created and things are getting uploaded as we talk. If we go back to home, the menu structure’s to be a little different. This will actually get changed at the end. It will update this but I can tell based on the fact that it shows video as discussions, Wikis that it’s actually in progress of uploading content so that’s a great sign.

We can actually look at the upload. We can see that it’s doing some work. This might take a little bit of time. Okay, so we see now that the upload content’s finished. Let’s go ahead and take a look at the resulting content in our migrated site so if I come over here and I click on documents, first thing you’ll notice is kind of our default, our standard way of transforming and uploading this content is to use a Wiki library, really because we can maintain the relationships that Jive has between containing content, content and then socialization settings like likes, things like that. We want to make sure all that stuff is maintained properly and Wiki libraries have been the best ways of doing that. There’s other ways of doing it and we are not necessarily set on this. This is the default mechanism the tool uses is a Wiki library for collaborative documents, files, photos, things like that.

Let’s go ahead and jump into a document. You can see here, I’ve got some basic information about the document, in this case has an attachment, so we maintain attachments. Describes what the document is. Again, there’s not a whole lot of real HTML rich content here so if you actually had rich content, you’d see it represented here in that sense. Let’s see if we can find some stuff that has a little bit more stuff in it. Let’s go to another document. Here you can actually see one with international characters so if you click on that, you’ll see we actually maintain international characters across this. Let’s pick on maybe an actual report like a Word document.

Here you’ll see a Word document, I click on this, it’ll actually take me to the physical Word document, I can download it, open it, work with it just like I did before. That’s the essence of the documents, files, binary files, photos, things like that inside of … From Jive. If I click on this, you’ll see an actual photo is uploaded. Discussions are a little different. They’ll go to a separate library, it’s actually a discussion library in SharePoint so we have native discussions and if i pick one of these, you can see it has an image inside of it. Here’s a picture of a ring, obviously and some commentary around what that was. It’s an actual discussion, a thread of discussions all represented here in native SharePoint form. You can see the 4 replies.

If I go, let’s pick a different one. Here’s also some discussion that has some of the representation of some of the international characters. Again, a lot of this was test content so it really used just to make sure all that was working properly. Let’s go into the blog site. We’ll actually transition into the blog site, which is a separate template. If you scroll down, you’ll see the order that they were actually created in. You’ll see attachments. If I click on one of these, you’ll actually be able to open and interact with the attachment. See that downloaded, see the images, more attachments. So on and so forth. All the blog content is maintained in a sequence and we actually do leverage the SharePoint blog because why not use standard SharePoint functionality to do what it’s designed to do?

The next real step from here would be to turn things loose to validation so we would go into a deeper look at the counts to see did all the counts of content from Jive, does it match up with what we have in SharePoint and then we do a much deeper dive in terms of looking at the links. We actually have another utility we use that validates all the links, all the images, making sure things got migrated as they were expected to be and then if there’s any issues at all, we have a way to repair that stuff but typically we like to try and validate and get it right up front.

That’s basically the essence of the migration and hopefully this makes sense to you. I’m sure you guys may have some questions but at least you get a sense for how this all fits together and works so thanks for watching.

One thing I forgot to mention earlier or forgot to tie back to is that we looked at a particular discussion in Jive and wanted to see what that looked like in Jive so this is Lisa’s awesome discussion you saw earlier. If we go back to SharePoint, you see Lisa’s awesome discussion. Same basic structure, everything maintained. Again, not really real content here. It’s just more of a test content just to show that we can move stuff around really for test cases but just wanted to kind of bring closure to that, make sure you guys see the resulting content.

read more
Chris EdwardsDeep Dive into Migrator (Jive to SharePoint Migration Tool)