Businesses migrating from on-premises SharePoint to SharePoint Online face all the same issues as those moving from an older version like 2010 to a newer one like 2013—plus all the issues associated with moving to the cloud. A survey conducted earlier this year by Cryptzone found that 39% of companies using SharePoint are on the 2013 version, 29% are still on the 2010 version, and 16% are already using the cloud version SharePoint Online. Not surprisingly, though, it’s this last category that’s growing the fastest.
A full 48% of businesses surveyed were already using Office 365, a bundled cloud software service that includes SharePoint Online, and another 15% plan to adopt it in the next year. Though many respondents cited security concerns as reasons for keeping at least parts of their environments on local server farms, the biggest stumbling block for a lot of businesses remains the complexity and time-consuming nature of cloud migrations.
No two migrations are ever the same, so answering questions like “When should I upgrade to a new version?” or “How much time should I budget for my migration?” or “Is the cloud the best option for my company?” is all but impossible without doing a good deal of upfront analysis. There are, however, some mistakes that are common to almost every failed migration project.
And they tend to fall into one of these categories:
1. Treating Your Migration like a Side Project
Maggie Swearingen at Redmond Magazine calls this “Internal-Project Syndrome,” and you probably already know exactly what she’s talking about just from the name. Your business’s own projects are constantly getting pushed to the wayside whenever deadlines loom for your clients’ projects. Instead of assigning a team to the migration exclusively, many businesses task one or a few IT people with moving content over whenever they have some extra time.
SharePoint migrations take enough time when done properly—anywhere from 5 months to a year—but when they’re treated like side projects they can end up dragging on so long that by the time they’re finished a new version is being released. So the first step is recognizing that migrations are an involved process that requires a lot of upfront analysis and planning, a dedicated team, and a lot of time.
2. Leaving the Project Mostly or Entirely in the Hands of IT
Every successful business IT project relies on a balance between expertise in, well, business and IT. But, since SharePoint is a technology, many business leaders assume it’s reasonable to hand off migrations to their IT staff. This would be fine if it was only the IT staff who would be using the new system. There are few technologies, though, that are as intimately tied to business processes in all the departments of your company as SharePoint. And, when it comes to developing a content strategy and creating an information architecture for regular business users, people with deep knowledge of those processes are going to be a critical part of the team.
As Aptera’s Senior SharePoint Administrator Scott Walsh explains, “You can find people who are beyond proficient in all the technical aspects of SharePoint, but the biggest challenge, both when we’re dealing with people on the client side and even when we’re hiring, is finding anyone who really understands how the system will work in the business context—and that understanding is not some added benefit. It’s crucial to making things really work.”
3. Lifting and Shifting instead of Mapping and Restructuring
It’s tempting to look at migrations and upgrades as one type of project and updating your content and information architecture as another type of project. But do you want to migrate a bunch of content that nobody has any use for anymore? In any SharePoint migration, there will naturally be some content that can be lifted and shifted to the new environment pretty much as-is, but that’s probably more the exception than the rule.
What this means is that before embarking on your migration, you’ll need to inventory and assess all your business’s sites, workflows, list settings, documents, etc. to determine how much time and resources you’ll end up having to devote to them. This is important too because obviously some of your workers rely on certain parts of the system to perform daily tasks, so the downtime could seriously disrupt your business. Prioritizing each part and projecting timelines for when their transitions will be complete are essential aspects of planning.
4. Overlooking End Users
The whole point of SharePoint is to make your workers’ jobs easier so they can be more productive. You won’t get much return on an investment in a system few people ever end up using. The key to ensuring user adoption upon completion of any SharePoint project is to involve end users early and often. Representatives for users fulfilling each business role should be consulted in the planning phase so that the solution addresses their challenges as directly as possible. And you should have plans in place as well for keeping everyone informed of the project’s purpose—which should be to make their jobs easier—and for training them on the new system.
Walsh likes to point out that “People aren’t going use a new method for doing something like sharing a document if the old method is simpler and takes fewer steps.” That’s why the daily challenges of each type of user need to be incorporated into the architecture of the solution. While IT people are probably more apt to explore a new system to discover all the tools and capabilities, business users can’t be counted on to go out of their way to experiment. So the challenge is to lay out what you want your workers to do in a series of easy steps, and then take the time to walk them through the process a few times.
Microsoft, along with several third-party vendors, is well aware of how complicated SharePoint migrations can be, and they’re working on tools that will make the process as quick and painless as possible. At the Ignite conference this past summer, Microsoft announced the release of a new Migration API that speeds up the transition from on-premises environments to the cloud by channeling content through Azure, which offers a much higher throughput. And companies like Sharegate are already offering tools for migrating forms and workflows like those set up with Nintex. But, while it seems the end game for Microsoft is to eventually get everyone in the cloud, for the time being the optimal choice of environment is best decided on a case-by-case basis.
Popular posts like this: