Creating a SharePoint Migration Plan (Part 1 of 2)

Home   |  ECI Blog   |  Data Series   |  Creating a SharePoint Migration Plan (Part 1 of 2)
Author Alex MathewsRoss Posted on

For SharePoint Online

(Introduction)

Beginning a SharePoint Migration project can be a daunting undertaking.  Do you start with a site design or you design the sites as you go?  Unfortunately – it often usually requires a mix of both.  This post aims to help you create an iterative plan for migrating content to SharePoint Online.

 

1.      Planning

The key to any migration is making sure all activities are defined and scheduled as early as possible. This also means we need to allow time in our plan for delays, repeats and sifting – all activities that we do not necessarily want to occur – but need to plan for.

Performing an inventory audit will help identify all the stale content within your existing sources and decide whether to move, archive or remove it completely.

A key activity to mitigate the risk of these delays is to involve stakeholders as early as possible – and get them to analyze their content prior to the migration activities beginning.

This will usually be best done within one or more workbooks – which will become an important tool later for validating the migration.

Tips

  • Try using the PowerShell “Get-ChildItem” cmdlet recursively to map out files within a Shared Drive
  • The “GetWeb” cmdlet will actually allow us to get any content with a URL – and save it to a temporary folder
  • The temporary folder can then be bulk uploaded to SharePoint

 

2.      Design

Make sure you limit how much design effort at this stage.  A SharePoint site should ALWAYS adjust its functionality to match its content.

However, once you understand the categories of – you can start planning separate document libraries for each category.  Categories could include types of content (Agendas, Manuals, User Guides, Meeting Minutes, etc.) or format types (Word/PDF/Excel).

For each set of related categories – we will need to create a separate site.  The site structure will also account for your organization structure.

All migrations can be done manually – but this make take some time.  Check out the following tools for helping speed things up:

Tips

  • A simple criteria for creating a SharePoint site is determining audiences.
  • Instead of working out who requires access to the content – determine what groups require access to what content (work backwards).

 

3.      Iterate

The easiest way to reduce errors, bugs and issues in your migration is to “slice” the migration content into numerous cycles.  The benefits to this are 2-fold.  It will allow you to prove your migrations methods and add any improvements that arise.  Also, it will reduce the possibility of trivial bugs causing widespread errors across multiple sites.

Another great benefit to the regular, staggered migration cycles is that it allows time for stakeholders to validate the migration.  This is made a lot easier with smaller batches of content each cycle.

Tips

  • When trying to determine with stakeholders what should make up each migration cycle – it can be best to separate content by the frequency it is used
  • Documents used each week go first – then used monthly, used annually and so on.
  • Create a “Migration Tracker” spreadsheet for measuring progress and tracking bugs

 

4.      Review

Once the content is migrated it is important to ask two questions to each of your stakeholders:

  1. Is all your content migrated?
  2. What could we change to make your content more usable?

SharePoint is all about making documents and knowledge more accessible and collaborative for your end users.  Due to the hands-on nature of migration projects, they produce some of the most informed requirements your stakeholders will offer up.

Use this as an opportunity to revisit any design decisions and create a road map for your SharePoint platform.

Tips

  • Use the “Migration Tracker” above to help organize the stakeholder review/validation of the migration
  • Measure the frequency of bugs – and improve your migration methods accordingly.
  • Your migration tracker will also help predict an end date
  • Create a backlog of tasks for future enhancements – rather than making ad-hoc design changes during migration

 

Advanced Topics for Future Blogs:

  1. Automation with PowerShell
  2. If you have a PowerShell Guru at your disposal
    (you can try using the cmdlets to help speed up the process)
  3. Migrating Web Parts
  4. Migrating Page content from existing SharePoint sites
  5. Migrating Wikis from another Content Management system
PREVIOUS
NEXT