Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has spent nearly a decade helping clients transform and migrate their content from one platform to another (typically to Microsoft 365) with a focus on the more complex scenarios. Prior to his transformation focus, Kirk led several key SharePoint integrations at ThreeWill including Jive, Polycom, and Confluence.
Danny serves as Vice President of Client Development at ThreeWill. His primary responsibilities are to make sure that we are building partnerships with the right clients and getting out the message about how we can help clients.
Find this Podcast “Large and Complex SharePoint Migrations Webinar” on the ThreeWill Soundcloud, Stitcher, and iTunes.
Transcript
| 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.
|
