Migration Planning: On-premises to Cloud


With cloud computing becoming ever-more prevalent and increasing proof that storing your files in the cloud provides greater security, with far less up-keep whilst vastly improving your ability to collaborate, many companies are looking to make the switch.

When choosing to make the switch, it is important to consider a variety of things to make the transition as smooth as possible for your employees. For the purpose of this article, we will focus on a simple content migration scenario from a SharePoint on Premise (2016 classic experience) to SharePoint Online (Modern Experience); however, the principles outlined in this article will work for other versions of SharePoint, and even for migration from other systems such as file servers, or other intranet / document management solutions.

Before deciding the tools, you may want to use for job, you need to ask yourself some questions and put a plan in place. Key questions you may want to ask before migrating are:

1. What type of release do you want to implement?

a. Phased

b. Cut off

2. What files go where?

3. Do all files need to be migrated?

4. Do you still need access to files on the old system?

5. Do permissions need to be migrated?

6. What content do you want to migrate?

Next steps

Tips and Tricks

What type of release do you want to implement?

When making a transition between solutions, you need to determine how you want to roll out the change to your users. 2 common release scenarios are phased / parallel and cut off.

A phased / parallel approach is where you have both your SharePoint on Premise and SharePoint Online systems being utilised simultaneously but in a controlled manner. For example, you may wish to migrate only a department at a time to SharePoint Online. This will minimise impact to the overall business if something goes wrong but increases the amount of time and planning involved in coordinating the ‘phases’ in which users move to the new system. This type of approach can be useful for large businesses, as migrating such many files in a short time period is infeasible.

A cut off or ‘big bang’ approach is where once all files have been migrated, the business decides for all users to begin using the new system at the same time whilst deprecating the old system. This can either be communicated throughout the business, or by turning off / revoking access to the old system. This approach can work well, but involves a much larger amount of up-front planning, and can have an increased risk, especially for large businesses. This approach is recommended for smaller businesses, who either have a small number of files to migrate, or a small number of employees.

What files go where?

With your approach decided upon, you now need to determine which files from your source, go to which location on to your destination. This can be done by creating a ‘migration mapping’ sheet. This can be a simple Excel document, which holds reference to content on your source location, to its corresponding destination on your Online site.

Depending on the current state of how your files are stored, the granularity of your migration mapping sheet can vary. For example, if you are happy with the current structure that files are stored in, you may want to simply map sites to sites (Site A to Site B). However, if you file structure is currently not in a good way, now can be the perfect opportunity to tidy things up. If this is the case, you could create a mapping sheet which goes to the library or folder level. For example, you may have a folder on the HR site, which you feel may be best placed in a new location on the Finance site, you can represent this within your mapping sheet, meaning the structure on your mapping sheet will represent the migrated structure.

If your new SharePoint Online tenancy does not yet have a Modern Site structure architecture in place, it might be worth while planning how you want your new intranet to be structure, then mapping the files from your old SharePoint, to the new one. The same can be said here for permissions.

Do all files need to be migrated?

This is an important question. Many clients have asked for us to migrate all their data over to SharePoint online, however a large percentage of it may be legacy data that could instead be archived offline or discarded. The benefit to this is 2-fold, the first being that minimising the amount of files / data you have on your tenancy generally results in a much tidier tenancy which is far easier to maintain, and the next being that taking the opportunity to analyse what data you currently have allows you to remain compliant. If there is no business reason for holding on to records, which could potentially hold sensitive data, why do it?

This feeds directly into the next question:

Do you still need access to files on the old system?

If you have decided that you do not want to migrate all your files, as they are no longer business critical and can be archived, will you need to access them regularly? You may want to keep your old system up and running for a period after the migration, in case files are missed from the migration, or you decide that files that were previously archived are now needed. This isn’t a required step in your migration, but is a worth while thought to have in the back of your mind.

Do permissions need migrating?

If the permissions set up is complex on your on-premises tenancy, you need to think about whether all of them need to be migrated across to your new SharePoint Online tenancy. Again, it is worthwhile, if you are thinking of migrating permissions, to include these in your mapping sheet. It could also be a good opportunity to re-think your current permissions structure for that of a simpler implementation.

What content do you want to migrate?

This question can encompass a few of the above, but SharePoint is not just a file storage platform, other things exist on the platform that you may want to migrate such as:

· Workflows

· Webparts

· Pages

and much more. It is worth while thinking of these things as you may have internal processes that rely on some of the above. From experience, it is often better to put a plan in place to rebuild some of these things such as workflows into PowerAutomate, and certain webparts to SPFx modules (if they do not have a direct mapping to SharePoint out of the box modules).

What next?

Hopefully some of the above has given you some ideas on how you can get to planning your migration. From experience, I have found that the planning phase of a migration is actually just as important as the migration itself – but with all your plans in place, what next?

Choosing a tool for the job is the next natural step in migrating your files and content between systems. Here at AMT, we have used a variety of tools, but my 2 favourites are:

· The SharePoint Migration Tool

· ShareGate

The SharePoint migration tool is a free piece of software provided by Microsoft that allows you to perform basic content migrations. It works very consistently and has an easy-to-use interface. However, for large data migration with complex permissions, structures, and file sizes, I would recommend ShareGate.

ShareGate is a paid for ‘Industrial’ migration tool. Whenever I have used it I have been impressed with their analysis tools, error handling and support resources. The tool is expensive, so I would only recommend it for cases where migrations are large, complex, and potentially involve migrations or large permissions structures and page contents.

Both tools are incredibly easy to use, providing a simple user interface which is as simple as signing in to both your source and destination tenancies, and pointing which location you wish to migrate the files to. No 2 migrations are the same, so I recommend putting in place some proper research, hopefully utilising some of the advice above, to help you conclude on the best approach to migrating what you have.

Tips and Tricks

This might sound like an obvious one, but proper analysis before hand saves so much time when migrating. All the tools in the world can help you decipher what approach you need to take, but nothing so far has beaten taking a little bit of time and looking at the current infrastructure manually.

Don’t ‘bulk’ migrate. Whichever tool you end up using, don’t just migrate all libraries from all sites, to the source site(s) in one go. It makes picking out any errors very difficult. If you have created your mapping sheet, migrate a library, or a site at a time. This will allow you to tackle problems as they arise, and potentially prevent additional issues further down the line.

If you need any help on your migration journey, from consultancy, to helping conduct the migration in a controlled way, please contact AMT Evolve, we will be happy to help.