This article originally appeared on
AvePoint.
Every year more and more organisations are set to embark on a cloud migration journey. It can be a daunting process for those who’ve never made the move before, especially when it comes to keeping data safe throughout. Here’s advice on how to navigate the three core steps in a compliant migration: Assess, Move, and Verify.
Assess
The first step is to figure out what you have and who it belongs to. Visualising all of this can be helpful not only for you, but for the rest of your team and any third-parties as well. Consider plotting out answers to questions such as:
- How old is the data?
- What data do you want to bring?
- Who are the primary data owners for the files you plan to migrate?
- Are there policies within your organisation that say you’re only allowed to keep data for a certain amount of time (common in the healthcare and financial sectors)?
Being able to pull these layers apart and find the answers to each of these questions is key. Gone are the days of
massive file shares where data sat untouched for years. If you have any such large datasets that need to be moved to the cloud, your best option is to go in and apply classification tags to every piece of content. This way, you’ll know which content is certified as good to go and what needs to be left behind or moved to another location.
Going in and scanning the content layer is critical to a compliant migration. Though it might take longer than “lifting and shifting” all of your content at once and evaluating it afterward, going file-by-file and seeing what content’s there at the outset is a much safer proposition.
Another thing to keep an eye on are permissions; are they inherited? If certain document libraries and subsites don’t inherit permissions from the parent libraries and sites, those are red flags. That means that that site acted as a private site to whatever Team it fell under.
If your VP of Marketing only has access to a subsite in a Marketing site collection, and she’s only sharing permissions with a Marketing manager, no one else sees that site or has access to it. So whenever they’re doing in that site needs to be kept separate from everyone else. Evaluating what permissions to carry over is a huge factor in protecting sensitive data.
Assess the Data
After you assess, it’s time to nail down your migration approach. Will you migrate by department or business unit? How much notice will you give employees? Do you have a designated
Office 365 champion who’s rallying everyone to get excited about the move? The sooner you let your users know that the company is transitioning to the cloud and the sooner you can get your champion spreading the gospel of Office 365, the better.
Depending on the type of organisation you work for, a compliant migration might require that certain data be kept separate from the rest. This ultimately depends on the type of data you’re working with. Evaluate the following:
- What’s inside of the files that you’re moving?
- Who created them?
- Where were they originally located?
- How sensitive are they?
If you’re looking at an Intranet that’s public to all, it’s okay to keep public. What you have to keep an eye out for are the very particular areas where only certain individuals are working. It wouldn’t make sense, for instance, to move the conversations of C-level executives to a public SharePoint site; you’d want to keep that data siloed out.
So, during the move, it’s important to verify what the permissions look like across your organisation’s environments before the migration and what they’ll look like afterward. Be sure to verify, assess, and address what content is there.
Finally, though it’s often underprioritised, you want to verify that all of your organisation’s content was moved and all of the permissions are intact. If you’re working with a third-party to migrate your data, all it takes is one file to be missing for the whole migration project to get called into question. People will begin casting doubt and asking questions like, “Was all of our content really moved over? What actually happened? Why are we missing files?”
Oftentimes, however, files aren’t missing; they’re simply part of the content that was designated to be left behind. Because of this, thorough reporting before and after your migration is essential. Some of our customers use
Power BI dashboards to filter down through business levels, file owners, file age, and more. All of this information can be useful in determining if you need to keep something.
If keeping anything older than five years puts you at risk, for instance, it’s vital to outline that during the planning phase and take note of it so there’s no confusion afterward. If legal says certain data can’t move, it must be left (and documented as such). And by tracking everything through reporting, verifying who had access to sensitive data before and after the migration is a cinch.
Remember, your migration is setting the stage for what you’re going to do for the rest of your life in Office 365. This may very well be the last migration you do for a long time. It’s bad data in, bad data out. Instead of shoving everything into the cloud with a shrug and saying, “What’s the worst that could happen?” make time to prune your organisation’s data what you have and then move it. By setting standards around data lifecycle management, you’ll mitigate much of the risk we all want to avoid.
For more information on compliant migration, please
get in touch!
