Will Holland is a Senior 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 for working with .NET, MVC, and cloud-based solutions such as Microsoft Azure and Microsoft 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.
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.