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 “Updated Webinar on Moving from SharePoint Online Dedicated to Multi-Tenant” on the ThreeWill Soundcloud, Stitcher, and iTunes.
Danny:
Hello and welcome to the ThreeWill Podcast this is your host Danny Ryan and what we’ve got for you today is a webinar from Kirk Liemohn about moving from Microsoft 365 Dedicated to Multi-Tenant. And of course as we started this webinar, I forgot to hit the record button so the first question I asked him is cut off from it but we’ll jump into it. To get it kicked off here, Kirk is a Principal Software Engineer here at ThreeWill and he was on a recent project where he helped the client with the process of moving from a dedicated to Multi-Tenant and we kicked it off with a question of why you would want to move from dedicated to Multi-Tenant. Let’s jump right in..
Kirk:
… is SharePoint Online, but it’s only … they don’t share resources. There’s only one tenant for … your resources are for one company, one tenant. It really is more like SharePoint 2013, or has been in the past. They wanted to move from dedicated to multi-tenant primarily to save on cost because dedicated environments cost a lot more.
Danny:
Okay.
Kirk:
The utilizing costs are … I think they’re more than double. So they’re going to save a lot of money. That’s the primary reason. A secondary reason would be that they wanted to get the benefits of SharePoint Online multi-tenant because that’s where Microsoft is putting most of its efforts. There are only a handful of companies, albeit large companies, that are in the dedicated environment, and by a handful, I mean dozens, 50, 60, somewhere in that range, probably. When it comes to multi-tenant, there are, I don’t know, hundreds of thousands, or something along those lines, of companies. Then, of course, then a number of users is created there as well.
Microsoft is rolling out the newer features there first, so if you want some of those new features, then you might want to be in that environment. You might have to wait years, potentially, for them to get into some of these other environments.
Now that’s going to change. There’s this vNext version … I don’t know if that’s an internal name or an external name … for dedicated that is going to be more at parody with SharePoint Online multi-tenant. I don’t know exactly where that is right now, but then it’ll be a little bit more feature parody between the dedicated environments and the multi-tenant environment.
Danny:
Got you. Were they originally on dedicated because of … to support more of the custom environments? Or what was sort of … I’m maybe just generalizing here, but what would be the reason for someone to go to dedicated in the first place?
Kirk:
Yeah. I think that was probably … I don’t know the history on it, but I think that was probably the reason. In dedicated, you have some leeway, so you have a little more control. For example, you can limit how often you’re getting your updates, and you have more control of when those updates occur, and you have more white glove service of support, from a support standpoint, than you will in multi-tenant. I think that’s always going to be the case. I don’t know exactly how much control they had in terms of when updates could come out, but they had some level of control.
In SharePoint Online multi-tenant, you have very little control of when things are going to get updated, and sometimes you don’t get really notified when things are getting updated, so there can be problems with that. In addition, they had the ability to have some level of farm solutions. There was a fairly complicated MSO path process, and I forget what that stands for, but a process for getting custom farm solutions into the dedicated environment. So they had that capability, and then they had to go through a review process. That review process was done by Microsoft, and they could’ve declined things, and they certainly did, depending on what it was, but they had that capability. Now this vNext I referred to recently, once that happens, I don’t believe any farm solutions will be allowed though.
Danny:
Okay. For the project itself, did you … How did it get kicked off? Did you guys start with some sort of analysis phase or … and was there sort of a lot of pre-work that was done before … I imagine before the migration itself, but how did the project kick off?
Kirk:
Yeah. There was, and we actually … I think, if I remember right, we had an analysis phase, and then there was a little bit of a pause, and then we went into the next phase. In the analysis phase … that’s the way we like to structure our migration projects. We like to have an analysis phase, a plan, a verify, and an execute. In that analysis phase, it will cover the scope of the migration. Are you migrating a single farm, multiple farms, where are you going to, what are you going from? We, at, we deal with Jive migrations and other migrations, so we want to know the scope of what’s being migrated.
We want to understand their vision, what objective they had, what are their success factors. We want to … Out of that analysis phase, we want to come up a migration approach, and give them a roadmap or a plan of how we would do the migration. We want to come out with things like a resource plan, a schedule, what risks we see out of the planning phase, and then communication is definitely a big one. We want to get that started and start having a communication plan with the project that will be updated later, but we want to get that moving. Then, obviously, at the end of the analysis, we want to come up with an estimated budget for that migration. Those are the types of things we did on this project that we’re talking about.
Danny:
When did you do the … because there was a tool selection process that you had. Was that part of this as well?
Kirk:
No. We did … It could be, but we did that more in the plan phase.
Danny:
Okay.
Kirk:
Yeah. The approach we took was … Well, any complex migration with a lot of data is going to require a tool. You can’t easily more things from one SharePoint environment to another. Now there are different approaches like constant database backups and database attaches or site collection backups. Some of that stuff just can’t be down when you go into SharePoint Online. In fact, none of those can be down when you go into SharePoint Online. In fact, none of those can be down when you go into SharePoint Online. In those instances, a tool is definitely required.
So we looked at several tools at a high level. So we had a set of requirements that drove our tool selection process. One of them was, we had so many site collections that we were trying to move … it was in the thousands … that we knew we didn’t want to be pointing and clicking on the tool to just move each site collection, for example. We had to have something that we could automate around that. That narrowed our tool down quite a bit. It had to be one that would do the lift and shift type of moving of site collections, which is a requirement for this one because there were so many, which most tools are capable of doing. It had to be able to go to, obviously, SharePoint Online, so that means it’s going to be connecting via CSOM.
There was a new migration API from Microsoft for moving to SharePoint Online, and it uses Azure. That was something we were very interested in because there can be issues with throttling if you try and push a lot of things into SharePoint Online at once. They’ll try and slow you down and cause issues. So that migration API was key for us, so we were looking for a tool that supported that as well. Once we narrowed it down a little bit, we took a deeper dive on two of the tools, to compare the capabilities based on our specific needs. We’re going from a dedicated environment to a multi-tenant environment, and we just wanted to find out what worked and what didn’t work for those environments.
Danny:
We ended up going with, when we were partner, with Metalogix Content Matrix.
Kirk:
Yep. That’s correct.
Danny:
Then we ended up … with app dev background, we want to automate everything. Right? I heard from one of the things from the project, we ended up creating over ten thousands of powershell script to automate it. Right? That what happened?
Kirk:
Yes. Yeah. I don’t have pride on how many lines of code are created, but it ended up being a lot.
Danny:
Well, I could’ve done it in five thousand lines of code, just to let you know.
Kirk:
Yeah. So, you know using … and this is true, I think, with all the tools, the Content Matrix UI, it lets you connect to a source site. In this case, it’s a dedicated environment and lets you connect to a target site. In this case it’s SharePoint Online and you can say, “All right. I want to copy this one to over here,” and then you have a lot of things to configure. Okay. How many versions are you going to maintain? What are you doing with user mapping? Lots of things. There are dozens of things to configure in there. It’s really easy to make a mistake. Easy though, with Content Matrix, it will let you set defaults or remembers what you did last time …
Danny:
Yeah.
Kirk:
There’s a few things that are not defaulted to the next time. You really wouldn’t want to have to go through that thousands of times anyway. It’d be error prone and time-consuming, so we definitely did automate that. We used Powershell for that. We automated it in several ways. We use a SharePoint list to create our batching structure of what site collections are going to be moved when, and we then used Powershell on several Azure migration nodes, just servers running in Azure that had Content Matrix on it. They would pull from that list and decide what site collection they’re going to move at the time.
Then after they moved them, they would analyze the results, the logs of what happened, and we would do some initial triaging of that, and that would get into a SharePoint list as well. Then we could do some manual triage and manual remediation from there. It also did things like notifications to users. There were a couple types … e-mail. E-mails are sent out to notify users that their site’s being migrated, that type of thing. Information was stuck on both the source and the target site collection pages, so that you could tell that it was being migrated, for example.
Danny:
You really just wrote all that Powershell script because Pete was on the project. Right?
Kirk:
Yes. Well, he didn’t get to write that much, actually, but …
Danny:
Oh no.
Kirk:
We didn’t get to.
Danny:
Is that Will- Who else was on the project? Who was on the team?
Kirk:
Yeah. So, it was Pete … I guess he would be the overall lead, and he was the scrum master. He did a lot of the blocking and tackling for us. This is … there’s a lot of moving parts on this project, so we really looked to him to help us figure out where we’re going to focus. Will Holland, he was a developer on the project, and he did a lot of the Powershell. He also helped manage our offshore team. So we did a small offshore team we were working with as well. Rob Horton, he actually played a couple of roles.
He developed a realtime dashboard that would watch our migration nodes in Azure so we knew what was going on, and we could see what their status was and maybe how many things … how many site collections they were copying at the time, and if they were ready to take on new work, which they did automatically. You could set them up so they did it automatically, but it helped us know what was going on. That was just a part of what he did. A lot of what he did was around managing the support process, so how are support tickets going to be handled and what’s the process for making all that happen?
Danny:
Nice.
Kirk:
We had Trident for offshore help, and they wrote some of the Powershell scripts that we wrote, and they also did a lot of the manual triage work. Then I was dev lead and Powershell script monkey, as well.
Danny:
So you got some Powershell script in, at least.
Kirk:
Yeah. Well, actually one of the things I did … I spent a lot of time on was validating the use cases for the migration tool. I did that to pick the tool, but still needed to understand where it was not going to work for us because these tools have to handle a lot of different scenarios. They’re used to handling … going from SharePoint 2010, 2013, 2010 to Online, 2013 to Online. It so happened that Content Matrix had a concept of being able to put a plug in into a dedicated environment, so that was useful.
Are they going to be doing a database attach or not? So there’s all these different things they have to deal with, different scenarios, and then different configuration parameters. What are you going to do with versioning, as I said before. How many new versions are you going to have? How are you going to map your users, those types of things. They have a lot of things to deal with, and because of that, there are going to be some issues, and we had to find those. Example of one, which I believe was fixed by Content Matrix since then, was around regional settings. Some regional settings weren’t making it over. So in our Powershell scripts, we would do that ourselves. So there’s a few of that … some of that going on.
Danny:
Yeah. It sounds like you guys were really using Content Matrix as sort of like a platform to actually go build something act, which is [crosstalk].
Kirk:
Right. Ideally, you’d … and I’d done some of this, but ideally, you do not want to have to write a migration script from scratch. There’s just a lot of things those tools have to cover.
Danny:
Yeah.
Kirk:
If you try and write one on your own, you will realize it, but it’s hard to realize until you start doing that.
Danny:
How important was communication on this project? You mentioned it earlier, and I think you … times in which we talked about migrations, you keep on bringing me back to communication. Was it critical on this project, as well?
Kirk:
It is. I think it’s critical on all migration projects that have any size to them. So yeah, very important. There’s lots of reasons that it’s important. There are a lot of parties involved. So you have your end users, you have your site owners, you have IT for the company that is in charge of this migration usually, you have your stake holders, and then, of course, the migration team that’s doing the work themselves, but you need to be in proper communication with those parties. You don’t want your site owners to be surprised and all of a sudden find out one day that, “Oh, my stuff’s been migrated,” and they didn’t realize it was going to happen.
If you can do a perfect migration where they can’t even tell, then maybe you don’t need to do something like that, but when you’re going from one version of SharePoint to another, you’re going to have some problems that they’re going to need to realize are there. That gets into other aspects of the communication, so you might have some documents out there that you want to communicate to them so that they know what’s coming. So that one might be … we call it … one of those things, a policy manual, so that they can … they know what the policy is from a migration standpoint.
Do we support migrating running workflows? Well, if you go into SharePoint Online, you don’t. It’s pretty much impossible. There’s certain things you are not going to support, and then maybe there are certain things you are. Maybe you’ll choose not to support moving branding over. Because if you’re going from one version of SharePoint another, then the branding story’s different, especially when you go into SharePoint online, and that’s going to be hard to do that with ease.
There’s other things you want to communicate. Instead of just having documents and checklists for them to read, like your pre migration run book or something like that. There’s also, as I mentioned, e-mail notifications or other notifications on the SharePoint site. Then when are you going to communicate to these people? Are you going to tell site owners months in advance? I think that’s a good idea, especially if you’re going to SharePoint Online. Because even if you’re going from dedicated, if you’re going to SharePoint online and site owners don’t know, who’s going to deal with any farm solutions they have, if they do have those? Those don’t go into SharePoint Online and it doesn’t … it takes time to migrate those over. We do those types of migrations as well. There’s just lots and lots and lots to cover. If you don’t start … If you don’t have a plan on your communication, you’re going to miss some of that stuff, and there’s going to be people disappointed because you missed it.
Danny:
So talking about disappointment, all this hard work, all this preparation … We start the migration. Right? We were in week one of production migrations.
Kirk:
Yes.
Danny:
I love a good story, Kirk. So this is a good story. It’s not that it doesn’t have a happy ending, but … so we started doing migrations, and then everything was put on hold because of the exchange migra- things not going as well with … over on the exchange side. I thought SharePoint was the tough part. Right?
Kirk:
Also, too …
Danny:
[crosstalk] more had to do with active directory stuff, too. That complicated things, as well. Right?
Kirk:
Yeah. Well, maybe. I would say probably more exchange. What we were told was that the exchange migration, which was supposed to happen months before ours, and then kept getting pushed off, and then started happening right as we were starting ours, a little bit before, maybe. There were some issues coming out of that that were causing problems. There was some change in upper-level management as well around the same time, maybe just before then. So they didn’t quite have the buy-in from the new upper-level management.
When some of those … I guess some of that exchange migration was having problems. They just put a hold on things. Yeah, that was disappointing, but definitely learned a lot from it, and that’s one of the things around the communi- that go back to that communication, because that’s why it’s so important. We didn’t have, maybe, an opportunity to communicate with those new stakeholders until it was pretty late in the game because they came along late, but you want to make sure you get buy-in from your stakeholders, and make sure they understand some of the pains that are going to involved with the migration. You don’t want to hide that from them.
Danny:
Yeah. So did you … Do we … We had to back out some of the content. Right?
Kirk:
Just a little bit. We barely started the production migration. So the only time when you would have to do that is if they started making changes in the target environment. That did happen, but it was small enough where I think we were able to just write some scripts to figure out what had changed, and then do some relatively simple backwards migration, if you will. I think we just mainly did that with a tool.
Danny:
Got you. Got you. So now looking back on this and at least … What? Six months or so since … at least since we wrapped up the project. What nuggets of wisdom would you have , or sort of are the takeaways that you have from the project?
Kirk:
Yeah. So I’ve already mentioned communication.
Danny:
Yeah.
Kirk:
I don’t think I can emphasize that one too much, but … so that was clearly important for multiple different reasons. With large companies, they have ways to communicate with their users and stuff, that you have to be in line with. You just have to realize that there’s some red tape there you got to deal with, and there’s a proper way to do it for each company, so you want to be aware of that. One of the other big takeaways just around running the pilots. You want to run … there’s going to be things like POC’s especially if you have maybe some custom code that you’ve written to do some automation or you’re jut trying to validate certain use cases with a tool.
Then you’re going to start doing pilots, and you need to start doing pilots, and they need to be done with as many, if not all, of the processes in place. When I say that, I’m talking about, you need your support process in place. You need your triage process in place. You need to run … you need to run everything through the pipes in terms of trying to understand how is this going to work beginning to end, and if that means doing multiple pilots where your first pilot is only focusing around certain aspects, and then a later pilot is trying to handle more, then that’s fine. You’re going to … if you don’t do a pilot with all your processes in place and as part of that pilot, then you’re going to have more surprises when you’re doing production.
Danny:
Okay. Makes sense. If you had to give some advice, maybe who’s … this is really what I would classify as a really complex migration. You mention communication. You mention piloting out things first. Anything else that, advice wise, that you would give to someone looking to do this type of project?
Kirk:
Well, I mean … Yeah, so communication is key still. Give yourself time to have that communication to occur.
Danny:
Okay.
Kirk:
These migrations … that means you got to … if you want to be migrated in the year 2018, you need to start thinking about the project now, so that by this summer or so, you can start planning and sending out communications to site owner, especially if you’re going to SharePoint Online from a on-prem version or a dedicated version because if you got farm solutions, you got to have a plan around those. Each one of those is a project by itself … you know, migrating a farm solution to SharePoint Online because you got to re-architect the code. We’ve done that, as well.
You want to determine what your migration policies are going to be early on, so that you can communicate that out and people know what to expect. So that requires some understanding of what your source and target environments are and what their capabilities are and what the capabilities are with tools to move it from the source to the target environment. That takes some effort and time. So you got to give yourself plenty of time, I guess is what I would say. Other things to think about are external users. Do you have external users in your environments? Especially if you’re using an on prem and you’re going to 2013, that external users exists in SharePoint Online. If you’re going to SharePoint Online, you’re … it’s a different concept of external users. It works differently. The main one is communication and time.
Danny:
Time.
Kirk:
Yes.
Danny:
Which is why we try to start these migrations as early as possible, but unfortunately …
Kirk:
Users they come along and say, “All right. We need it in three months,” or something like that.
Danny:
Because I remember from our last conversation, there was a cut over date, and you can’t change that date, so you really have to manage a project around a fixed timeline. Which brings a new level of complexity to things as well.
Kirk:
Yeah. Change of scope. Right? So there’s only a certain amount you can do in a certain amount of time until it changes your scope. Then you start saying things like, “Okay. Maybe we won’t migrate my sites. At least that reduces some load. Okay, we’re going to simplify things. All right. We aren’t running any workflows. We’re not even worried about those. Site owners have to pay attention to those.” I’m just making up examples of ways to simplify. So things like that would have to … you have to take … you have to cut some corners if you’re going to try and get it done in a really quick timeline.
Danny:
So you’re working on a white paper on complex migrations, which this project would fall underneath. Was anything that you have in there, was it influenced by this project at all?
Kirk:
Oh yes. Heavily, and a lot of the things I’ve been talking about are in there. Communication is definitely talked about, and there’s other aspects, too, for sure. That the way we … the types of documents, the way you might plan, the process we put in place around this to have an assessment phase, a planning phase, verify and execute, those types of things. Big influence. I’ve been fortunate enough to work on several types of migrations, so this dedicated to multi-tenent is one. I’ve done some application migration where we’re going from farm based solutions to the client side technologies when you’re moving to SharePoint Online.
Danny:
Mm-hmm (affirmative)
Kirk:
It’s a requirement to be client side even if it’s not SharePoint Online. There’s … What I’ve learned from those who have gone into there … even those the white paper’s more focused on SharePoint to SharePoint, I’ve done also Jive to SharePoint, and there’s some takeaways from that as well. So a lot of similarities in terms of the process, for sure. Then, you still have issues with migrations and how are you going to handle those, and they’re a little different when you’re going from Jive to SharePoint, but you have to be able to react in the same types of ways.
Danny:
Mm-hmm (affirmative) Well, this was great, Kirk. I appreciate you taking the time to put a button on this project and help talk abut what things you’ve learned from it and look forward to that white paper to share with other folks. If you’re interested in it, you can actually go to our website and I’ll send that out to folks as it’s available. Also, just for folks … I am recording this and we’ll send out the audio for this. I’ll send that out to everybody who’s are the webinar next week.
So I’ll end you a link to that. This was great, Kirk. Thank you so much for taking the time to do this. We’ve got some … this first quarter we’re focusing on doing migrations, so we’ve got a couple more coming up. Kirk referenced that we’ve been doing a lot of Jive to SharePoint migrations. So our next one that’s coming up is a discussion about migrating from Jive to SharePoint. That’s coming up next month. Let me … I’ll get the exact date on when that is. It’s the 23rd of February, so it’s Thursday at 1 PM. Then coming up in March, we have another one, which is about complex SharePoint Online migrations. That one will go through the white paper with folks, too, and share what your learnings are in that white paper. So, Kirk, thank you so much for taking the time to do this, and thank you, everyone for listening, and have a wonderful day. Thank you. Bye-bye.
