Tim Coalson is a Senior Consultant in the Delivery Practice at ThreeWill. Tim has been developing solutions on the SharePoint platform for over 15 years and has been a developer/consultant for over 30 years. Tim’s current focus is on helping organizations thrive by delivering the Intelligent Intranet and Teams Enablement service offerings. Also, Tim develops integrated business solutions using Power Apps and Power Automate (aka Flow) which are part of the Microsoft no code/low code solutions.
Introduction
On a recent project, I kept hearing the term “Content Rationalization” thrown around. I knew what that term meant to me, and ThreeWill has done a podcast about the topic but wasn’t sure that my understanding of the term matched the definition of all stakeholders involved in projects. So, I begin to ask around to make sure we were all working off the same understanding when we used the term in reference to data migration. The content below is the result of that collaboration.
Definition
At a high level, Content Rationalization is determining which data is being migrated to the target location for that content. There are several things that can have a major impact. Is this a SharePoint to SharePoint migration or some other similar platform migration (i.e. Unily to Unily) where the source and target content (i.e. document types) are going to closely match? Is this new platform intended to only be fresh, new content or does it also act as an archive repository for old data? Are there multiple target locations involved in the data migration where some data might get migrated to SharePoint and other data to a Microsoft Team? Depending upon the requirements for the new platform or the use cases for the data being migrated, the requirements or criteria for the data being migrated might change.
This post will not be exhaustive but will hopefully prompt some thought when data migration is being considered.
Questions to consider:
Which sites are in-scope to be migrated?
If the data in this site hasn’t been modified in the last year or two, should I consider it to be stale? Or is this relatively static data that is not updated but still is valuable for viewing? Without physically looking at each site, is there metadata such as created or modified dates or analytics about the site (last viewed, number of views) that can be used to programmatically determine the relevance of an existing site as it relates to data migration? In the end, site owners should be able to make an argument for their site being migrated, but it’s good to be able to get a general scope of the migration using some form of automation.
Where will this data get migrated?
Is this collaborative data that is centered around a project or a team? If so, something like Microsoft Teams may make the most sense. Or, is it more general, company information that might make more sense in an Intranet portal? For data to be migrated, target location(s) need to be specifically defined, and depending upon the granularity of the migration, specific libraries or repositories within those target sites may need to be specified.
What types of data will be migrated?
Are there some types of data that will not have much value in the new environment? Will social metadata (i.e., comments and likes) on the data in the current environment be relevant in the target environment? Are there some types of data in the current environment that don’t really map well to the new target environment?
What document type should house my data?
For each type of data that is targeted to be migrated (i.e. news, announcements, events, etc.), what will the object or document type be in the target location? If you are migrating between two different platforms (i.e., Jive to SharePoint), there will not always be a corresponding object in the target platform that exactly correlates to the objects in the source platform. So, decisions will need to be made as to whether this data should be migrated and to what document type or object it should be migrated. And, of course, these document types may have platform-specific functionality tied to them which will impact the decision
What data should be migrated?
Should I migrate all data from my current platform or are some of this data obsolete? Should I only migrate data that was created or updated in the last year or two or do I need all of it? Should the same data criteria be applied to all data or should different criteria be applied to different types of contents (i.e., keep announcements for the last 6 months but documents for the last 2 years)?
What should I do with data that is not migrated?
Is there auditing or legal requirements that require I save this data in some form that allows it to be retrieved at a later date? What are the requirements? Does it have to be “real-time” access or can it be stored and managed by a “librarian” where access to the information will be gained through a manual request?
Conclusion
As mentioned above, I’m sure this list is not exhaustive but I believe it is a good start as you consider your migration. Migrations are always a bit messy so don’t get too frustrated. There are always compromises that have to be made and not everyone will be happy. Just understand that is the nature of migrations and make the best decisions that will best further the goals of those leading the data migration effort.
To learn more about ThreeWill cloud migration offerings visit Cloud Migrations
CONTACT US TO LEARN HOW WE CAN ASSIST IN YOUR TECHNOLOGY INITIATIVES!
