Migrating your on-premise SharePoint solution: key strategies and lessons learned

Since Microsoft’s announcement of upcoming SharePoint 2019 later this year, many organizations are planning to move to SharePoint 2016, SharePoint Online, or Hybrid.


Often companies choose a lift-and-shift approach, where the solution is moved to a newer version of SharePoint with no functional changes. This approach is cost effective especially if your previous solution has not been heavily customized, and you just want to take advantage of all the new features available. Lift-and-shift can also be selected as a “phase one” migration, followed by functional enhancements in later phases.

Although this is a relatively straightforward path, here are the key tactics we found crucial with many customers over the years.

Do a trial run / Have Pre-Production environment

As your SharePoint environment goes through updates, it’s hard to keep track of everything. Small customizations are often implemented by Power Users directly on the page via script. Sometimes it’s a piece of JavaScript, or a workflow built using SharePoint Designer. Those may not easily translate to a newer version of SharePoint and that’s why we recommend doing a trial run on a development environment using DB attach process.

Once you have ran the migration, you can involve your key users with a smoke test of their specific areas. This brings us to a next point of having a RACI matrix to know who does what.

Have a RACI

It’s an all familiar [Responsible/Accountable/Consulted and Informed] matrix. Here is why we need it:

  • To identify who will be doing the smoke test of trial migration and catching any issues on key pages (landing, key areas, and department pages etc

  • Know who to contact when things need to be fixed or content retired

  • Understand who makes go/ no-go decision, and understands all aspects of the solution

  • Identify stakeholders to prioritize issues before migration to production

  • Know who will send communication to which users at various stages of the migration

  • Know who will support users who are unfamiliar with some new UI present on their pages

  • Identify staff and contractors supporting outages after hours or on a day 1 after the migration

  • Identify who will track task completion, or who's your project manager

Prioritize Issues

To some people an issue may not be an issue, and sometimes that’s a big issue :)

With the help of RACI you can determine key stakeholders who can help you drive what’s to be addressed right away or after Go-Live. If there are items on which your team can’t agree, use your Go /No-Go meeting to decide with [Accountable] stakeholders.

Keep track of the decisions for each issue discovered and what resolution should be. It will help you see what was done as you migrate from development environment to staging and finally to production.

Track Action Items

Migrations strictly rely on correct sequencing of events because they involve switching users from one production system to a new system.

If someone doesn’t complete their task or completes it partially, it’s likely to have a bearing on the next steps in the sequence. For example, if you decide not to set automatic link redirect to a new system, be sure to send an email communication about that as it may impact some users.

We recommend using Trello or Microsoft Planner to track activities and checklists, and move them from one bucket to another as they change their state.


Prepare Communication

Having adequate communication sent to users will set their expectations and significantly increase customer satisfaction. As a bonus, your users will feel that you care about their experience.

Depending on the size of your organization, you may want to message things via email, staff meetings or other methods. Chose the method so that no one misses your planned outage window.

Raise awareness of the upcoming change by sending initial communication first, in advance of the migration and more details closer to the migration.

Don’t forget the details:

  • What will happen (outage, system unavailability etc)

  • When will it happen (and for how long!)

  • What to expect after (redirect on some page, new login, new UI etc)

  • Who to contact if they have a problem (chose method which can handle larger than normal traffic)

Have a Go /No-Go Strategy

Schedule Go /No-Go decision early on to ensure everyone at the table is the right decision maker. It’s important to consider not just technical readiness but also change impact. Short notice change may introduce risk of wider outage so it’s key to chose your options wisely with the right people at the table.

Prepare to handle outages

Continuous testing helps but outages always happen.

This might sound obvious, but have technical resources allocated to work over the weekend or evenings surrounding the migration milestones. Even if you won’t need their help, it’s good to have a backup. It might be permission access to a file-share or incorrect login credentials that will stall entire migration. Same goes for users who will perform smoke test of the migrated system. Having the right people available at the right time is crucial.

We recommend developers and admins clear part of their day the morning following a successful migration to help address anything urgent as users report problems.

In summary

Technical aspects of a lift and shift migration are as important as change management parts of the process. Feel free to adapt some of the tactics above to your organization based on the size and culture. In many cases, you’ll be glad you clarified assumptions and avoided set-backs.

Leave your comments on what are some of the things you're curious about and we'll try to get an expert insight on the topic


Yaroslav Pentsarskyy is the Director of Product at Origami. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.