tim-tag-office.jpg

Catching Up with Tim Coalson (Nov 2017 Version)

Danny Ryan

Host – Danny Ryan

Bio – LinkedIn – Twitter

Tommy Ryan

Guest – Tim Coalson

Bio – LinkedIn

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

 

Tim:I’m doing well. Thank you.

 

Danny:Very good. Very good. Tim sits right across the wall from me. Every once in a while, I get to hear some interesting things coming from his direction. Always keeping it professional, business-like but it’s a fun conversation …

 

Tim:Of course. Of course.

 

Danny:… we have to be in every once in a while. I will-

 

Tim:I am the epitome of professionals.

 

Danny:You’re an architect too, right? Is that correct or some-

 

Tim:Yes.

 

Danny:What’s your status nowadays? Have you reached any enlightened statuses at all recently? No? I wanted to catch up with Tim, see how things are going. Just have our quarterly chitchat, and I think, for this when we just wanted to talk about some, I guess, recent projects or projects that we’ve had over the last couple of years and just some of your thoughts on those projects.

 

Tim:Yeah. Since I didn’t want to take time to write a blog, I was thinking, “What can I talk to Danny about?” One of the things that prompted, I guess, what I wanted to talk about today was, within the last couple years, ThreeWill has started to focus in on the various areas, so the principal consultants are assigned as principals of each different areas that we, I guess, approach at ThreeWill, the things that we focus on. I figured I would break it down into those principal areas that we focus on and talk about the different types of projects that I’ve worked on as well as the ones I, I guess, like kind of least favorite to most favorite.

 

Danny:These are the different practice areas like migrations …

 

Tim:Exactly.

 

Danny:… portable apps and sustainment. Have you been on each type of project?

 

Tim:Yes. I’ve worked on each of those over the years.

 

Danny:Let’s start with your favorite, migrations, right?

 

Tim:Yeah. That’ll be my least favorite. I was thinking about, “Okay, why are some of these more favorite one do I enjoy some of these more than the others?” The thing I concluded was, really, for me, I enjoyed a personal interaction. Some people are going into a closet, burying their head in code and writing code for me is more interaction with people whether that’d be people on my development team, whether that’d be the customer. In, I guess, an ideal project, it’s both where I’m interfacing with the customer team. I’ve also got other team members I’m working with and then, together in a collaborative way, we create a solution that is not only functional and helpful for the customer but also something that is appealing, something that has a nice looking user interface that’s engaging that people don’t dread using and ideally, something that people will actually enjoy using.

 

As you think about migrations, one of the way I think about migrations is, if I were going from one email provider to another, in the end, it’s email and I’m not going to really feel like the only thing you’re going to get credit for is if you do a bad job. Because in the end, if you do a good job, then it’s pretty much what I had before. Maybe it’s on a different platform, but you move me, not, probably, give me a lot of different functionality. You’ve just taken me from having a certain functionality on one platform. Now, I have that functionality on another platform. Usually, people underestimate the effort involved. They’re disappointed when they realize, “Wow, it’s going to cost a lot of money to keep the same functionality I have.” A lot of times, it’s driven by licensing. Maybe they’re getting rid of an old product that has a expensive licensing renewal and maybe moving to Office 365 because maybe it comes with some new subscriptions that they’ve purchased. It’s essentially free or a lot cheaper.

 

For me, migrations, out of all the things that we do, is probably my least favorite. However, certainly, is useful for certain customers at certain times. Probably the next one I think about is collaboration spaces. Whether that’d be an internet, whether that’d be an extranet. Usually, places where people need to collaborate around certain content. In some cases, people wanted to make that appealing looking. We’ve done some, in addition to out of the box functionality of SharePoint, we’ve done some more custom UIs that make the experience a little bit nicer. In some cases, we’ve added some custom features within the site to make tagging data a little bit easier. That way, the search is more effective across the site.

 

Sometimes, we’ve created templates so that sites can be recreated, so that project sites can easily be recreated from a template where they’re consistent across all the different projects. That way, when someone moves from one project to another, they can already anticipate what the structure is, which makes it easier to find, the different types of documents they’re looking for. Those are also pretty fun to work on as well. Usually, you’re interacting with the customers to decide, “Okay, how do we want to build out this project site to make it the most useful or the most beneficial?” Sometimes, there are different types of project sites depending on the types of projects. There are different needs where there’d be document libraries or different list, features, custom list. That’s also pretty involved working with the customers. I enjoy those as well.

 

Public websites, I’ve done some of those both with SharePoint as well as outside of SharePoint. Currently, I’ve been working on a public website for two years now that says, “A support site for attacks in the other team product company.” They sell products. They sell books. They have the general types of support wanted on a site. You’ve got knowledge base. You’ve got search capability within that knowledge base. You’ve got the ability to create tickets, web cases. In this case, you’ve got the ability to chat live with a customer service representative. You’ve got the ability to search within the site, not only the knowledge base content but other content around their products. What’s nice about that is. Generally, it’s something that UI is very important because you want to make the user experience nice. We get to spend quite a bit of time working on the user interface. Those are fun to work with.

 

You have an intent of you put yourself in the position of the people that visit this site. Okay. If I’m visiting this site, what would I want my experience to be? What are the type things I’m going to be looking for? Based on that, then you want to try to customize or optimize the site to make that experience as good as possible. I’m a consumer. I use an AT&T website for my mobile phone. I use Comcast or Xfinity for my cable providers. I know the types of interactions that I have with a public website, particularly a support website. As I think about that, then I think about, “Okay, customers are going to come to this support site for similar reasons. How can I make that experience as good as possible, not only from a visual perspective but also ease of use? How can I make it as understandable as possible where they can find what they need and get on with their business?” Public websites are a lot of fun.

 

Probably, the ones I enjoy the most, however, are departmental applications. Usually, there’s a fairly small subset of people that use this site. There’s usually a defined process or business process that they’re trying to follow. It’s about, “Okay, how can I create an application that’s going to support that process whether that’d be a process that needs to work through some approval process?” Those are pretty popular. Those were able to leverage a lot of what’s built into SharePoint for those types of applications because SharePoint does have approval workflows built in. We’re able to customize those to meet various types of approval processes. Sometimes, that might be a single approval. Sometimes, it might be an escalating approval where we might have two or three people involved in the approval process.

 

Within those departmental applications, of course, we’re interviewing different users; understanding within the process, maybe, two, three, four different user types; what is their role within this process; what kind of views of the data do they need at any given point and time to say, “Okay, what invoices are being approved? What’s the current status of invoices,” for example. In some other cases, it’s been approval of messaging that needed to go out to customers in an envelope. We’ve done various types of departmental applications over the years. For me, it’s just a lot of fun to work with all of the different people to understand, “Okay, what are their needs within this application,” and then create something that helps support their process, that it gives each user the information they needed at the various points in the process to be able to do their job and in the end, just adds value, makes their job easier, makes them more efficient, more productive.

 

Danny:Nice. I guess the last type of project, have you done stuff with Sustainment?

 

Tim:Yes. Sustainment is, in a lot of cases, a lot of the Sustainment work I’ve done, at least, has been part of working on departmental applications or working on public websites. We’re doing the ongoing maintenance as new features come about. For example, today, on a lot of support sites to help call us for the companies and be able to provide quick answers to customers, a lot of bots, now, are being used to help answer questions sort of automated chat instead of chatting with a live customer rep, you’re chatting with a robot. That’s a fairly recent technology. Within that sustainment process, we might be asked to add that to an existing website. It’s not a brand new rewrite. It’s just a new feature that we might want to add to a public website.

 

Within Sustainment, I’ve added a lot of new features to different applications. Maybe a new report, a new view of data someone thinks about that would be helpful to help support their job. A lot of times, that’s where Sustainment comes in. They give us a call and say, “Hey, I’d like this new feature on an application that you wrote for us and that you’re doing sustainment for us. Let’s talk about what are the requirements. Could you give me an estimate and then let’s build this to help make the application better, help it evolve as requirements change over time?”

 

Danny:Nice. Nice. Well, I appreciate that I think, in the end trying to help out these different departments, something that’s going to make a difference in their day-to-day, I think, I hear you there. That’s going to be all nice to be able to do that and then …

 

Tim:That’s the rewarding part …

 

Danny:Yeah. Yeah.

 

Tim:… at the end of the day that you’ve created something that people find useful.

 

Danny:You must be excited that I’m focusing in on a lot of migration work, right? That’s-

 

Tim:That’s why I’m going to stay on this public website for another couple years.

 

Danny:No. Well, their projects come after that. It’s a really good way to get to work with new clients. I think a lot of people, even though you could have someone who’s not very educated about what it takes to migrate, that’s part of my role. It’s to communicate, “Hey, we’re not switching out email” or “We’re moving from one platform to another platform,” and that’s never easy. Somebody who’s been in the industry for a while will know that but still, you’ve got to be able to communicate that. Fortunately or unfortunately, it makes a lot of sense to have outside firm like us do that because why do that because you’re only going to do it once. That’s-

 

Tim:Right. Part of the concept of our practice here is, we’ve done this over and over and over. We know what to expect, one going from platform A to platform B. We’ve done that before. We know some of the gotchas that you can anticipate. We can communicate those to you upfront and set an expectation. “Here are your options to overcome that” or “We’ve figured out how to fix this so we can address that.” They’ll give you options in various ways you can approach it or if it’s something we’ve solved where a customer doesn’t have to choose an option. We just fix it. We make it work as they would expect. That’s, I think, one of the key advantages to our principal, to our focus areas. Our practice area says that we do kind of work within those to gain expertise and then can help as we work with the next customer. All the previous experience that we’ve gained with other customers, they get as a result of this practice area focus.

 

Danny:Are you sticking around for turkey day or going somewhere?

 

Tim:I’m not.

 

Danny:Where are you going?

 

Tim:Heading to my family’s house.

 

Danny:Nice. Very nice.

 

Tim:Yeah. I’m looking for the-

 

Danny:When are you taking off? Tomorrow?

 

Tim:Today.

 

Danny:Today.

 

Tim:Of course, I’ve got a deployment tonight at midnight. Tomorrow, I guess.

 

Danny:Well, thank you for all that you do. I appreciate making a difference in a lot of these departments and continuing to learn and continuing to be open to new things and learning new things and sharing with others and thanks for all that you do, Tim.

 

Tim:Sure, Danny. Thanks.

 

Danny:Yeah. Absolutely. Thank you, everybody, for listening and have a wonderful day. Take care. Bye-bye.

 

Additional Credits

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

read more
empty.authorCatching Up with Tim Coalson (Nov 2017 Version)
truth-sharepoint-online-migrations.jpg

The Truth about SharePoint Online Migrations

Will Holland is an Software Engineer at ThreeWill. Will has proven to be adept at understanding a client’s needs and matching them with the appropriate solution. Recently he’s developed a passion on working with .NET, MVC, and cloud-based solutions such as Microsoft Azure and Office 365.

More and more people are beginning to look to the cloud as a reliable, affordable, and safe alternative to keeping and maintaining their own server infrastructure, and rightly so. For us here at ThreeWill, that has meant we’ve seen a huge uptick in people looking to migrate their on-premise SharePoint farms to the promised land of SharePoint Online.

If you’re finding yourself considering the move, then this blog post is most definitely for you. Before I get started with the meat of this post, though, let me state what might not be obvious; especially if you’ve been through an on-premise SharePoint migration: Migrations to SharePoint online are hard, complex, and time-consuming.

The good news? We can help! We have a lot of in-house experience at ThreeWill. I have personally been involved in my fair share of migrations as of late and, for the foreseeable future, it looks as though I’m going to continue doing so. We have a dedicated “migration practice“, led by the wonderfully brilliant Kirk Liemohn, and teamed with people (like myself) who truly enjoy the challenges that come with it.

But I’m not writing this blog post as a sales pitch. No. I’m writing this blog post as a reflection on something that I feel I’ve personally not done a great job at doing: Really setting expectations. We try to, as politely and positively as possible, let you know that a challenging road lies ahead…but it always seems to surprise folks when something ugly pops it’s head up.

And that’s what this blog post is about. This is the brutal, honest truth about migrations.

There’s nothing easy about it

On the surface, a migration seems straight forward. You want your cheese moved from Point A to Point B. Simple as that. It’s an easy trap to fall into, and one that I’ve fallen into a few times myself. It’s also one of the things that make migrations such a personal challenge for someone like me.

Most “dev” projects I’ve been on, my client has some high-level idea about the end product they’re looking for, but it’s usually never an extremely well-defined piece of software. In fact, only once in my time doing this have I had a client know exactly what they wanted, feature by feature. As a consultant, that gives us some wiggle room to adjust where we set the bar, allowing us to set it a reasonable height, and provide the possibility to exceed it.

Migrations, on the other hand, everyone knows exactly what they want. Everything from over here to over there. What’s worse, if you did a migration from SharePoint 2010 to SharePoint 2013, it was almost that straight forward. There were very few things that wouldn’t just migrate and unless you were doing some major architectural changes, you could basically just move your database from “here to there”.

SharePoint Online migrations aren’t, unfortunately, that straight forward and it’s best if you just go into one with that understanding.

Not everything’s gonna make it

To make SharePoint online a reliable environment, Microsoft has put certain limitations on what you can do in your own tenant. They do this to prevent anyone from bringing the whole thing down, which would obviously be a bad thing.

These restrictions take multiple forms, and impact migrations in different ways. The most obvious of these restrictions is that most all of your custom code will not be allowed to even be installed, and any content (such as custom branding) that gets deployed through those solutions, they won’t migrate either.

Since there is no server for you to run code against, the only code a migration tool can use to migrate is CSOM. That means that there are some limitations as to what a tool can do. For example, you can create a list, but can’t specify a list’s GUID – which usually isn’t an issue, but can wreak havoc if you have custom JavaScript or workflows depending on that GUID.

Workflows are another thing that is troublesome at best. 2013 workflows, and any reusable workflow, and any running workflow instance just won’t migrate, period. 2010 workflow definitions can, but there’s no guarantee that they’ll be working if, for example, there’s a URL to the ‘old’ farm used in a workflow action.

InfoPath forms are another thing. The form itself can be migrated since it’s essentially just a file, but they’re going to require manually inspecting and correcting of any issues.

There are also some non-specific things that won’t make it. Every migration I’ve been involved with has had at least one publishing library that someone added several hundred documents to and then decided to add a column and make it required, which results in all of them remaining checked out to the migrating user.

There’s a fair-sized handful of things that can be an issue. Fortunately, Microsoft has released a script they call the SMAT tool to help identify some of these issues, but even that doesn’t cover it all. Unfortunately, the only way to figure out everything that won’t migrate is to try.

No one is going to be excited about it

This is probably the hardest aspect of any migration, especially from an outside perspective like mine always will be. We rely so heavily on users, who we refer to as “Subject Matter Experts”, to help validate and identify any new issues. It’s so critically important that they get in as early as possible to find those issues so that we can, hopefully, come up with a remedy and avoid those mistakes for any remaining migrations. We’re always so optimistic at the start of the migration that user involvement gets taken for granted.

Here’s the catch, though. Practically none of them will do so voluntarily. They have their own jobs and responsibilities to worry about. So long as they have their old site, they’ll wait until they no longer have a choice to deal with the new one. The only problem is that they really are critical to the success of a migration.

If they’re not proactive, you must force them into action. Without them, there’s a very high likelihood that you’ll make it to the end of your migration and then be hit with a huge influx of issues and a very poor favorability rating.

Planning and communication are key

The lynchpin of any migration, more so than any other kind of project I’ve been on, is planning and communication.

Each one of the truths I outlined above can be overcome just by coming up with, and sticking to, a plan. Some of the decisions you’ll have to make will not be fun, and the people affected by these decisions will not be happy about them, but so long as you communicate what’s happening…you’ll end up at the best possible location.

You’ll need to come up with a plan or policy for how to deal with everything that won’t migrate. Whether it’s something that you’ll be manually recreating, instructing your users to recreate, or just leaving it behind altogether – you need a policy that you can point to and explain.

Having a Pre- & Post-Migration “runbook” that you can distribute to your site owners is hugely helpful. These should contain the things that every site owner needs to do before and after, including things like “complete all running workflow” or “check to ensure that your InfoPath forms are working”

You’ll also need to come up with a plan on how to compel your site owners to aid in validation. Usually, the most effective way to do this is to put their “old” site into Read-Only mode once the site starts migrating, but there are other ways as well.

Really, if the only truth you remember from the post is this one, you’ll be in pretty good shape.

read more
William HollandThe Truth about SharePoint Online Migrations
why-sign.jpg

Why the SharePoint Framework Will Change the Way You Customize SharePoint

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

With Microsoft driving cloud adoption through Office 365 and SharePoint Online, the development framework of SaaS solutions had to change in order to facilitate the move to the cloud. Enter: the SharePoint Framework (SPFx).

Considered a huge departure from the traditional model, the SharePoint Framework required developers to cross-skill to adapt to the new tool chain. By unpacking its features, developers can have a proper understanding of what is required to not only build new SPFx applications, but to also migrate their existing solutions to SPFx confidently.

During this 30-minute webinar, we will focus on the technical aspects of the SharePoint Framework and help you realize the full potential of a customized SharePoint environment, including:

  • the SPFx differs from “server-side” applications.
  • What the tool chain comprises of.
  • How to easily transition across to the new model.
  • The controls, deployment, and configuration options available.
read more
Danny RyanWhy the SharePoint Framework Will Change the Way You Customize SharePoint
complex-sharepoint-migrations.jpg

Is Your Organization Prepared to Do a Complex SharePoint Migration?

Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.

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?
shutterstock_156929909.jpg

Large and Complex SharePoint Migrations Webinar

Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.

Danny:Danny Ryan, I’m the Co-Founder and VP of Business Development for ThreeWill and I will host this and I’m not hosting it quite well. Hopefully it’ll go a little smoother from here. I’ve got Kirk Liemohn here with me, Kirk is a Principal Software Engineer, a Migrations Practice Lead. Thanks for joining me, Kirk.

 

Kirk:Sure.

 

Danny:Awesome. So we’ll go ahead and jump right in since we want to … In this discussion, if you’ve got some questions that you’d like to ask please ask those questions through the … GoToWebinar interface. I see that a lot of people have figured that out so far.

 

We are covering primarily a white paper that was produced by Kirk. In fact it was so large that we’re calling it an E-book, it’s about 26 pages and it covers large and complex SharePoint migrations and some of the things that we’ve learned through the years. With that you can download that again through the … GoToWebinar interface, there’s a PDF that’s in there and feel free to download that. So let’s jump right in. … Let’s jump in for the second time, how about that?

 

Kirk:Yes.

 

Danny:That first thing that you go through in the white paper is a discussion about whether your organization is prepared for the migration. Tell me more about that.

 

Kirk:One of the main things there, obviously, is has your migration done this before? Has it done a migration before? Maybe you’re going from 2013 to 2016, those were the SharePoints this time but previously you’ve done migration from SharePoint 2010 to SharePoint 2013. If that’s the case, then you’ve got a lot of experience to draw upon and you can take what you did well before and use that. Those things that you didn’t do so well, you can try to avoid the same mistakes.

 

Maybe instead, however, you’re going from SharePoint 2013 to SharePoint online and you’ve probably never done that before because you don’t usually migrate there twice. Although maybe different farms you can do that with. So there are some different challenges there, you just need to realize that and then realize that, “Yes, we got some experience with migration but there’s some aspect that we don’t know as well.”

 

Other aspects are, do you have skilled resources for the migration? This could be anyone from project managers, tier 2 support type thing, developers or people to help manage the migration, IT personnel, communications, those types of things are important to have a successful migration. We’ll get into some of those a little bit more.

 

And then I think it’s really important to understand, do you have the time to do a migration? Do you have a reasonable deadline as to when this has to happen? As we have seen before, especially with our Jive to SharePoint migrations, this can … Sometimes our clients come in and want something done in two months and that’s just not a very reasonable timeline a lot of times. For a very large and complex migration, we probably want it to be a year or more out that you’re going to need this thing to be done.

 

And then finally I would say senior C-level type or senior executives, you need someone on there that’s an advocate for this project, the migration project. You need the CIO, CTO, someone like that that can say, “Yeah, we need to make this happen here. Why we need to make this happen.”, and work with that individual to give them an understanding of what the process is going to be like. What’s the end user experience gonna be like? Because you’re going to be moving people’s cheese, and it’s gonna potentially cause some people problems and you want everyone to understand this. You want to communicate it well, give the communications certainly a bit, but you also want some sponsor that can back you on this, and can understand upfront that there’s going to be challenges with migrations.

 

Danny:Now sponsors are usually somebody within the IT department?

 

Kirk:I could be. I guess it doesn’t have be but it typically is.

 

Danny:Okay. Then usually with these, we’re sort of looking at your own organization and a lot of these, for the large and complex migrations, really there’s a number of people who are involved. Your organization, the sponsor, the things that … the capabilities and also the amount of time that you can put towards the migration but then you’re also working with third party folks maybe … We’ll talk later on about off-shore resources and outside consulting firms. It’s almost like you’re putting together a larger team to go after this as well.

 

Kirk:Yes, support personnel, everything.

 

Danny:Let’s jump into number two. Should you automate?

 

Kirk:The first part of this is … Clearly for anything but a super simple migration you’re going to want to use a tool out there and that’s sort of a form of automation. You’re gonna want to find one of the third party tools to help you and that’s important in of itself. Then, do you want to automate on top of that tool? By that I mean, if you look at how a lot of these tool work, they let you go in with an interface and say, “Okay, I want to move this folder from my source environment to my target environment, or this library, this site or site collection”. They help you through that process, but a lot of times there’s a lot of configuration options. Like, “Okay I’m moving the site collection. How many versions of your documents and list items do you want to maintain as you’re moving it over.” You can configure that with a lot of these tools.

 

Well that’s only one piece. There’s dozens of knobs to turn with these more advanced tools, and you’re going to probably want some consistency.

 

In addition to that, if you’re moving a lot site collections, you may want to automate the process of batching these up and moving them over time. So maybe your doing 50 to 100 site collections a day, and maybe you want to run them in off hours based on the timezone of that site collection. Then maybe at the end of when it runs you want to send some e-mails, before it runs maybe you want to put a banner on the site to say it’s being migrated. There are lots of things you can do around that if you do the automation.

 

Then, of course, you can watch it from a monitoring stand point and understand. How many do we have active right now? Are we having problems anywhere? Do we have a capacity to do this? Really a lot of this depends on your method of migration. SharePoint, as many people know, … There’s things like site collection backup restore, database attach migrations, and then if you’re going to SharePoint Online you can’t do either of those. That one you have to use basically a tool that’s going to use CSOM or the Azure upload API, along with CSOM. There’s a lot of moving pieces, and you can’t do 1,000 site collections at once. It needs to be managed from a batching stand point.

 

Danny:There are a lot of tools that are out there. I know we’ve even done evaluations for clients just to see what was the best one for them. I know through the years we’ve, just because of our clients preferences, done a lot of things with Metalogix where we end up building on top of their tools, automating the tool, which has been interesting to see.

 

Kirk:Some tools don’t allow you to automate it and I think some have gotten better over the years. Metalogix is definitely one that you can’t automate it so they’ve got a relatively easy way to say, “Okay, give me the PowerShell script for copying this site collection over from one environment to another.” Then you can take that a layer in doing that on any site collection. Maybe you can find out when it’s done and do some other tweaks if you need to. If you’re automating you can overcome any deficiencies in the tool, or any custom things you want to do before a site collection is moved, or after any part of the migration.

 

Danny:We’ve got some folks from CASAHL on the line as well and how we use their tools to inventory things.

 

Kirk:To my knowledge that’s a lot of what they do is inventory. They do a very detailed inventory of what you’ve got out there. SharePoint doesn’t do a great job of telling you what’s in SharePoint. If you want to know things like, “Well how many farm solutions do I have out there?”, or “How many sandbox solutions do I have?” Maybe you’re moving to SharePoint Online where you can’t really do that anymore. What about running workflows? You can’t migrate running workflows to SharePoint Online, for example. How many are running? What about other things like, “The length of URL is too long.”, maybe it records some things like that, so lot’s of things you can inventory.

 

Danny:Right. This one I know, within the e-book is a long one. This is one of the longer ones. Since I helped format it a little bit, this was a longer one which was; break the process in to stages. We have lots of conversations around here about process and fun topics like that. What does this mean for a migration? Talk me through this.

 

Kirk:Sure. So we came up with … Obviously you have to manage this somehow, so you want to break it up into parts that you can think about a focus on. We broke it into four primary stages; Assess, Plan, Verify and Execute.

 

The Assess stage is the first one. That’s the one where we’re going to try and understand what it is you want to get done. We want to know what your goals are. We want to understand what the scope is. Are you moving two farms? One farm? How big is the farm? What site collections are not? What version of SharePoint are you on? We want to understand a resource plan. Come up with a schedule. Really get the lay of the land, initial communication plan, lots of things.

 

The next one after you do the assessment is the planning stage. That is the big one, so we even break this one down further into four more steps. Instead of planning we break it down into; Inventory, Map, Streamline and Communicate.

 

Inventory is what you talked about with CASAHL tool. Microsoft has a tool out there, some of the migration tool vendors have a tool as well. We even have one, our ledger tool.

 

Danny:Everybody’s doing it.

 

Kirk:Just to be the cool kid on the block.

 

Inventory is to understand what you’ve got and what you want to move. You want to take stock in what’s out there. How big is each site collection, if you’re moving site collections. You want to understand, is it business critical? Is it not? What about your OneDrive or user base data. Those types of things.

 

After inventory you want to map it. It could be a simple mapping exercise where you just say, “Well, we’re moving things from point A to point B. It’s a lift and shift. We’re keeping the same URLs except for maybe the beginning part or maybe we are keeping the beginning part the same.”, so same managed path, if you will, same URLs for the site collection, or are you going to do some reorganization a long the way. You could move a lot of site collections into the same site collection, or vice versa. As a simple example. That’s the mapping exercise.

 

The streamline exercise is really after you start to understand this stuff, you want to decide, are there ways we can automate this or make this better? This might be the time that you might define proof concepts that you need to get done, in terms of, let’s test out the tool in this way, or how are we going to manage this batching of moving all of this content over?

 

Then finally after streamline in the planning sub phase, if you will, is communication, and this one comes up multiple times in this white paper or E-book. This is just one of those times that you’ve got to communicate to others, what the plan is, what the customer requirements might be. So you might have farm solutions. You might have to deal with those. Once you’re done with this planning phase you can update your migration charter, basically your scope as to what you’re going to do and what you communicate to the team members as to what we’re doing.

 

Big breath.

 

After that phase we’ve got the verify phase, and that’s where we’re really dig in and say, “Alright, let’s make sure we can actually do this. Let’s take a subset of things.” This is where you might do proof concepts on the tool, do some tests on it, make sure that it’s hitting your primary business use cases that you have out there, that you know of maybe from your inventory. You’ve got to do pilots. So after you’ve gone through some of those, maybe you’re going to automate in some way, you’ll want to go ahead and set that automation up, code for it, prepare for it. Then at some point you can do pilots, and we’ll get into pilots some more, but that would be part of this verify stage.

 

Then finally, after that, is doing the real work, the execute stage. Ideally in the verify stage, you’ve done a pilot of enough of your process so that there’s not many surprises, but there’s bound to be surprises when you’re executing. The execute is where you’re going to do things over and over and over again if it’s a large migration.

 

Danny:A lot of these, it really doesn’t matter what you call them, you just can’t skip some [crosstalk 00:14:56] Call it your process, call it whatever you may, I think this is all designed around reducing risk. Looking at, how do we pull off a successful migration? Well, these are the things that we’ve noticed have to happen in order for us to reduce the most amount of risk-

 

Kirk:Right-

 

Danny:for it to occur successfully.

 

Kirk:Yes exactly.

 

Danny:Awesome.

 

Okay.

 

Number four. Drum roll please. Communication is … We talk about communication, it seems like that’s the central theme with you, right? I guess you can migrate to the best of your ability, but if you mess up the communication then it’s not a successful project.

 

Kirk:Right. We’ve seen before where … We need to communicate not only … There’s lots of people to talk to right, but if you don’t communicate to your end users and your site owners you’re gonna have some problems. They’re gonna start seeing things are happening underneath them and they’re gonna be complaining, and some of those people are gonna know the CEO. So you just need to communicate early, and well. We’ve got lots of way to do that.

 

We’ve got a few different documents that we think are useful through this process. One is a policy document and this will define what your policies are with the migrations. As an example if you’re moving to SharePoint Online, you’ll probably have a policy that says, “We are not going to move migrating workflows, SharePoint workflows.” That’s because you can’t do that with SharePoint Online. That would be a good policy to have, but people need to understand that. What does that mean? How do they prepare for that. You’ll probably want a runbook or a checklist for them to go through before the migration so they’re prepared for that.

 

There can be other policies of things you support and things you don’t support as part of the migration, but it’s important to understand what that is, and that takes time to understand that. I talked before about time. To come up with this policy document and then communicate it out takes some time, and I think it’s an important piece of the migration.

 

Another one is a runbook that I just mentioned. So this would be maybe a checklist that site owners have to go through before their site is migrated, or it could even be users but typically would be site owners that they do before and after a migration of a site. This may time, for example if you are going to SharePoint Online and you’ve got farm solutions, well those farm solutions aren’t going to go over. How are you going to deal with that? Are you, as the IT organization that’s running the migration, going to go ahead and, as a service, re-architect those farm solutions for them? If there’s a lot of them, probably not. You’re gonna make the business own that. Each business unit that has farm solutions, now they’ve got to come up with a way to get that over on their own. You’ve got to work through that process, and the runbook might have that as one of the checklist items.

 

Danny:Okay.

 

Kirk:A couple of the documents that we have, that we’ve discussed as a self-help document, which is for users. Maybe you’ve noticed through your testing phases and pilot phases that there’s certain places where users can get confused. You’re moving from one environment to another, from one version of SharePoint to another, things look differently in SharePoint. Site actions menu is on a different side from 2010 and 2013. In SharePoint Online you’ve got the new modern views and modern UI that looks different. So maybe you’re self help might help users find that stuff and make it a little bit less jarring as they go from one environment to another.

 

Then finally another document that we’ve talked about is a knowledge base and this would be more for your level one or level two support to work through if there are migration issues. An example of this might be, when you’re migrating master pages and they don’t migrate well for one reason or another. There might be some ways that some technical individuals can help out and they might want to have some guides through the document.

 

That’s only part of the communication. There’s more to it than that. In the white paper, we show a timeline as how some of this might work, but when you’re doing the migration of people’s content, you might want to e-mail out the site owners, or people who use the site and say, “Hey, you’re going to be migrated in two weeks, and here’s the schedule.”, or you might want to send out some communications earlier than that and let the site owners sign up as to when they’re going to be migrated or give them some leeway from a timing standpoint. A lot of times there’s some aspects of your business that have critical periods within the year. Maybe it’s around a holiday, or something like that. You just have to give them some leeway so that you’re not migrating them at the most important time of their year. Maybe it’s tax season, or something like that. You can communicate via e-mail, you can communicate via banners on the site-

 

Danny:Okay-

 

Kirk:just lots of different ways, and you can automate some of that obviously if you want to.

 

All right well we’ve talked about pilot already-

 

Danny:You don’t usually say “Always”. Typically you’ll say “It depends”.

 

Kirk:Well it depends if you’re doing a larger complex migration.

 

Danny:If you’re doing a large … well I think we went into this … and it is large and complex migration so-

 

Kirk:-but the answer is you do one, and in fact, you might want to do two.

 

The pilot is critical. I think what’s important about a pilot, and important for me to communicate right now, is a pilot is not necessarily just testing, “Does the tool that we’re using work the way we want it to for these 20 site collections, let’s say.” That’s good, you want to test that out and you want to pick a decent number of pilot site collections that you can use to move over and migrate and see how it goes, but you don’t want to just test the mechanics of the tool. You want to test the mechanics of your process. Do you have a support process that’s ready to handle this? Do you have a ticketing process that’s ready to handle this? Can you handle issue remediation? What do you do when an issue comes up? How is it handled? How are the communications working during … how’s it going to work during production? Well if you can test it during pilot you’re going to run through some of those things and you’re going to find out what’s working well, not working well and work through the kinks in the process.

 

Once you start your full on migration a lot of times people want to go fast, fast, fast, fast and if that’s the case you’re going to have a hard time catching up if you’re always trying to deal with these issues that were not tested during pilot.

 

Danny:What groups typically do the pilot. Is there any guidance there with who does the pilot?

 

Kirk:A lot of times you’ll see IT wanting to pick themselves as a guinea pig, which is fine, but you really need to work through representative parts of your company. It needs to be more than just IT. You just have to branch out to different departments, and, of course, you want to choose people, maybe a site owner, that can work with you through some of these issues.

 

For example, during the pilot process you may find out that, “Oh, that didn’t go well at all, we’re going to just trash what we just did and we’re going to do it again.” Ideally you want to work with individuals that will allow for that. Now when you’re done you really want it to be in production. I think that’s the ideal scenario, but you have to allow for a redo or a mull again of some sort in some of these cases, or it’s going to limp a long and you’re going to be like, “Okay, well we’ve got these five libraries moved over but we really had a problem with this one because of the way custom content types were set up.”,or something like that. We need some time to work through that. Please work on the old site for this library and the new site for this one, or something like that. You may decide that’s how you want to go and having pilot users and pilot site owners that can work with you, it’s important.

 

Danny:Number six. Have a plan for triage … There’s going to be issues? I guess we’re talking about large and complex.

 

Kirk:Yeah. If you’re doing certain things like a database attach, a lot of times that can go pretty simply, but if you’re doing a lot of one off movements or moving things with CSOM over to SharePoint Online then these tools are not perfect and there are certain things that it can’t do just right. They can report errors and you can you try and look at those errors and work those, and, of course, users can report errors as well. From a triage standpoint you want to be able to take in a different piece of information, and you want to have a plan for how you’re going to address them. What we’ve done in the past, is we’ve looked at something we call issue definitions, which is just a way of defining a type of issue that we think can occur. Maybe we found that out during pilots, or even some of our testing. It’s something that we know the tool doesn’t handle perfectly-

 

Danny:Yep-

 

Kirk:or because of our process something just can’t happen perfectly.-

 

Danny:Yep-

 

Kirk:Maybe some of those we’re able to automate and code around but some of them we can’t. If you can define some of those issue up front, then what we’ve done is we’ll actually automate the process of taking errors from the migration tool, plug them into these issue definitions and then we jumpstart the triage process so we know, “Okay, this needs to go straight to level two support, or level three support or we’re going to start managing the triage process and the remediation of the issues.”

 

There’s a feedback loop where these issue definitions, you can determine them a little bit, mostly in pilots and even throughout production. Then that feedback loop is, well maybe goes back to update our knowledge base or our self help or our policies. Maybe our policy manual we talked about earlier, needs to say “You know what we cannot handle this.” And we communicate that out.

 

Just realize that there’s a big feedback loop there.

 

Danny:I’m just pulling up as you’re talking here, just, sorry I’m just pulling up the e-book and noticed it had some nice diagrams just sort of talking through this a little bit as well.

 

Kirk:That kind of shows a little bit of a feedback loop where those issues go into an issue definition, then depending on what happens, you’re going to have some feedback to the site owners. Maybe you’ll do an update to self help or knowledge base.

 

Danny:Nice.

 

So support process.

 

Kirk:Yea, so this is part of the triage right-

 

Danny:Okay

 

Kirk:You’re going to have, I think I already mentioned some of this, you’re going to have inputs from multiple sources. You’re going to have users are calling in with issues, site owners are going to be calling in with issues. Then the actually people running the migration or the tool itself that’s doing the migration, it’s going to find issues. All of that needs to come into your process and you need to have a clear defined path of how you’re going to handle those issues.

 

This gets back to when I talked about the pilot needing to test, not only the tool itself, but needing to test the overall process. If you can include your support process as part of the pilot you’re going to be well prepared to do the migration because … Just imagine on day one of a migration if you’re doing 100 site collections or 1,000 site collections, or whatever it is. Probably closer to 100. These issues are flooding in. You need to have a vetted process where you can deal with that, because there’s going to be new things coming up that you weren’t prepared for. You want to be prepared as you can.

 

Danny:I think as well with this one I thought you had some-

 

Kirk:There’s a sample diagram in there that shows-

 

Danny:A sample diagram-

 

Kirk:It actually says it’s a simplified diagram because even though there’s 20 or so blocks it can be a lot bigger in terms of what the process might look like on how you escalate to different levels of support, where the issue originated and what documentation gets updated in the end, if any.

 

Danny:Okay.

 

Nice.

 

At least that’s a starting point or-

 

Kirk:Yeah-

 

Danny:an example of one for you.

 

Kirk:Yeah that came out of one of our migrations that we simplified it to generic sizes basically. It will be more complex than that but that might be similar to what you want.

 

Danny:Number 8.

 

Kirk:Yeah.

 

Danny:Archive strategy.

 

Kirk:Right, so a lot of time’s you’ll hear … It’s easy to just go out there and say, “You know what, our goal is to move from SharePoint 2010 to SharePoint 2013, and let’s just move it.” That’s fine, especially if it’s on for him, maybe that’s more fine, but if you’re going to SharePoint Online it’s a little bit harder. Why move things that just you don’t need? There’s always things that can go away and I know that as part of governance a lot of corporations will try to do things where certain sites have policies where data gets deleted over time. I don’t know if I’ve ever seen that used well in the field, but it’s great if you can do that. There’s still bound to be site collections that you just don’t need anymore, or at least you don’t think you need. We talked about CASAHL tool, it’s going to tell you when the last time, and I think the Microsoft one might do this as well, when the last time a site collection was touched.

 

Danny:Okay.

 

Kirk:You know if it hasn’t been touched in two years, or three years, well there’s a good chance you don’t need it anymore. By touched, maybe that means something was modified. Well, maybe people are reading the site and maybe they do need it. You want to understand what you want to keep and what you don’t and in the e-book I mention, “What is your criteria for archive or not.” Maybe it’s there’s no changes in the last two years or last six months or whatever it is, or maybe it’s based on size. If it’s really small maybe somebody created a team site and never really did anything with it, or created a blog site and they created one or two blogs. Is it really that important to keep that?

 

Understand what that criteria is and then come up with a process for archiving, and you also want to test your process for restoring. Maybe your archive process involves site collection back ups. You’ve got to come up with a way that tools have ways of archiving as well. Then you’ll want to test your restore process so that you feel comfortable and that your team that’s going to manage this going forward … They’ve got to be the ones that know how to do the restore. Someone says, “Oh, gosh we really did need ‘x’ document and that was over in this site, and we don’t have that anymore.” Someone can do the restore for them and get the document up.

 

Danny:I think up to this point we’ve talked a lot about SharePoint to SharePoint migrations. Funny when you were talking earlier about the inventory of what’s out there, one of the types of migrations we’ve been doing a lot of is the Jive to SharePoint migrations. That made me think that the trial version of the migrator tool doesn’t move inventory for you. It tells you what’s out there, so that sort of fits into the process that we use.

 

Kirk:Oh yeah.

 

Danny:Then you have the shallow pool and the deep pool which sort of tell you a little bit more, give you some more information about what’s in the environment. All these things pretty much applies to … Doesn’t really matter, it’s not exclusive to moving from SharePoint to SharePoint Online.

 

Kirk:I don’t think it has to be.[crosstalk 00:33:14] It’s a process and-

 

Danny:Yeah-

 

Kirk:it doesn’t have to be that specific to your technology.

 

Danny:Okay.

 

Kirk:One other thing when it comes to archive, or one other thing to think about is, a lot of clients will say, “You know we want to move to SharePoint Online, so let’s migrate our 2013 SharePoint environment there, but you know what, we’ve got some critical farm solutions that are in these certain sites, and we just don’t want to undergo the effort to re-architect those solution to get them to work in SharePoint Online.” Maybe that’s a good decision for you. That decision may be that you keep them in your current SharePoint, maybe 2013 environment, and then the other sites go to SharePoint Online. I call that a hybrid option-

 

Danny:Yeah-

 

Kirk:Where you keep some of your existing farm working and you move most of it to the new environment. Then you let that hit end of life-

 

Danny:Yeah, hit the end of life-

 

Kirk:and then you can get rid of it that time.

 

Danny:Yeah, just wait for the next time in which you really need to do a refresh with that line of business and then the time in which you decommission it and move it over to SharePoint-

 

Kirk:That’s right.

 

Danny:That sounds sensible.

 

So, last one. We’re here.

 

Kirk:We made it. Even though..

 

Danny:I wanted you to change this to, “consider ThreeWell resources”, but you wanted to have, “consider off-shore resources”. Why is that such an important thing for you to point out at this point.

 

Kirk:Yeah. Well if it’s a big migration you’ve got a lot of moving parts and a lot of data going across, so some things are going to be happening over and over and over again. While you can automate a lot of it, there’s going to be a human factor for a lot of it as well. We have used off-shore in the past, and you can use off-shore to help out with various aspects. One might be, as you’re starting your project and you’re determining that hey we can automate some of this, they could help you maybe with some of that tooling. Another would be, certainly, the level two supports. Maybe you’ve got a help desk staff but when it comes to SharePoint expertise you only have a handful of people and they are not going to be able to take all of those level two calls that are coming in. An off-shore staff might be able to do that. You can get some SharePoint resources obviously, that know some of these finer things within SharePoint such as, I mentioned, MasterPage tweaks that might have to occur-

 

Danny:Okay-

 

Kirk:for example.

 

That’s where they come in a fill those gaps.

 

Danny:Awesome

 

Kirk:They can also help with the triage process so as issues are maybe being reported not only by users, but but by the tool itself, they can triage those issues and say, “You know what, oh, this isn’t an issue.”, or “Oh yeah this is something big, let’s dive in further and see if we can fix this.”

 

Danny:Excellent.

 

You did it.

 

Kirk:Well, I’ll mention one other thing around the off-shore is … I’m not saying you should use them, I’m saying you should consider using them-

 

Danny:Yeah. Okay-

 

Kirk:We’ve had success with them in the past for sure. You want to consider the timezone differences, and that can be a pro and a con. For example, obviously timezone differences can be rough, say they’re in India and that’s 10ish hours different from Eastern time in the U.S. but it’s kind of hard to talk to them much during the day. That can be a problem, but the other side of that coin is that if you’re running these migrations, they can be doing things off hours while you’re not doing them. So you can be more of a 24 hour team when you have your team spread across the globe, to an extent. Then of course, maybe you’re a global company and you’ve already got resources all over the place, but if you don’t then this might be a nice way to kind of help your IT organization manage the process.

 

Danny:Awesome. Awesome.

 

So we are about at 10 minutes left here. If folks have any questions that they want to ask in the GoToWebinar interface, feel free to do that, and we’ll look through those. I’ll give you guys a second to do that. If there are any questions again if you go into that handout section of that GoToWebinar, you can download the PDF for this, so feel free to download that and share it with your colleagues.

 

We’ll also, I think I mentioned this the first time and not the second, that we will be sending out a recorded version of this so you can share that as well. ThreeWill have a podcast and actually this will go up as well as a podcast. We’ll have to just clip out the first part of it, or have a very long intro music.

 

Kirk:Yeah. Yeah.

 

Danny:Intro music for 10 minutes, some nice elevator music for 10 minutes-

 

Kirk:Yeah-

 

Danny:and then we’ll jump into it.

 

I don’t think I see anybody.

 

Kirk:Maybe we muted the questions.

 

Danny:I don’t think I muted questions. I hope not, I hope I haven’t muted questions.

 

Well, let’s do this. I guess if you had to have a conclusion to all of this, putting this together, what would be … Didn’t have time to listen to whole podcast, whole webinar, what would you say is a key thing to take away from this as far as preparing for a large and complex SharePoint migration.

 

Kirk:Be prepared is what I was about to say.

 

If you can, take a look as this paper and read through some of the sections and see what rings true for you, and plan ahead. We’ve said it several times. It’s probably the top three, might be … Plan ahead, do a pilot and communicate. There’s others in there, they’re all important, but those are ones that I think are really important, and not necessarily in that order, but you want to give yourself the time to make it happen. You want to vet the process out and the tool out and the whole thing. You need to communicate with, not only site owners but also end users and upper management, and make sure that everyone’s on board with what’s going on. There’s several ways to do that communications, several times you need to be doing that communication.

 

Danny:Purely selfish question here, but people pull us into these types of engagements why? Is it just because we’ve done them before and can keep them out of the things that get them into trouble with the migration?

 

Kirk:It’s not part of people’s business to be doing migrations, so they don’t really need to have that expertise for something they’re not doing that often. It’s smart, if it’s big enough, to try and get help. So you’re not going to run into all the issues we’ve run into before if you have our help. There will be issues, I can guarantee that. If it’s large and complex enough there’s going to be issues that we’re going to have to work through, because every migration is different, but there’s a lot of similarities to them.

 

Danny:So once everybody is on SharePoint Online, what happens to our migration questions?

 

Kirk:When you’re not ready for it.

 

Danny:Then we move over to our portals practice and then to add them you can switch over to that-

 

Kirk:That’s right-

 

Danny:That will be a … I’m not sure that date’s going to come anytime soon as far as everyone moving over to SharePoint Online.

 

Kirk:Yeah, and that is one interesting thing. This doesn’t have to apply just to SharePoint Online, but I think a lot of this is when you’re moving to SharePoint Online it becomes more complex, because the tooling has to do more work. Once you move to SharePoint Online, the promise is, you shouldn’t have to migrate again. There’s not another version of SharePoint to migrate to, Microsoft is handling all of that for you underneath the covers. At the same time, there will be features that come and go and be deprecated over time I would guess. I haven’t seen that happen yet on SharePoint Online. I can’t think of one, but there will be the next InfoPath, PowerApps, or something, maybe that will go away. I’m not saying it’s going to, but hopefully it automatically migrates into it’s next thing for you, but there will be some aspect that I’m sure is going, but it should be a lot less from a migration standpoint once you’re in SharePoint Online.

 

Danny:Awesome.

 

Well, thank you for taking the time to put this e-book together.

 

Kirk:Sure.

 

Danny:And getting your thoughts down on paper. I know it’s tough. I mean, you’ve been really busy lately, and doing a great job on projects. Just appreciate all the hard work that you’ve been doing with migrations. It’s awesome. It’s amazing to see how quickly all the stuff is coming together.

 

Kirk:Thanks. Well there are several people that helped out. I know on the title page or something, it mentions reviewers or contributors or something like that. Several people helped out and I appreciate their help.

 

Danny:Absolutely.

 

I don’t see any questions. If not, I went ahead and put up … You’ve got my e-mail address up there, my phone number, feel free to drop me a line if you want to pick up on this subject and maybe go into something a little bit deeper that we didn’t cover with this. I can grab Kirk and we can set up a phone call. If there’s any other questions that you have.

 

Again, thank you. My apologies for about the first 10 minutes. I apologize about that, but thank you for hanging on and for listening. In a couple of days here you’ll see an e-mail from us that has a link to how to share this with others, so keep an eye out for that. Thanks again Kirk for your help with this.

 

Kirk:You’re welcome.

 

Danny:Thank you everybody for listening.

 

Have a great day and have a great weekend. Take care. Buh-bye.

 

read more
Kirk LiemohnLarge and Complex SharePoint Migrations Webinar
complex-maze.gif

Complex SharePoint Online/2016 Migrations

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

Learn the ten things you need to know about Complex SharePoint Online/2016 Migrations from Kirk Liemohn, Principal Software Engineer at ThreeWill.

Secure Your Spot read more
Danny RyanComplex SharePoint Online/2016 Migrations
threewill-webinars-2017.jpg

Free ThreeWill Webinars for 2017

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

We’re excited to announce our Webinar Schedule for 2017 (all times in EST)…

  1. Moving from SharePoint Online Dedicated to Multi-Tenant – 1/26/17 @ 1:00pm – Listen Now
  2. Migrating from Jive to Office 365 – 2/23/17 @ 1:00pm – Listen Now
  3. Complex SharePoint Online/2016 Migrations – 3/30/17 @ 1:00pm – Listen Now
  4. Creating Award-Winning SharePoint Intranets – 4/27/17 @ 1:00pm – Watch Now
  5. Find Anything in SharePoint with Amazon-Like Faceted Search – 6/29/17 @ 1:00pm – Watch Now
  6. Budgeting for 2018 SharePoint Initiatives – 10/26/17 @ 1:00pm – Register
  7. Successful SharePoint Farm Assessments – 11/30/17 @ 1:00pm – Register

The schedule is subject to change (especially if presenters get overloaded on projects). Let us know in the comments if you have other topics that you would like us to cover.

Sign up below to get notified about upcoming events or follow us on twitter.


SharePoint is a web application platform in the Microsoft Office server suite. Launched in 2001, SharePoint combines various functions which are traditionally separate applications: intranet, extranet, content management, document management, personal cloud, enterprise social networking, enterprise search, business intelligence, workflow management, web content management, and an enterprise application store. SharePoint servers have traditionally been deployed for internal use in mid-size businesses and large departments alongside Microsoft Exchange, Skype for Business, and Office Web Apps; but Microsoft’s ‘Office 365’ software as a service offering (which includes a version of SharePoint) has led to increased usage of SharePoint in smaller organizations.

While Office 365 provides SharePoint as a service, installing SharePoint on premises typically requires multiple virtual machines, at least two separate physical servers, and is a somewhat significant installation and configuration effort. The software is based on an n-tier service oriented architecture. Enterprise application software (for example, email servers, ERP, BI and CRM products) often either requires or integrates with elements of SharePoint. As an application platform, SharePoint provides central management, governance, and security controls. The SharePoint platform manages Internet Information Services (IIS) via form-based management tooling.

Since the release of SharePoint 2013, Microsoft’s primary channel for distribution of SharePoint has been Office 365, where the product is continuously being upgraded. New versions are released every few years, and represent a supported snapshot of the cloud software. Microsoft currently has three tiers of pricing for SharePoint 2013, including a free version (whose future is currently uncertain). SharePoint 2013 is also resold through a cloud model by many third-party vendors. The next on-premises release is SharePoint 2016, expected to have increased hybrid cloud integration.

Office 365 is the brand name used by Microsoft for a group of software plus services subscriptions that provides productivity software and related services to its subscribers. For consumers, the service allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft’s cloud storage service OneDrive, and grants 60 Skype minutes per month. For business and enterprise users, Office 365 offers plans including e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software.

After a beta test that began in October 2010, Office 365 was launched on June 28, 2011, as a successor to Microsoft Business Productivity Online Suite (MSBPOS), originally aimed at corporate users. With the release of Microsoft Office 2013, Office 365 was expanded to include new plans aimed at different types of businesses, along with new plans aimed at general consumers wanting to use the Office desktop software on a subscription basis—with an emphasis on the rolling release model.

read more
Danny RyanFree ThreeWill Webinars for 2017
helpful-tips-black.jpg

CSOM GetItemById Results in “The property or field has not been initialized”

Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.

I was having a problem where I was trying to migrate list content from SharePoint 2010 to SharePoint 2013 but a couple of fields were not making it over.  I was using a migration tool that I like to use, but had to resort to connecting to both SharePoint 2010 and SharePoint 2013 using CSOM due to environment restrictions.  I know there are limitations with CSOM and likely more with SharePoint 2010 than there are with SharePoint 2013, but I was still surprised the tool couldn’t get values for these two fields.

I thought I could get around this if I wrote the code myself so I gave it a shot.  I wrote some PowerShell to first query for the list item IDs from the source list.  The code uses a CAML query and only has the ID field in the ViewFields for the query.  I then iterate across the results of the query.  For each result I get the entire source item by ID as follows:

$sourceItem = $sourceList.GetItemById($sourceItemFromCAMLQuery.ID)
$sourceCtx.Load($sourceItem)
$sourceCtx.ExecuteQuery()

GetItemById is the key method above as I thought it would do a good job of getting all fields for that list item.  However, for the two fields that gave me problems with the migration tool, it failed with my code.  The line of code that gave me an error was:

 $sourceValue = $sourceItem[$fieldName]

The exception thrown was of type PropertyOrFieldNotInitializedException.  The exception message was:

The property or field has not been initialized. It has not been requested or the request has not been executed. It may need to be explicitly requested.

I immediately thought this might be a row ordinal issue based on problems it has caused me in the past.  In retrospect I discovered that according to the schema XML for the fields, they are still in row ordinal 0 (which is good) so that didn’t explain my issue, but my fix was the same regardless.

To fix this problem I simply added these two problem fields to the ViewFields for my initial CAML query and subsequently get the values from the CAML query instead of the list item obtained using GetItemById.  It added a little complexity since I had to pay attention to which field values I obtained from the CAML query and which I obtained from GetItemById, but it solved my problem!  I hope it helps others as well.

read more
Kirk LiemohnCSOM GetItemById Results in “The property or field has not been initialized”
deep-dive.jpg

Deep Dive into Migrator (Jive to SharePoint Migration Tool)

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

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)
shutterstock_226224313.jpg

Prepare to Migrate from Jive to SharePoint with this New Tool

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

Danny Ryan:Hello, this is Danny Ryan and welcome to the ThreeWill Podcast. Today, I have Chris Edwards here with me. Hey, Chris. How’s it going?

 

Chris Edwards:Hey, doing great.

 

Danny Ryan:Good, looking forward to getting an update from you. You’ve been busy, my man.

 

Chris Edwards:I always try to stay busy all the time. Try to.

 

Danny Ryan:Keeps you out of trouble.

 

Chris Edwards:Yeah, hope so.

 

Danny Ryan:Hope so. How are the puppies?

 

Chris Edwards:They are all adopted except for one. We’ve decided to adopt one.

 

Danny Ryan:To keep one, very nice.

 

Chris Edwards:There was struggle is trying to get a name. Figured it out when we finally got one.

 

Danny Ryan:What’s the name of the-

 

Chris Edwards:Sheldon.

 

Danny Ryan:Sheldon, sounds kind of formally dressed or something. Let’s get to it. I wanted to get an update on … I know you’ve created a trial version of the Migrator Tool.

 

Chris Edwards:Right.

 

Danny Ryan:I just wanted to get an overview of what that is and just catch up on things. I know you’ve been working on a video as well of what Migrator does and demo for me and just catching up with you as far as what things you’ve been up to lately.

 

Chris Edwards:Migrator, it is … Basically it’s a initial visual interface that allows someone to just download it. They want to see how large their Jive environment is. We typically work in terms of number of places. When I say number of places, in Jive there are different kinds of places. There’s the concept of the space, concept of a group, concept of a blog and a concept of a project. We just call all those places just to have a generic name term for it.

 

Danny Ryan:Okay.

 

Chris Edwards:One of the first things we do in a migration is we do an inventory check. We basically pool all of the different number of places and then a basic hit on the content. To have that initial conversation is hard to know how the day of a customer is. The Migrator utility in its current state doesn’t actually migrate content. It’s not what its intention is at the moment. We’ll talk about that in a minute.

 

Danny Ryan:The trial version of it, it just goes out and does these counts for you and just get-

 

Chris Edwards:Yes.

 

Danny Ryan:Okay.

 

Chris Edwards:It’s designed to be the super simple. All its trying to do is gather your Jive Instance URL, basically what you use to get the Jive. A user name and password that … In this case, the user name should have the access to all the different places that we need to find. Typically, it didn’t have to have right access-

 

Danny Ryan:Just real access.

 

Chris Edwards:Just real access that needs to be able to use the API behind the scenes and actually get hold of the places themselves. Then what it does, it goes off and does, this is magic behind the scenes, it pools all the details and just report a summary. It just allows that conversation to be very clear in terms of when we are looking for the number of places looking for a size of what you guys … What a particular Jive particularly has. We have a clear talking point and clear denominator to work off of.

 

Danny Ryan:Partially it’s kind of funny because when we’re talking about doing pricing based off of places …So many times I say species not places. I’m saying the right word places. I had some folks who prospects who were saying, “Okay, that’s great. How do I find out what that is?” I would be like, “Ah.” There’s not a real place you can go to. I’m assuming in the Jive admin where you can go see or just show you the same information, correct?

 

Chris Edwards:There’s not a clear way of saying, “Okay Jive, how many places are there and what does that break down? I’ve not been able to find a clear indicator of that. That’s what the simple utilities in its current state is designed to do.

 

Danny Ryan:There’s also a very real. This is almost like what you often do with projects for flashing one through the pipes which is seeing if somebody can test it against their Jive or whatever they happen to be running Jive-wise. This is just hitting drive, it’s not hitting SharePoint or doing anything with regards to Office 365 or SharePoint.

 

Chris Edwards:Yes, that’s actually a great point. It’s only hitting your Jive Instance, so it is not … Before there’s backend information. It’s not recording information other than what’s in the log file, it’s log goes to the really application apps. In the video I pointed that out because I know what that is.

 

Danny Ryan:You’re storing the credentials anywhere-?

 

Chris Edwards:We’re not storing the credentials anywhere. The intention was to not do any of that. It’s really just an exercise to get the number of places to have that conversation.

 

Danny Ryan:Where does this go? I know one of the things I’d love to have is just 2, because a lot of people ask, “Can you just migrate one place for me?” I know maybe eventually if there’s some arm twisting going on and you have enough time we may be able to get to that or maybe not. Who know? We may need to work into it.

 

Chris Edwards:I’d love to look into it.

 

Danny Ryan:I know that’s something we want to do. There’s also maybe getting a little bit more information about sizes of things or what are the things are on the backlog right now or things that you want to add to the trial version?

 

Chris Edwards:The trial version, the next major … The logical thing to do would be to go a little deeper in terms of the contents. One of the things we do is … Part of the inventory process is we capture the number of places but we also do an initial high level pool of content that actually pool the binaries, not do the full mass of pool but the high level details of what’s in the content that allows us to get the number of content per place.

 

The beautiful thing about that is to do that in a simple way, adapt to the utility then we can actually start talking about how do we group all places in such a way that we’re able to batch them up. We can do them in a very consistent way. If we wanted to migrate 100 or 200 or maybe 1,000 at a time, that 1,000 we identify is similar to the next 1,000 and not guessing in terms of how long something is going to take. We get more predictable with how long an actual migration is going to take. The next phase would be more predictable, has a more predictability to the output and how long things will take to do.

 

Danny Ryan:Very nice.

 

Chris Edwards:It just helps us plan and it adds to the overall process of how migrations are done. That information will be super useful to have.

 

Danny Ryan:It’s a nice, I appreciate you creating a little video and I’ll put a link to the video in the notes in this podcast, but just walking through what the typical drive migration looks like and what the tool does. I know it’s a command line tool so its doing what it’s doing and it’s writing to a log file and you … I really appreciate you going through what the whole process is. That just makes it more real to me and for folks who want to see what does it look like to do an actual migration.

 

Chris Edwards:We’re trying to keep things simple. We’re trying to go after stuff that truly makes sense. We want to help people be successful in their migrations. We don’t want to overdo it or over-engineer it. At least we’re very specific about where we’re going after, ask the right questions and make sure we’re able to things correctly. Also estimate things correctly so we don’t over blow the budget or anything like that.

 

That’s the only designed to be … Someone to go from end to end, be predictable about it and be successful the whole process. Also, keeping the tool simple, allows us the customer is done very easily. Someone, “Oh, I don’t like the that works.” I said, “Wait.” The whole migration process, I want to change something about it. I’m going to make it very easy for us to adapt to that.

 

Danny Ryan:Very nice.

 

Chris Edwards:That’s the plan. That’s your idea.

 

Danny Ryan:You are in a middle of migration right now, right?

 

Chris Edwards:Yeah.

 

Danny Ryan:How is that going?

 

Chris Edwards:Going pretty well. Looking forward to getting this one under the belt as well, but it’s good it’s a pretty big one.

 

Danny Ryan:Big like certain amount of content or big like number of spaces or number of places?

 

Chris Edwards:Number of places.

 

Danny Ryan:How? Do you mind me asking?

 

Chris Edwards:We’re actually migrating 2500 but then archiving over 10,000 so it’s a fairly large effort.

 

Danny Ryan:Very nice. Well done.

 

Chris Edwards:Yeah.

 

Danny Ryan:Well done. That’s it for now. I appreciate these little updates and continue your hard work. There’s lots of people who are contacting us about migrated from Jive to SharePoint and Office 365 and it’s amazing what you guys have built over the last couple of years. It’s not just the tool, it’s also the whole process and the far that you guys have put behind this that I appreciate.

 

Chris Edwards:We’re also looking at improving how we can really leverage the SharePoint. The SharePoint functionality in what it does. I’m really trying to change the way we think about … This is not your bunch of wikis. Let’s just not migrating Jive content, let’s make this content come alive in SharePoint and really take advantage of that. We’re looking into that as well.

 

Danny Ryan:I think we’ve recently seen some of the new you. All I changed is the SharePoint and some of them smell a little Jive like. They’re trying to go a little bit more down that pass. Hopefully we’re getting more towards they’re moving a one to one and the experience is similar to … In SharePoint to what you have in Jive. It’s because there some transition and there’s some change right now and hopefully we’ll see Office 365 continue to improve the whole UX experience and then getting the content and hopefully everybody will be happier With that improved experience.

 

Chris Edwards:Absolutely. Looking forward to seeing that continue to improve.

 

Danny Ryan:Thank you for taking the time to do this, Chris.

 

Chris Edwards:All right, thanks.

 

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

 

read more
Chris EdwardsPrepare to Migrate from Jive to SharePoint with this New Tool
shutterstock_218803594-Recovered.png

ThreeWill’s New White Paper on Complex SharePoint Migrations

Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.

Danny Ryan:Hello, and welcome to the ThreeWill Podcast. This is your host Danny Ryan, and I have Kirk Liemohn here with me. Hello, Kirk.

 

Kirk Liemohn:Hello.

 

Danny Ryan:How are you doing?

 

Kirk Liemohn:I’m doing well.

 

Danny Ryan:Awesome. Thank you for joining me. We’ve got Kirk working on a white paper for us, and he’s been a member of a team on some complex SharePoint migrations, and as part of that, we wanted him to sort of put together what our sort of 10 points that we think people need to know about complex SharePoint migrations.

 

You’ve put together the first … I know you’ve got an outline of the whole thing, the whole kit and caboodle, but today what we’re going to do is we’re just going to focus in on two aspects. Not necessarily the most important, but they’re important. Let’s talk about two of the aspects that you wanted to highlight first.

 

The first one, I hear this all the time with migrations, which is communication.

 

Kirk Liemohn:That’s right, yeah.

 

Danny Ryan:Communication, communication, communication. You started off with that one, so it must be at least somewhat important.

 

Kirk Liemohn:It’s on the top of my mind. I think there are several aspects to it. There’s, “What are you going to communicate, and to whom?” Then, there’s “When are you going to communicate it?” From the “what” standpoint, for larger migrations, say if you’re migrating a large number of site collections, the IT organization isn’t going to be able to handle everything themselves. They’re going to rely, they’re going to delegate to site owners or others for some of those, potentially. If that’s the case, then you’re going to have to give some documentation and guidance to those site owners. That’s part of the communication.

 

Danny Ryan:Your first part of this is breaking off and delegating some of that to the individual site owner so that they are able to assist with the migration as well?

 

Kirk Liemohn:Right, and they’re aware of it, right? They’re the ones that are going to be affected, so if your migration is going to … You’re going to change your feature set during your migration, maybe you’re going from SharePoint On-Prim to SharePoint online, that’s a fairly common one. If you’re doing that, well, certain things aren’t there in SharePoint Online. You can’t have farm solutions, and there can be some difficulties in the migration where certain things don’t go over well. You can’t migrate running work flows to SharePoint Online.

 

You can communicate that through various means, but if you’re going to let site owners know this, you might want to create a policy document, and in that policy document it might say kind of what’s covered in the migration, but more importantly, what’s not covered in the migration. That might be, like I mentioned, running work flows might be a good example if you’re going to SharePoint Online.

 

That’s one way. Then, there’s other things like we have a runbook, which might be a checklist of what a site owner would do before and after the migration. They might prepare their site for that migration, so if you’re going to SharePoint Online or you’re going to a different SharePoint environment where your list view threshold is now going to be smaller than it was in your current environment, then you’re going to have to deal with that, and maybe the site owners have to put indexes on some of those lists. You could help those site owners out by telling them, “Hey, you’ve got some large lists out there,” but you may want them to put the indexes on them.

 

Danny Ryan:Is that runbook, is it like a document, or is it a task list?

 

Kirk Liemohn:Yeah. It is. It’s both. It’s a document that’s a checklist, basically. You can have a runbook for the team that’s doing the migration themselves, but you may want to have a runbook for the site owners that says, “Here’s what I need to do before and after my site or sites are migrated.”

 

Danny Ryan:This is part of getting ready for the migration, and delegating out some of that communication. Is there typically like a SharePoint site that’s created for communication purposes to everyone, so that’s sort of …?

 

Kirk Liemohn:That’s one way. If you’re doing a large migration where there’s a lot of site collections involved and a lot of things involved, then, yeah, you need … For example, if you’re doing thousands of site collections, and each of those has one or more site owners, you’ve got to have some database to kind of say who the site owners are, “Have we communicated with them yet? Has the migration started yet?” Those types of things. We have used SharePoint lists for that.

 

Danny Ryan:That sounds like a good …

 

Kirk Liemohn:You could use a database for that as well.

 

Danny Ryan:Or an Excel spreadsheet.

 

Kirk Liemohn:You could, yes. You could. Especially if it’s shared, and probably put in SharePoint or something. You don’t want to e-mail it around.

 

Danny Ryan:Oh, come on.

 

Kirk Liemohn:You need to have a way to communicate when you’ve got all that information that’s got to be … You’ve got to have some electronic single point of reference for that. We kind of keep track of that. There’s also things like, maybe your support staff is going to need a document to kind of how they’re going to manage certain types of issues that you expect to occur.

 

Danny Ryan:The site owners will hear about it, but then support will also hear about it once you move over to the new site as well, and issues with the new site.

 

Kirk Liemohn:Or there could be a self-help or other type of document that end users could use for common situations that you kind of want to head off so that support isn’t overwhelmed with issues.

 

Danny Ryan:Very nice.

 

Kirk Liemohn:That’s a lot of the “whats” that’s involved out there. Certainly, there’s more. You’ve got to get buy in from your executive, or the company, to make sure that they support your effort, and they understand kind of what you’re not supporting when you’re doing this effort, because if you’re moving to a different environment where certain things aren’t supported, then there’s going to be people that are not happy that they’re losing, say, “Hey, we’ve got this solution that’s a farm solution and we need it.” Well, either it’s not migrating, or it’s going to have to be re-architected. You need support from throughout the company that’s going to say, “Yes. This is the direction we’re going,” and then you also need to communicate early enough so that those site owners can take steps to correct what has to be corrected. In some cases, it may be re-architecting an application that’s written on a farm solution, for example.

 

Danny Ryan:A lot of this, you’re communicating out because you’re about to move somebody’s cheese, and people inherently don’t like change, right? There’s some people that will be unhappy regardless of how well it goes. I think a part of the reason why you’re communicating is to mitigate some of the things that could upset people, because you’re letting them know … I think a part of this is in the migration itself, because there’s sort of this uncertainty about when this is going to happen. What changes are going to happen when it does happen, and how do you communicate out to the world that, “Hey, we’re going to do this. Here’s when it’s going to happen.”

 

There’s also, I think, often here on migration projects, sort of, “When are we off the old site and onto the new site, and what happens if …” Changes on the old site. How we dealt with things like that.

 

Kirk Liemohn:From a communication standpoint, you definitely want to plan for that. There’s a couple of ways you can do it. For some sites, you can cut it over immediately, and the old site is gone, or it’s not accessible in general. You’ve moved it over, and they’re ready to go, and you can do that on an evening or a weekend, and you can basically try and ensure that they’re not using it at that time. For larger sites, it can take longer to go over. It may take days for the content to get over there. It kind of depends on the methods you’re using, whether you’re doing like database copies or what have you.

 

The client set object model is going to be slower to move, and if you’re using Azure Upload services, that can help, the Azure Upload API. Then, with those, you’ve got incrementals, and you’ve got to communicate that. They need to know what the cut over is, so you can have e-mails that kind of help communicate that. You can have banners that are put on the source and-or target sites that help communicate that. You want to time all that based on when is the most appropriate timing. For example, you may want to send an e-mail out to site owners two weeks before their site is going to be moved over. You’ve already sent them one well before that says, “Here’s the schedule.” Maybe interact with them on the schedule because some are going to need to change the schedule because their very important month of the year is right around Labor Day, or right around Christmas.

 

Danny Ryan:This is a finance site. You do not want to do this at the end of the month.

 

Kirk Liemohn:If this is a tax site, you don’t do it in April. Those types of things. Then, after you’ve kind of ironed out the schedule, you want to send a reminder probably maybe a week or two before you’re going to do it. Say, “Hey, it’s about to go.” Maybe send an e-mail right when it’s going, or maybe just update a banner on the site. Then, you can use e-mails and banners from there if you like. You can automate that or not depending on the number you’ve got. We have automated in the past for large number site collections.

 

Danny Ryan:For number two, because I know you’ve got to run off here, I think it’s closely related to communication, which has to do with expectation, which is pilots, and running pilots, and our philosophy definitely seems like it translates over from app dev over to migrations, which is “Get those early cycles in so you’re learning together,” so pilots are become very important. Tell me more about that.

 

Kirk Liemohn:I think one of my big takeaways, I would say, on pilots, is have your pilot process try and cover as much, if not all, of your migration process that you can. It obviously is going to cover the physical moving of bits from your source environment to the target environment. You’re going to try and test several sites, site collections, what have you, and hopefully a varied number and type. Maybe some departmental sites, maybe some that have applications. Maybe some in different regions of the world. Some of different sizes, large and small. Not only the constants, but you also want to cover your other aspects. The communication. Are you sending out those e-mails? Involving the support process in your pilot, to make sure that support is ready? Tickets. How are support tickets going to be generated, and are you all ready for that?

 

Other things like issue remediation. You might have a feedback loop of issues that are found, and you want that feedback loop to work. You’ve got a triage process that you need to make sure you vet, whether it’s manual or automated. All of that should be part of the pilot process. Then, of course you can have one, or two, or even more pilots if you want to. Each of those is a big feedback loop into how you’re doing the whole migration, so that once you get to what I would call production migration, then the spigots are on full, potentially, and you don’t want to have to be catching up on, “Oh, our process isn’t ready for this.” You want to vet out as much as you can in the pilot, before you go fast in production. You may decide to go slow in production, and that would help. A lot of times, they’re like, “No, we need to get this done by a certain date, and once we start, we’ve got to really move.” That’s why the pilot process is important.

 

Danny Ryan:How is it decided who goes into the pilot?

 

Kirk Liemohn:That’s a great question. I think that’s going to depend on any client of ours, any company out there. In an ideal scenario, as I said, you want a breadth of different sites, so that’s one thing. Before you start, before you get too deep, you need to catalog things. You need to catalog what you’re moving. You need to understand what you’re moving, to an extent. Then, maybe the IT organization that’s responsible for the migration would start picking what makes sense, but they also have to reach out to the site owners, those responsible for those sites that’s being moved or copied, and they have to work with them and say, “Can you be part of the pilot?” A lot of times, you’re going to get better hand holding when you’re part of the pilot, so that’s the pro for them. The con is, there’s going to be some tweaks in our process that we’re going to learn throughout this, and we want you to be reasonable and flexible with us as we go through this. You want to find those people that you can work with for the pilot.

 

Danny Ryan:You probably also want to get input from them as well, as far as what you can improve in the whole thing as well.

 

Kirk Liemohn:Of course. Yes.

 

Danny Ryan:What else about pilots? Anything else you’d like to point out?

 

Kirk Liemohn:I think that’s mainly it. You want to just cover the entire process. If you’re just covering the moving of the bits, or the covering of the bits, or the reorganization of the bits, that’s an important aspect, but you’ve got to cover communications, as we’ve already talked a lot about communications, you’ve got to cover your support processes, where your documentation is and everything. Is it working well? Then, how your remediating issues, and the triage process, and just how that feedback loop works.

 

Danny Ryan:For pilots, is it something that you do a certain number of sites for the pilot, but then when you do the production one you re-do those sites? Do they move over at that point in time? What’s typical for that?

 

Kirk Liemohn:It could be either. I like pilots that are somewhat large, so you aren’t just doing a small handful of sites. You can start out that way, and you’re going to do that. If you’re doing automation, you’re going to be doing some testing of some sites. Those might be throw-away. You’re not basically going to keep them in the target environment. You’re going to re-do them later. If you’re starting to do a large number, it’s kind of a shame to have to re-do them later. You’ll want to work with your site owners and give them the expectation that, “Yeah, we are going to move over,” if everything’s ready for it, and that way you don’t have to re-do them. Then, there’s, “Oh, you know what? In this case, this site didn’t go over well, and we found out a way to correct this in the future, but for you, it’s too difficult for us to kind of fix it in the target environment. We would rather copy it over again. Are you okay with that?” That would be one of the hiccups you’d have to get around. I think it depends, but if you have the luxury to re-do them, maybe that’s nice, but if you’re doing a lot of pilot sites, I think you’re going to want to keep them over there.

 

Danny Ryan:This was great. I appreciate you taking the time to do this. I know a lot of the stuff you pick on projects just to be able to communicate this out to folks, and sort of summarize it, is really helpful. I know for us, when we’re just talking about complex migrations, I know we’re involved in some migrations from other platforms to SharePoint. You’ve been involved in one that’s a SharePoint dedicated to multi-tenant, right? That’s a complex migration, and I think there’s a lot of other sort of areas where I think a lot of what you’re sharing here definitely pertained to those as well. I appreciate you taking the time to summarize all of this.

 

Kirk Liemohn:You’re welcome.

 

Danny Ryan:Those are the first two, and you’ve got more upcoming, and I look forward to chatting with you about those. Folks who are listening to this, if you’re about to embark on a complex SharePoint migration and want to chit chat with us about it, please reach out to us through ThreeWill.com, and we’ll follow up with you and look forward to talking to you about what you’re trying to do.

 

Thanks again, Kirk, for taking the time to do this.

 

Kirk Liemohn:You’re welcome.

 

Danny Ryan:Everybody, have a wonderful day. Take care. Bye bye.

 

Kirk Liemohn:Bye.

 

read more
Kirk LiemohnThreeWill’s New White Paper on Complex SharePoint Migrations
office-365-migrations.jpg

ThreeWill Supports Complex Office 365 Migrations w/ Metalogix

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

SharePoint Solutions Expert Delivers Customized Cloud Migration and Sustainment Services With Confidence Using the Metalogix Software Development Kit

(cross posted with http://www.metalogix.com/News-Detail/2016/07/11/threewill-supports-complex-migrations-to-microsoft-office-365-with-metalogix )

Atlanta, GA and Washington, DC – July 11, 2016

ThreeWill, an Atlanta-based SharePoint expert, and Metalogix, the premier provider of unified software to migrate, manage and secure content across enterprise collaboration platforms, today announced that ThreeWill is a founding member of the recently expanded Metalogix Advantage Partner Program (MAPP). Using Metalogix solutions at the core of its SharePoint practice, ThreeWill can deliver customized cloud migration and sustainment services by building customized solutions on top of Metalogix Content Matrix using the newly launched Metalogix Software Development Kit (SDK).

“Over and again customers ask us to evaluate products to support very complex SharePoint migration projects and every time we find Metalogix on top,” said Danny Ryan, Vice President Business Development, ThreeWill. “No other product can do what Content Matrix from Metalogix does. What’s equally important is that by using Content Matrix, we are able to support customers with sustainment services to maintain what we build. Metalogix has a tool to help us with this along with a flexible platform we can build on top of to provide customized solutions to meet even the most complex customer requirements.”    (Hear it in his own words – please visit: http://www.metalogix.com/Partners/Partner-Program-Overview.aspx to watch Danny Ryan’s video commentary.)

“ThreeWill takes an innovative approach to meeting customer requirements,” said  Joe Sullivan, Director Global SIs, Cloud Alliances, Metalogix “Their expertise and hands-on know how make them an ideal solution partner for large organizations with demanding SharePoint requirements. We are pleased to welcome ThreeWill as a founding partner of our expanded SharePoint migration ecosystem.”

The newly expanded MAPP enables partner-powered migration services with a comprehensive package of critical information, training and content to quickly create a repeatable and profitable migration practice. Members of the program also gain access to the Metalogix Content Matrix SDK to simplify complex customization and migration projects. The packaged program also includes access to Metalogix Content Matrix through the Metalogix Learning Management System, a sample statement of work, a sample project plan and pre-migration assessment and analysis tools and guidelines as well as sample code and scripts.

The newly enhanced MAPP is available now to qualified partners. For more information, visit http://www.metalogix.com/Partners/Partner-Program-Overview.aspx.

Tweet this: [email protected] supports complex migrations to @Microsoft #Office 365 with @Metalogix http://www.metalogix.com/About/News.aspx/2016

About Content Matrix

Metalogix Content Matrix simplifies the planning, migration and management process for SharePoint and Office 365 while enhancing their permissions, auditing, and reporting for assured security and compliance. Content Matrix offers expert pre-migration planning, assures zero downtime with unlimited movement and management and even migrates everything, in one hop, eliminating the need for intermediate SharePoint versions or on-premises staging. With Content Matrix and the Metalogix SDK, solution providers can benefit from the following features:

  • Simplified setup which easily connects to SharePoint farms, sites, or databases based on each project’s migration scope
  • No server-site installation for direct connection to SharePoint 2013 and 2016 on-premises farm or SharePoint Online site collection using Microsoft’s API
  • Multiple migration options to provide flexibility and granularity of control
  • Ability to migrate while keeping current SharePoint farm running to minimize user impact

About ThreeWill

Ranked in the top five percent of Microsoft partners based on four independent surveys, ThreeWill helps teams work together better by building solutions on SharePoint using agile processes. Established in 2001 and based in Alpharetta, Ga., the company is a Microsoft Partner with Gold Application Development and Gold Collaboration & Content competencies. For more information, please visit www.threewill.com.

About Metalogix

Metalogix is the premier provider of unified management software to migrate, manage and secure content across enterprise collaboration platforms in the cloud and on-premises. Over 20,000 clients trust Metalogix to optimize the availability, performance and security of their content across the collaboration lifecycle. For more information visit us at www.metalogix.com or call us at +1 202.609.9100.

Metalogix is a registered trademark of Metalogix, Inc. All other trademarks used are the property of the respective trademark owners.
###

Media Contact:

Sabrina Sanchez
The Ventana Group
[email protected]
(925) 785-3014

Nicole Gorman
The Ventana Group
[email protected]
(508) 397-0131

read more
Danny RyanThreeWill Supports Complex Office 365 Migrations w/ Metalogix
scrum-migration.jpg

Using SCRUM on Migration Projects

Tommy serves as the President at ThreeWill. In this role, he works with his leadership team to hire the best people, find the right business opportunities, and ensure that ThreeWill delivers for our clients on projects.

Danny:Hello, this is Danny Ryan. Welcome to The ThreeWill Podcast, I’m here with Tommy. Tommy thank you for joining.

 

Tommy:Glad to be here Danny.

 

Danny:Awesome, thanks for getting together here on a weekly basis, it’s nice to see your smiling face.

 

Tommy:Sure, it’s good to be here.

 

Danny:We’ve had a couple of podcasts leading up to this topic that we’re going to cover today, which is about the process that we use on doing migrations. I know we’ve been doing some complex migrations recently. It seems like really trying to get our customers to get over onto Office 365 has been one of the challenges that folks are seeing. We’re seeing a lot of projects related to this. For folks who might not know we us Scrum. Scrum is one of the Agile processes that is out there. There are some small modifications that we make just for the fact that we’re dealing with an external client, working with a client, but for the most part we’re using the fundamentals of what Scrum is about. What we wanted to talk about today is maybe any of the modifications that we might make, or maybe even just pose the question, does Scrum work with what we’re doing on these migration projects?

 

Tommy:First of all Danny thank you for the opportunity to geek out on process.

 

Danny:Oh jeez.

 

Tommy:I don’t get this opportunity too often and I don’t believe you let me do this. Yes we can geek on processes.

 

Danny:This is a sign of true love Tommy.

 

Tommy:Yes.

 

Danny:I love you my brother. I love you. I will sit here and listen to you about process for the next, don’t say 30 or 40 minutes. Maybe I’ll give you 15 minutes, how about that?

 

Tommy:Okay, 15. [crosstalk] 15.

 

Danny:Okay, ready? Crank them up, ready, 1, 2, 3 and go.

 

Tommy:Yeah, the process as it relates to migration. We’ve really enjoyed using Scrum as our methodology for doing custom implementations and the work that we do with SharePoint (Scrum on migration). As we’ve approached migrations we thought about using Scrum, and should Scrum be the methodology that we use? That’s what we use today and it’s working for us. I was taking some time recently to step and think about, is that the right choice? Are we just forcing it down the path of Scrum because that’s what we know and we’re comfortable with?

 

I posed that question out to our Yammer group and had some really good feedback on that. The question came up, should we use Scrum? What are the options to evaluate it against? I said, “There’s really any option.” Is there something better than Scrum to do these migration projects? When you see a migration you automatically think about, there are distinct phases when you approach a migration. You have a step, some kind of analysis type step, or people might call envisioning of what is this scope of this migration? What’s the bounds? What are we trying to accomplish as a part of this migration?

 

That goes to another phase which is a planning phase, is, okay this is our scope let’s do the proper amount of planning to know how this is going to fit into the grand scheme of things. Because you can’t just be willy nilly about going after a migration. There’s a organizational impact, it’s not just planning for the work you’re doing to make that migration occur but how does this fit into the grand scheme of things and how can we do this and minimize disruption to the organization.

 

Danny:Yeah it seems like communication is just … This is typically things that we might be working with our client, but ultimately our client’s responsible for the communication that goes out to the people who are using what you’re migrating off of and onto.

 

Tommy:That’s such a huge part of a successful migration, is the communication’s piece. Just like real estate it’s location, location, location, migration it’s communications, communications, communications.

 

Danny:Good [crosstalk]

 

Tommy:If you do not do that you’re destined to have a lot of pain in that process.

 

Danny:I know for a lot of the Jive to SharePoint migrations that we’ve been doing we do them with the workshop upfront and then we have the project afterwards. It sounds like what we’re doing is those … Maybe those first 2 steps during the workshop and then coming up with the plan afterwards.

 

Tommy:Yeah, when you look at those workshops at the end of the day it’s helping a organization decide, should I do this? What’s the rough budget for going after this? Especially with the Jive to SharePoint migrations it’s, okay I’ve got this in Jive, where does it go conceptually over into SharePoint. What we do in these workshops is we’re doing an inventory for them in an educational piece to let them know what is involved of this process of moving from Jive to SharePoint. We come out of that and we’ve done some of the analysis piece basically, some of the planning, really, really rough side of the planning side. It’s really enough planning to arrive at a budget so you can make an ROI decision and you can get a sense of, can I get this done in time?

 

Because a lot of times the approach with these migrations is, okay I’ve got a renewal, we’re ready to move and it’s going to be financially advantageous to move by this day. Our workshop allows them to understand what are they going to do and how much is it going to cost. Then we really need to go through all those steps, they might be compressed after our workshop but we’re still doing a certain amount of detailed analysis and planning before we get into some of the more implementation steps.

 

Danny:As you know I find it refreshing that there’s a deadline out there, because for a lot of typical collaboration types of projects that we’re doing where there isn’t a deadline to get something done by a certain period of time, it’s sometimes tough to make a decision whether to do it or not to do it. It’s just nice to have something. Fairly early on when working with clients who want to do migrations I start putting together and action plan around it, which is saying we do this during this time, we do the workshop here, we do this next, and sort of work our way backwards. It’s one of those things as a good project manager I] want to give a sense of urgency at the right time. If you don’t spell out, “Hey guys, really it’s like … I know we need to move over in October of this year, but if you back things out, we need to get a services agreement in place right now if we’re going to make it.”

 

Tommy:When we’re doing those we’re estimating certain things, one is the actual physical migration and the other is what types of enhancements do we need to make as a part of that generic process and tooling. What additional scripts or enhancements to the tool needs to take place? Do you have anything that needs to be custom built on the other end? Let’s say maybe you’re using for the case of Jive, you’ve got a landing page in Jive that has widgets and it’s arranged in a certain way. Maybe we need to build that on the SharePoint side so we can give the user a similar experience when they show up at the new location, when the previous location is shut down.

 

When you look at those steps, the analysis and planning, what comes right after that is what we call configure and develop. Configure and develop is, what do we need to configure in the tool and the environments to run a migration, and then what do we need to develop to enhance the kind of out of the box migration experience. That might be from the tooling or the destination side to create some things custom to get a better adoption after this is migrated.

 

Then we go into a pilot and we go into an actual production migration, and then a stabilization transition to get that platform finalized so you can shut down the previous environment. With those phases, the way I look at it when I put my Scrum hat on is I look at each of these phases-

 

Danny:You have a Scrum hat? Wait a minute.

 

Tommy:I do, I do.

 

Danny:You have a Scrum hat.

 

Tommy:It’s kind of messy.

 

Danny:Where is it? You keep that by your desk? You pull that out when somebody takes the wrong move?

 

Tommy:I wear a few hats around here.

 

Danny:You wear so many hats you don’t have hair on your head, neither do I but that’s not the reason, that’s a whole nother thing. Go ahead, sorry. You were saying about a Scrum hat?

 

Tommy:When you’re look at these phases … Let me get back to my process please. When you’re looking at a phase, I can draw the analogy of that phase is like a release in Scrum. When you have a release, within that release you have sprints and within that you have your daily cycles. What we look at is when we get into that phase of planning, or let’s say if the configure and develop phase, we have a budget set for that that is enough budget to get the goal accomplished, but we want to accomplish that goal in the most optimized way possible. You go into that phase and you say, “Here’s the 10 things that we know, the 10 stories that are inside of this phase,” and we want to give the highest value during that period of time.

 

When we come up with other ideas, let’s say, during that phase then we can adapt to going after the better ideas. That’s, I think, the beautiful thing about Scrum is you’re not committed to a story until you get into that sprint. You’re flexible enough to change your mind if you want to spend that money in a better way.

 

Danny:It all goes back to your manufacturing days, just in time, minimize rework. It just seems to be that’s what you’re ultimately trying to do, is not creating a bunch of rework.

 

Tommy:Right, but with migrations the, quote, standard is you really do have those phases that are logical steps to get you there. You’re not going to flex as much on that because it just doesn’t make sense. You skip one of those steps and then you end up putting yourself at risk for a successful migration. We’re finding that it really is a mixture of a waterfall, you have this phase and this phase and this phase, that you don’t do them all together every sprint.

 

You really need to be in a mindset of, “Let’s finish a certain amount of analysis. Let’s finish a certain amount of planning. We need to finish the configuration and development, and then let’s pilot this thing to prove out everything that we did leading up to that is working. Then let’s go into production, guns loaded,” doing this as fast as possible. Because as soon as you start that migration now you’ve got 2 places where that content is and the sooner we can get it all in that destination and be able to shut down the source, the better off that organization is going to be in terms of being confused and disrupted.

 

Danny:Yes. Chris and I talked about ludicrous mode.

 

Tommy:Yes.

 

Danny:We need to then go into ludicrous mode.

 

Tommy:It’s all about ludicrous mode, yes.

 

Danny:We’ve got the special sauce for turning on the ludicrous. I want to thank you today also for wearing cool socks again.

 

Tommy:Right?

 

Danny:You have outdone me.

 

Tommy:How do you like that?

 

Danny:I know people can’t see this.

 

Tommy:You’re going to have to have a vlog so we can show the socks.

 

Danny:I think I need to take a picture of that and I’ll put it up on the blog as I post it up. Man, that’s pretty nice. He’s got grey and blue and dark blue socks. Does that match your Scrum hat?

 

Tommy:It’s why I have multiple hats, whatever the color of socks I have I put on a hat.

 

Danny:I like it. You met with somebody today as well.

 

Tommy:I did. I actually met with 2 clients today, very good morning.

 

Danny:It’s great. That’s good. I’m glad to hear that. Anything else we want to talk about with this?

 

Tommy:You’re ready to be done with processes, aren’t you?

 

Danny:I know, I know. I know. You’re like, “I just got started Danny, I’m about halfway through the subject.” To wrap it up Tommy what do you …

 

Tommy:No, I think a lesson learned, and I’m working on the blog when I get to that point. I’m really just making sure that we’re doing the right thing by applying Scrum to our migration projects. It seems to fit. I think you have to put it in the right perspective and not make it Agile from the perspective of it’s just one big project. We can go in any direction. I think that works well for some app dev that we do, but when it comes to migrations we need to have some discipline of these phases and there are certain things that have to take place in those phases to be successful.

 

Danny:Good. That’s great that we’re taking the time to learn that. I, from an outsider again looking in on a couple of these projects, it seems it’s continuing to serve us, flexibility wise as well.

 

Tommy:Yeah, that’s what we want.

 

Danny:[crosstalk]

 

Tommy:We have the 3 Cs. I think having choice, we want that in every project that we do. We don’t want someone to feel like, “I’m stuck.” We want to give them the right guidance and put in the guardrails but give choice within those guardrails.

 

Danny:I like it. I like it. I’m whispering now, I don’t know why. I don’t know why I’m whispering. Great, thank you for taking the time to do this.

 

Tommy:Sure Danny.

 

Danny:It’s a pleasure, even when we’re talking about process. It was a pleasure. I stayed awake for the whole thing. I’m here, I’m right here with you. Thank you everybody, you stuck with us too, wow. All right, way to go. Thank you for taking the time to listen today. Definitely if you’re looking at migrating to Office 365, especially for folks who might be doing from a platform like Jive or some other content platform, feel free to reach out to us, it’s a topic we’re pretty passionate about talking about. Just come to us through the website, just go to the contact us page, that sends me an email and we’ll talk very soon about it. Thank you so much for taking the time to listen today. Have a wonderful day, bye bye.

 

Tommy:Bye bye.

 

read more
Tommy RyanUsing SCRUM on Migration Projects
whats-next.jpg

What’s Next with SharePoint Development?

Pete is a Director of Technology at ThreeWill. Pete’s primary role is driving the overall technology strategy and roadmap for ThreeWill. Pete also serves as ThreeWill’s Hiring Manager and is constantly looking for new talent to join the ThreeWill family.

Danny Ryan:Hello, this is Danny Ryan, and welcome to the ThreeWill Podcast. Today I have Pete Skelly with me.

 

Pete Skelly:Hey Danny!

 

Danny Ryan:How’s it going?

 

Pete Skelly:Pretty good.

 

Danny Ryan:They say the third times the charm, right?

 

Pete Skelly:It is ThreeWill.

 

Danny Ryan:It is ThreeWill. This is our third take. It’s a Friday afternoon, things are getting a little crazy around here. I’m going to mention our beer mugs for the third time. Maybe that is what choking this thing up. Whenever I mention the ThreeWill beer mugs, it just stops on us. It’s like “oh, it’s beer time, it’s time to move on”. Seriously, thank you for taking the time to do this.

 

Pete Skelly:No problem.

 

Danny Ryan:I know you are very busy, or you are supposed to be very busy … you we’re supposed to give it a go this week, but maybe that gave you a little time to come see me which is wonderful. Now I know you are always trying to stay ahead of the curve and trying to figure out what’s coming up next, and as things mature with Office 365 and with SharePoint 2016 coming out, I know you are taking a look at sort of what’s the types of apps we’re gonna be building 6 to 8 months from now. What are you finding out?

 

Pete Skelly:There is a lot of really interesting things that are going on these days. There is so much that is happening, new sort of Microsoft you’ve mentioned recently in both podcasts and blog posts about the new Microsoft … the things that Satya Nadella is doing that is working and cultural change … them being open source. A lot of what they are doing, things like getting ASP.NET core to run on Linux and Mac, containers coming … so a lot of my day job these days has been extremely busy with some client work.

 

Danny Ryan:Those darn clients …

 

Pete Skelly:Those darn clients …

 

Danny Ryan:holding you down!

 

Pete Skelly:get in the way always. But a lot of what I have been looking at … kind of free time, trying to stay on top of things has been where at least where do I think things are going and where do some of the folks, SharePoint user groups and some of the other folks that I interact with, where do they think we’re headed? And so a lot of the things that I’ve been trying to at least look into, if not do full blown apps with, are some of the technologies that I think will probably hit us in maybe 6 to 8 months. So things like ASP.NET core, the use of things like Gulp and Grunt, and some of the more quote web standard. Standard tools …

 

Danny Ryan:I’m not a grunt.

 

Pete Skelly:No, that’s not it. Build processes, things that are … have not been typical to .net developers or Microsoft developers, things that have had a lot of automation around them in the past, using MPM. So recently a few of the things I’ve been looking at are Office ad-ins using what the Office dote PMP teams are doing with Yeoman. So there is a Yeoman generator called Office which actually lets you step out Office ad-ins, so things like mail ad-ins, Word.

 

A lot of what they have been doing is really powerful: layering in things like how to put items and icons in the functionality of the ribbon, things like using Angular and Adel within the Yeoman generator to actually be secure in the things that you are creating, doing it on a Mac or Windows, and then recently trying to look at with the release of … I think it’s a release candidate for ASP.NET 1.0 … core 1.0, I don’t even know what they’re calling it these days, they’ve changed it so much. Just looking at that and trying to figure out how we are going to do things in the SharePoint world, the world that we live in, between SharePoint 2016 that is coming to On Prem, what’s coming out in Office 365 in the next few months with build and connect coming …

 

There is a lot of interesting things that are coming, so just trying to stay on top of those is probably a full time job in and of itself. It’s kind of fun to just try to mess with some of those things either late in the day or kind of at night free time.

 

Danny Ryan:You end up talking to Kirk or some of the teammates about what you’re learning, or you’re collaborating with folks outside of ThreeWill or how …?

 

Pete Skelly:It’s been a little bit of both. Everybody is so busy here that I have been kind of keeping it quiet, so trying to find the right opportunity … it’s early in the year still, so trying to get some lunch and learn things built … so that’s part of what I like to do internally, is work on some of the lunch and learn things that we do internally so I try to get content that actually will show some folks some new things. We don’t typically use TypeScript in projects today, although I think the trend is moving much more towards frameworks that are gonna be client side frameworks. And between Office 365 and SharePoint 2016, more and more treating that as just a set of services … interacting with SharePoint groups and Office 365 groups and what they’re doing … think of some of these things when you’re working with the next client that is either on 365, moving to 365, whether somebody is gonna come to us and say “I want to migrate to 2016 on Premises”.

 

Those are the types of things right now that … there’s so much out there, that just trying to put your arms around it and figure out is that something I could use on my next project, what is the value for that, what is the business value for that, why would I use it? Some of the things internally, we’ve got a couple of folks that are doing some things with Visual Studio 2015 and Visual Studio team services. And they’re using things like Gulp, they’re getting into using Git for source control more and more inside a Visual Studio team services. Where I can, some of those things, just kind of helping out where I can, because that’s the things that I’m trying to push for, but right now, it’s a little early.

 

I think customers right now, at least in my opinion, don’t see a whole lot of need for ad-ins just because they’re not there yet. Getting to Office 365 or even SharePoint 2013 on Premises is probably the biggest hurdle for folks right now. They’re still in the midst of doing those upgrades and trying to migrate versus trying to make wholesale changes and make giant custom applications. And there is such an ecosystem the office apps and SharePoint apps right now … the whole add-in story, I think some folks are waiting to see how that’s going to play out, like are they’re major vendors that are going to come out with things, Myntax is a great example, things like DocuSign.

 

I think within probably next 6 to 9 months we’ll probably see an uptake in some of those requests, and my gut says that’s where the bulk of consulting … as far as customization goes, if I’m gonna move to Office 365, there probably will be a pretty robust ecosystem of apps that are gonna be out there, but how do I combine these? And we talked about this October of 2014 in one of the Whitepapers we did, the more of these kind of micro-services you get, the more you can treat things like files API, all the things that the graph, the Microsoft graph is doing, to be able to expose email, calendar files, other services, the social graph that you use … the more you can treat those things as just consumable services and put your own customization on top, the more powerful those things become.

 

Things like web hooks within office 365, really interesting, how do you build solutions that add business value with those … how do you kick off processes based on for someone like you, like sales processes? If you have someone from a specific company send you and email and you can recognize that and start other processes, write from the receipt of that email versus you having to touch it, that would be awesome. Finding those opportunities, but even being aware of that technology is just very difficult right now, just staying on top of how much change is coming.

 

Danny Ryan:With the, I know we didn’t talk about this in the prep, but with Microsoft buying Xamarin, that adds another Microsoft technology to the stack, I guess.

 

Pete Skelly:Yeah.

 

Danny Ryan:How … what’s going to be our approach starting to look like … because I know we do … mobile is something that comes up pretty often for us, and I think we are getting really good at building responsive sites and those sorts of things. But how does this sort of fit into what we’re doing for our typical application? Are we going to start look at maybe having a component of what we do involves Xamarin?

 

Pete Skelly:I don’t know. I think … I haven’t really even used Xamarin enough to even have an opinion on it.

 

Danny Ryan:Okay, that’s fine.

 

Pete Skelly:I think the most interesting part is … of Microsoft buying Xamarin at this point, is to me … that feels out strategy of cloud versus mobile first. It lets them … it really lets them target developers on everything. If you look at the add-in model … I kind of look at the purchase of Xamarin as a parallel to what they are doing with add-ins. So the add-in model basically separating out those add-ins into just a web application that is being serviced through one of those hosts. Well, it’s still a web application, right? But now you can do things like get to the native medal and if Xamarin forms allows you to do that, it just makes sense. Like I said though, I don’t have enough knowledge of why you would want to choose Xamarin over something like Cordova or any of the other frameworks that might let you to do that … Ionic or some of the others. It, to me, makes sense. I just wonder … what I know the cost of Xamarin studios are as a developer license has been pretty cost prohibitive. So curious to see what would happen there, whether it gets rolled into Visual Studio as an MSDM … you know, as Microsoft’s partner, whether you get that as part of your MSDM subscription or capabilities.

 

Yeah, interesting purchase. I just don’t know … I don’t see it yet as part of what our customers are asking for. I think most business customers still say “well I want it to be mobile”, but if they’re really pressed, those are the things that get dropped first. Unless they’re truly … we have some customers that they’re communications companies and that’s what they do, so they’re gonna have mobile. But for the smaller, mid-sized businesses, I don’t think they’re there yet, but Xamarin may push them there … you know, the ability to do those things quickly and have custom apps that integrate with what you’ve got in Office 365 and kind of the other story, that may just be the piece that pushes it over the edge.

 

It’ll be interesting. I think we won’t see much as far as real traction from that for at least 6 months. And it’ll take that long to kind of ramp things up.

 

Danny Ryan:Anything else you’re sort of keeping an eye on right now, just to stay ahead of the curve, anything else?

 

Pete Skelly:There is so much out there. The most interesting pieces to me right now are container technologies, and I haven’t even really had a chance to really mess with them.

 

Danny Ryan:Darn projects, just slowing you down!

 

Pete Skelly:You gotta pay the bills, but at the same time, you gotta kind of keep your eye on the ball long term. Somehow finding some time to look at that is a big deal. I just think in … you look at Pas, so Platform as a Service, probably 2 years ago, that would have been I don’t want to say the Holy Grail, but it made more sense than doing something as infrastructures as a service managing your own VM’s, etc. And the whole docker container mentality now with windows server 2016, I forget what technical preview it is, but they’ll be supporting docker. So being able to have a container that’s really light weight from a development perspective will be great, but being able to build a solution that does not rely on having to maintain a VM that you can actually spin up different services and test different things and different back ends. I think that’s the most intriguing situation.

 

I look back in the last 10 years, I just saw a post from Joel Olsen that SharePoint is 16 years old this year. So the interesting part to me is, you said Sweet 16, I would really like to see some maturity around using SharePoint and building solutions on it the way we used too. Not in the server side sense, but really saying all of the things that SharePoint provides and that Office 365 provides are a huge base and looking at that through the lens of how do I build solutions on top of all the things I get there, the security, the file storage, the countering, the integration with tasks, all the things that are there that from a business perspective make sense to kind of use and consume centrally, but put them in your own custom apps, or put them on mobile phone, or put them in devices that are out in the field that somebody can actually accomplish the major task and then maybe refine it at their desk later on, or kick off a work flow to start somebody else working on it in quote the back office or the front office, whatever you want to call it.

 

So there is a lot coming that I think is pretty interesting. It sounds like I’m speaking at way too high a level, but there is so much going on. From a detailed level, its …

 

Danny Ryan:That’s okay, stay high level for me, Pete. You seriously want me to stay awake, right?

 

Pete Skelly:I could put you to sleep probably.

 

Danny Ryan:No, no. I appreciate you staying ahead of the curve. I know that’s an important thing for us and its difficult to do at your own projects. I know this year, its one of those … it’s the innovators dilemma, you’re trying to stay ahead of the curve and when we actually get to projects where we’re doing it … you’re moving on to the next thing, it’s difficult to do. But it seems like this year is still the theme, I know talking with Tommy and some other folks, but just get migrating people over to the cloud still … it’s still holding people back right now. So we’ll still be doing a lot of that , and I’m looking forward to the day where we’re building a lot of these little cool apps, and we’re getting there. I think we’re definitely getting there on certain projects. But yeah, it just takes time and sometimes the larger enterprises are laggards, and so it’ll come over time, and just be a little patient with it. I think its great that you’re staying ahead of the curve. We should get together more often, I know we’re doing this once a quarter, but just to get the stuff in your head out is a good thing right?

 

Pete Skelly:That’s scary.

 

Danny Ryan:No, it’s a good thing. What are you looking at now? What are you doing now, Pete? What are you looking at now?

 

Pete Skelly:Yeah, I wish I had more time, but right now, the world of add-ins I think is probably the most intriguing and then the things around there just from a development ecosystem or life-cycle perspective, the things like Gulp, the things like looking at Yeoman generators, those types of things that just speed up development. And then looking at how mature Visual Studio team services is … we build services, get integration, those types of things. There is a lot there, you could go real deep down that rabbit hole, and make a lot of really good things for our customers. There is so much there just out of the box with 2016 … 2013, 2016, and Office 365’s. There is still a lot of consume. They’re pushing out things left and right, so things like Planner. I still don’t think I understand what’s really the play behind groups. I’m kind of looking forward to what they announce at Build. What’s really the strategy behind groups? It opens up a whole new world with active directory behind the scenes, but what are they going to provide out of the box, and then what are kind of ISV’s going to provide as value, and then what are the gaps going to be? Where are businesses going to have to fill gaps? So lot of questions still, too.

 

Danny Ryan:So before we wrap up, you’re involved with the Atlanta User SharePoint … some of the stuff coming up with that, you’ve got …

 

Pete Skelly:Yeah.

 

Danny Ryan:What’s going on?

 

Pete Skelly:We just finished actually planning some of this year’s conferences. The date for SharePoint Saturday 2016 is set, so Atlanta, SharePoint Saturday Atlanta 2016 is going to be June 11. We are also going to do Cloud Saturday, so that will be the second annual Cloud Saturday. We just started looking for sponsors, so I’ll be hitting you up for sponsorship real soon.

 

Danny Ryan:Well you know what my marketing budget is.

 

Pete Skelly:We started … so we just actually met last night, started talking about sponsors. We’ll start probably a call for speakers coming up relatively soon. We’ve got a little bit. But if anyone is interested in topics, basically [email protected] I think is the email address. If not, you can always send it directly to me, and I can get it to the right folks. And typical every year Atlanta Coke Camp, that is probably going to be sometime in the fall again.

 

Danny Ryan:Good.

 

Pete Skelly:So we started planning those things. We had some really good recent talks at the SharePoint user group. Lee Cleary from Protiviti spoke on 2016 and kind of the business value behind SharePoint 2016. So couple of really good sessions recently with SharePoint User Group. And it’s not just SharePoint, we’ve changed the name really to the SharePoint and Office 365 User Group to cover a lot of the change that is happening. Yeah, a lot of exciting stuff happening there too.

 

Danny Ryan:Very cool. Thank you for doing that. Thank you for taking the time to do that in your off time. [inaudible 00:19:37] 24 hours. Thank you for taking the time to do this, Pete.

 

Pete Skelly:Yep.

 

Danny Ryan:Appreciate it.

 

Pete Skelly:No, thank.

 

Danny Ryan:You betcha.

 

Pete Skelly:Pleasure.

 

Danny Ryan:Thank you everyone for listening, and have a wonderful day. Take care.

 

read more
Pete SkellyWhat’s Next with SharePoint Development?
ludicrous-mode.jpg

Ludicrous Mode – Update on the Jive to SharePoint Migration Tool

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

Danny:Hi. This is Danny Ryan and welcome to the ThreeWill Podcast. I have procured Chris Edwards for your listening enjoyment. He has been quite busy lately.

 

Chris:Yes, very much so.

 

Danny:He’s been very busy, so I really appreciate you taking the time to do this. I’ve been talking to a lot of people about the Jive, the SharePoint migration tool. I’m anxious to get an update on what are the things you’ve been doing recently, maybe hit it at a high level and let’s dive in to some particular things. I know you’ve added some additional features to it. What’s been going on lately?

 

Chris:Just a lot of activity on the Jive, the SharePoint migration tool. Lots of things more so around just refining the process. Not so much the tool. Actually, I’ve got quite a bit of updates on the tool but more of the process of how we go about capturing inventory, really refining the inventory in such a way that people can understand what is out there in Jive. What do people have that they really care about, and how do they make decisions whether or not a particular Jive place or a collection of Jive content needs to stay or go. We’ve done some improvements really with the process to help make some of those decisions as well as understand when we do move a Jive place, how do we know if we did it correctly?

 

It’s great to be able to move content, but when we move content, what if only fifty percent of it came across? How do you know that? How do you know if eighty percent of it came across? If only eighty percent of it comes across, is that a big deal or not? Do we need to care about those exceptions and care about things that happen? A lot of more improvements around the tool, really around understanding the process and capturing ins and outs and making sure people are able to make really wise decisions about the content itself.

 

Danny:It sounds like you have people you take a look at, you have a way of understanding what’s currently in their Jive environment so that they can sort of … Because part of this process may be pruning some of it or not moving content over?

 

Chris:Yeah. One of the things that people may want to do is look at when was the last time a place or a particular piece of content within a place … When I say place, I mean this is a Jive terminology for any kind of container in Jive. One of the things we were able to expose now is when was something last modified in the context of a place? A lot of companies, especially the bigger companies, they want to have a retention plan in play. They don’t want to move stuff over that was last touched more than two years ago. We can now identify that a little bit better than we could before and really, it maybe that they want to archive it. The way the tool has been designed, I mean we talked about this last time, is that the tool still maintains the same design where we pull content out of Jive and we store it into either database and/or a file system. That’s kind of the archive, if you will. That’s still in play.

 

Whether or not we move it forward though, that same content, we transform it into something SharePoint can understand and push it into SharePoint which is our upload piece, we actually have terms for these things now, then … It’s crazy who that kind of stuff works. We can actually make decisions on whether or not something goes to SharePoint or not, and better decisions, not just everything. On top of the process and just being able to measure what are we doing well, what do we need to triage as an exception, we’re getting timeouts all over the place, how do we go about fixing that? Then, minimizing how much redo we have to do. We don’t want to have to redo everything that we find an error later on in the process. We want to minimize that. We’re not billing for that time. We want to make sure we’re using our customer’s money wisely and really making sure that we can wise decisions, enabling them, and then also making sure that they get their content in SharePoint and they’re happy with what they get. That’s all part of that.

 

We really have made a lot of improvements to the tool with regards to performance and pulling content out of Jive. We got more respect around the tool now. Before, it was kind of a loosey-goosey, here are the command lines, very … I thought it was good, I just threw it out there. It was quickly put together. Now we actually sat back and said, “Okay, what do we really need to be pulling out of Jive? How do we need to control it? Do we need to pull everything? Do we need to pull it by type? Do we need to be able to pull things by maybe something that was last modified by a certain time frame? We can specify these different parameters and really hone in on what we want to pull out of Jive.

 

We also have added multithreading to the tool. Now, the tool doesn’t just go after one place in Jive at a time. It can actually go after a whole collection of them based on how many processes around whatever server or whatever environment you’re running on, it can actually utilize those processors. Instead of being restricted by the latency of Jive and just pulling one place at a time, which is extremely slow, we can actually queue up and run multiple pulls from Jive simultaneously.

 

Danny:In the command line, do you like /ludicrous mode?

 

Chris:Exactly, ludi mode.

 

Danny:Ludi mode.

 

Chris:I put it in ludi mode and it just pulls it all down in two seconds.

 

Danny:Then that server starts warming up and it starts …

 

Chris:Yeah.

 

Danny:Nice.

 

Chris:You can really see it rip and do stuff. It’s trying to get a balance of what can we really pull out of Jive? How fast can we pull stuff down without causing it to break as well? It’s kind of getting that, trying to get to that balance point.

 

Danny:When we’re moving over, so we’re moving over like a batch of … We’re probably working with a client to decide what’s coming over first, is that correct?

 

Chris:That’s correct.

 

Danny:Then, once that moves over, there’s some … I’m sure there’s some remediation on our side and then on their side, some … Are they going through in some acceptance? “Yes, my content has been moved over properly,” is that what goes on/

 

Chris:Yes. Typically the customers’ responsible for validating their own content, but we put a lot of stuff and try to put a lot of stuff in place and really structure the roles for the … Like I said, I’m more of the migration engineer and tool, I make changes to the tool but we actually have a migration engineer person now that actually is just running the migrations. That’s all that their role is and they’re managing the exceptions and monitoring things before the customer even sees the content. They can help direct, “Oh, we have a lot of timeouts. Maybe something was going on in Jive. Maybe things were happening at that time. We need to go back through and check to see if any code needs to be modified to fix this.”

 

Really identifying patterns and what kind of issues are out there, so we can decide if it has to be redone or not, before even the customer gets it. Then the customer would get it, we would inform them that we’re going to get a dashboard format into our regular format where they could say, “These are the new places that are available in SharePoint.” We’ll have a look. If we find issues, then we’ll track it and the migration engineer will basically go to work with individuals to do that, and see do we need to redo things or not? We got more of process. We have to because we’re dealing with a lot more volume of content now. When we originally did the migration, it was for ourselves. We don’t have so much content. If we had to do manual steps, manual process, we did it.

 

Danny:How many years ago did we do that?

 

Chris:Two or three years ago.

 

Danny:Two or three years ago?

 

Chris:Yeah. It was the first kind of iteration of the tool itself. Since then, the tool has basically stayed in the same overall form. It’s still a console-based tool. It was built that way on purpose to keep it simple.

 

Danny:It’s just like JavaScript console apps are coming back.

 

Chris:Exactly. There’s no reason that … I mean, why bring an interface into this if it’s not needed. We have found the need for an interface in certain ways like when people want to manage what places go into Jive and we’re dealing with a spreadsheet right now.

 

Danny:That’s great. People are very familiar with working with a spreadsheet as well.

 

Chris:It’s great but it’s unwieldy as the same time. There’ll eventually be some improvements there where we can not be so tied to the spreadsheet and make it a little bit more … At least that’s my hope. Make it a little bit more of a user interface on that part of it. Can never guarantee that particular functionality is going to happen. It really depends on how many people are interested in the tool, how often we’ll use it and whether or not we really see the bang for doing that.

 

Danny:When you’re doing this, you must pull all of the user information over first before the content? Is that correct? What’s the sort of high level series of what happens?

 

Chris:Typically, we focus on inventory first. We talked about this a little bit the last …

 

Danny:You can say something twice. I will forget. Actually if somebody listen to it, you don’t have to hit it too hard, but go ahead.

 

Chris:That’s cool. Typically, we pull, we do a getPeople. We’d pull the people in Jive first because everything is dependent on the person. Even the creation of a place, even the specification of a place. When I say place, in Jive, it’s the concept of blogs, spaces, groups, and projects. Those are the kind of four container text. Place is just a generic term for that, so I keep saying that every time. Essentially we pull the people, we pull the places, and then we pull what’s called the metadata run of content. We pull the high level of content into our database so we can get content counts. We know kind of at breadth what’s out there, what was last modified at the content level and at a place level, and we produce a spreadsheet out of that. We take that and we give that to the customer so they can say, “Okay, these are the particular places that really have been modified most recently, which ones have not been touched forever.”

 

They have a lot of information as well as counts as well as the size of each of the places, I mean, all that kind of stuff’s in the spreadsheet. They can take that and make their decisions. Then we batch it like you said earlier into logical chunks. We found that a logical chunk of like fifty places at a time is a nice focused batch. We may ramp that up as we really get further into this and work with larger customers. A batch of fifty at a time seems to be pretty reasonable because you can report updates on those, you can monitor exceptions on those, and it’s a consumable amount to say, “Here customer, here’s another batch of fifty. You can communicate this to your end users.” It seems to be a pretty nice manageable amount. That’s pretty much how it works.

 

Danny:It sounds like here’s a couple of new folks that are working with you. Is that like Lisa and Brendan?

 

Chris:Mainly Lisa. I have Gary working with us a little bit as well, doing more of some performance improvements and helping with some of that.

 

Danny:What about, are there different content types? Have there been some content types nuance that we’re supporting? I know we’re giving some estimates around where a blog post maybe coming.

 

Chris:When we originally wrote the tool, it was focused on three different containers. I kind of rattled them off earlier. There was the blog, project, group, and space. Originally blog was not part of our mix. It wasn’t really treated as a primary content type inside of Jive. We were really focusing on the spaces, projects, and groups. That really came over when we originated the tool for ourselves. I don’t think blog as a container type was really even around that time. We’ve been improving the tool. We got some updates to it that actually include blogs as a primary container type now as well and bringing over that content as well too. That’s some improvements to the tool and really making sure we can cover any type of place that’s in Jive. We have a story to deal with that. We focused on tasks. We’ve pulled discussions. We’ve actually changed the tool now so instead of generating pages like Wiki pages, things like that for discussions, it actually generates SharePoint discussions and real thread SharePoint discussions in SharePoint.

 

Danny:Nice.

 

Chris:It’s nice because it actually can be begin to introduce as a discussion. A discussion in Jive can be moved over to SharePoint and continued to be used as a discussion in SharePoint. The user information’s maintained, the timestamp’s maintained and the whole threaded nature of the discussion is maintained. That’s definitely the super improvement to the tool.

 

Danny:I used discussions. I used one like, I think the last time was six years ago. I mean, it was [inaudible 00:12:42]. I don’t remember.

 

Chris:Yeah. It’s not …

 

Danny:I don’t remember the la- … I’m being just upfront. It seems like that’s been something that again with the overlap between SharePoint and Yammer, more recently just got lot of the discussions go on inside of Yammer.

 

Chris:Right.

 

Danny:At least this gives you an archive or the content and you can pick up the Yammer discussion off of it as well.

 

Chris:You can do that.

 

Danny:You can refer to it or, you know, stuff.

 

Chris:You could use it by its pure nature, you could use it as a discussion in SharePoint, so that doesn’t really end that, but yeah you said it, it’s a great launching point to start from Yammer to say, “Okay, I want to point to this discussion and continue from there.” It works either way. It maintains the integrity too of the threaded nature of it and kind of how things were created in Jive. It matches a little bit better. Before, we were doing things where we would create these pages and it was more of a static pull. You would have to go to something like a Yammer. It was really your only option that can continue the conversation. Now we have a little bit more of a rich set of options to go continue the conversation.

 

Danny:Jive has the concept of secret groups. We’re handling those as well?

 

Chris:We’re actually capturing permissions. In terms of when I say permissions, really we’re capturing the users at the place level. How many members are in different Jive places? We’re actually able to capture that detail now in our database. That’s another piece of archive information we have. We could also play that forward. If something was a secret or private group in Jive, we can actually provision the site in SharePoint, apply the actual permissions in terms of who is a member of what in SharePoint, and then pull in the content. That way, we’re not actually opening up content to folks that shouldn’t see it. We’re actually able to leverage and move over the people and the people membership references from Jive into SharePoint.

 

Danny:Then those people would, you’d have to have the acceptance on their side, you’d have to have somebody who has access to the secret group to say, “Yes, the content’s moved over.” You have a secret group, you moved it over, how do you know …

 

Chris:Secret private groups in terms of SharePoint, there’s really no kind of differences between those. They’re basically the same thing.

 

Danny:Once it’s moved over to validate … Let’s say there’s a super secret HR discussion group, three members in that group that are over in Jive, it gets pushed over into SharePoint, then you have to have one of those three people to go and verify that the content did get moved over properly.

 

Chris:Right. As part of that spreadsheet I mentioned earlier, we actually have a list of all those types of users. For those highly sensitive places, it’s still up to the customer to communicate to their end users when it’s time to go look at it. We don’t add users to a site in SharePoint unless they were part of the appropriate place in Jive.

 

Danny:You’ve added, done some tweaks with multithreading.

 

Chris:Yes. [crosstalk].

 

Danny:Some of the [crosstalk]. What are we at a high level, just at a high level, what does that mean? Like you’re moving over a certain number of sites per hour or what is that?

 

Chris:This is for like the content metadata run like I talked about earlier where we just wanted not necessarily to pull down all binaries but we just iterate through all the content in Jive. We’ve been able to do something that previously took like a day, day and a half, I’ve seen it go down to like an hour, hour and a half. It’s a substantial difference.

 

Danny:Nice. Then the file content, it’s dependent upon how quickly the bits go over the … Is it pretty quick?

 

Chris:Pretty quick as well. Yeah. Typically we’re pulling down content and all the binaries that come with all that. Pretty much, everything that, let’s say from a batch of fifty like I talked about earlier.

 

Danny:Sure.

 

Chris:A batch of fifty places, let’s say they’re not super large places but let’s say a batch of fifty, we could pull that down in say like fifteen minutes. Before, that might have taken us half a day to do that just because we’re doing it at a very single-threaded way. There’s just a lot of latency there that we’re just not taking advantage of the machine that was running the tool. Really try to take full advantage of the machine and what Jive could actually accept for throughput. That way, we’re able to really trim that down. It’s important because people that are wanting to come off Jive, they want to get off there within a timely manner. It can be a major risk if they’re running up against the licensing end date and they’ve got a lot of content. We want to be able to get that content down quickly and be able to, I don’t know what we’re going to do with it.

 

Danny:Is there any plans to, because I know with Jive you can request a backup, let’s say when you’re moving off of Jive. Are there any plans for us to, instead of working with our API, to work directly with the backup to do this?

 

Chris:I’ve done that myself. Just poking into the database, but we don’t have any plans at the moment that allows us to programmatically look at that.

 

Danny:It might be interesting for us to look at that because if that’s … Because APIs change, right?

 

Chris:Sure.

 

Danny:Just in case like as a backup plan, if you can get the database backup of the whole thing and …

 

Chris:Can we take in a full content out there and transform it the same way?

 

Danny:Can we take in full content and then … Yeah.

 

Chris:That’s one of the nice things. The way we’ve designed this is that if you could read that database programmatically then you could basically push it through the same procedures we currently have for the transform piece and the uploads. All that would stay the same.

 

Danny:The only reason why I said it is it’s also a backup plan in case they’re not able to get out in time and we’re not able to get everything out if we can work with the database backup. That gives an alternative planning for people.

 

Chris:Exactly.

 

Danny:Just a thought I tried to come up with.

 

Chris:That’s good.

 

Danny:Such a little thing.

 

Chris:Backlog.

 

Danny:That’s probably the worst type ever. You would say that to me like, “Danny, that is the worst idea.” You’re going to leave the room and go tell people, “Danny said we’re going to [crosstalk].”

 

Chris:I think [crosstalk]. No.

 

Danny:He obviously hasn’t touched Visual Studio in over seven years.

 

Chris:It’s all good.

 

Danny:It’s all good. Thank you.

 

Chris:You know what, it’s actually a good idea. If companies are coming up with that, running into that risk of that restriction, we want to have as many options. It’s really one of those things if people really need it, we’ll do it. Probably not going to be something we’re going to focus on right now.

 

Danny:You’re now moving over to doing some getting started workshops, another some that we’re throwing on your calendar to help out. I think there’s some other folks who are jumping into the fray as well …

 

Chris:Exactly.

 

Danny:… to help out. That’s going to be good for you also just to see a couple, you know, more environments, see what people are doing and making the tool even better.

 

Chris:Making the tool better, getting other folks familiar with the tool, and really getting their thoughts too on ways that it could improve. Like I said, it was designed quickly. It was put together quickly to accomplish a task. We definitely refined it and made it a whole lot better, but it doesn’t mean it couldn’t be even better.

 

Danny:A lot of products come from scratch in your back. It’s amazing.

 

Chris:It’s solving a problem, right?

 

Danny:Yeah, solving a problem.

 

Chris:Yeah.

 

Danny:Anything else before I let you go and don’t see you for another quarter? Well, I’ll see you I guess at the kick-offs for these things.

 

Chris:Sure. No, I mean, that’s the basic gist. We are putting together some documentation to better define some of the stuff we’re talking about so it’s not just me rattling this stuff off on a recording like this. We’re actually going to put together some book and some details, so if someone wanted to pick this up, they could understand it in much more detail.

 

Danny:I get request all the time from folks in foreign lands asking for this as a product and I know right now it’s still a fluid thing, but maybe even- … I’m not saying we would never package it up as a product, but for right now, I think it’s best we’re doing the services along with it and then including the tool itself until we get it to a point where we’re happy with it.

 

Chris:Yeah. We talked a little bit about being able to monitor exceptions, monitor the … I mean, I just don’t think it’s at a state where I’d feel comfortable with handing this off to someone and they go run it. I want to be pretty confident that they’re going to be successful with the tool. It definitely requires some hand-holding. It doesn’t mean one day, we’ll just have to wait and see what it looks like and what the demand is.

 

Danny:Absolutely.

 

Chris:If it’s really going to help someone, we’ll make that decision then.

 

Danny:Awesome. I hope everybody enjoyed this especially if you’re looking at moving from Jive to SharePoint. Just a little update. Probably the next time, I’ll probably just do another update on this. This really helps me because when people are contacting us, unfortunately I’m the first line of defense.

 

Chris:I don’t know what.

 

Danny:I don’t know what it does actually but at least if we get an update once a quarter, I kind of can say what it does. This really helps me out, so thank you for taking the time to do this.

 

Chris:Anytime. Thanks.

 

Danny:Awesome. We have recently added some intro and outro music to our podcast.

 

Chris:Nice.

 

Danny:We’re getting there. I’m slowly putting a spit shine on it. It’s getting there. Thanks everybody for listening. Please drop by our threewill.com site. You’ll see a whole section on migration. Come drop by and let me know what you’re trying to do, what you’re trying to migrate from, where you’re trying to go. Really appreciate everybody reaching out there and have some real good leads come to the website. We really appreciate you taking the time to reach out. Thank you so much for listening to this podcast and have a super day. Bye.

 

read more
Chris EdwardsLudicrous Mode – Update on the Jive to SharePoint Migration Tool