Discussion in the last Blog Post was all about "Analysis" and in this post I wanted to move onto what I call the next step.
"Rationalization" or if you want to take a less technical and esotertic approach the "Rules by which we will plan and run our migration"
This is one of those phases in a migration where the better understanding of the organization rules, roles and compliance will keep you on track.
I like to think that a successful migration is when you move the pertinent data in a timely manner with no loss or requests for more data.
A lot of folks will just take the approach that if I move everything then I don't risk an issue. This would be akin to always moving to a bigger house
because you were afraid to get rid of anything. Unfortunately for many of us we have seen this in our environments, my experience is that this is
called Exchange Public Folders. Not to mention many of you have retention and compliance guidelines that this type of migration would violate.
So what are these rules and where do they come from?
From the initial "Analysis" phase of the project you should have a good understanding of both the Source and Target environments.
This understanding will lead you to the Questions and Decisions that make up a successful "Rationalization" phase of your project.
- If the Source has custom templates, site definitions or branding.
- Will you have customizations in the Target environment?
- How will you map the Source to the Target customizations?
- Are Source customizations replaced by Native Target Features?
- If the Source has no customizations but the Target will be branded or customized.
- How will you map to these new components?
- What timeframe does this add to the migration plan?
- What is the best practice?
- Data Retention
- Does the organization have a Data Retention Policy?
- Does it include SharePoint?
- Is it possible to identify one type of data from another?
- Compliance or Regulations
- Are you part of a manage industry or vertical?
- Data clasifications based on type or law
- Version History
- Does your Governance policy allow for versions?
- Is version history unmanaged or out of control?
- Will the target environment have version control and policies enabled?
- Old and Unused
- What classifies unused or underused data?
- Do you need to move provisioned but unused sites?
- What is the Target Environment
- Office 365
- What version
- SharePoint Foundation
- SharePoint 2010 Standard
- SharePoint 2010 Enterprise
- Which Features will you be using
- When will those Features be utilized
- Are you moving up or down versions
- Up version is approached as Feature Parity
- Down version is risky and will add issues to the migration
- Governance and Change Control Process
- Are there any limitations on the window for migrations
- What is the change control process?
- Is there one?
- When is the backup(s) scheduled?
- What is the window for completion
- Are you currently indexing for Search?
- What is the schedule?
- Can it be delayed or suspended?
While this is not a complete list of questions for the "Rationalization" phase of the project you should be getting the point.
Each of the answers to questions like these is going to affect not only how much data you are required to migrate, but how
much of the data and layout can be left behind. Also note that this is not only about data but timelines for migration as well,
which can and will affect how you plan and migrate your data.
In the next entry I will be discussing putting together the "Analysis" and "Rationalization" phases to drive your "Discovery"