I’m in the middle of a series on how to build and deploy successful SharePoint document management applications, with the goal of migrating end-users off of the most prevalent legacy document management system out there: that unholy trinity of shared drives, hard drives, and email.
In this post, we’ll dive deeper into migration planning, one of the most challenging parts of the process.
To that end, in the first three posts I’ve been walking through a process that, while by no means a silver bullet, in my experience will give you a better chance of success than the typical approaches, e.g., if you build it, they will come.
- Process mapping
- Process triage
- Process redesign
- Capabilities mapping
- System design and testing
- Migration planning
- Communication and training
- Go live
We’ve covered steps one through five in the first three posts, and that’s the place to start if you haven’t already done so.
#6. Migration Planning
If you’ve been reading the first few posts in this series and thinking to yourself, “man, nobody does all that work when they deploy SharePoint,” you’d be right: very few organizations take the time to do SharePoint the right way. Heck, very few of them take the time to do big ECM the right way, and those are multi-million dollar enterprise platforms that require system integrators to even get up and running…so SharePoint never stood a chance.
But compared to the efforts put into migration planning, the typical SharePoint development looks like an IEEE best practices case study. Only one of two things happen when organizations start up SharePoint: users bring nothing over or users bring everything over.
Needless to say, both of these are terrible outcomes for your SharePoint program.
To avoid them, you need to put in the time and effort to understand your users’ content from a number of different perspectives in order to determine what, if any, needs to be migrated to SharePoint and how:
- End user -- what content is of highest value to them, i.e., used frequently, supports their main processes or operations, etc.?
- Compliance -- what content poses the highest compliance risk, i.e., is required under penalty of law to be maintained, is critical to supporting compliance operations, mitigates the risk of being found non-compliant, etc.?
- IT -- what content is the most burdensome to support, i.e., largest files, infrequently accessed, extremely aged, etc.?
- Records Management -- what content is past its retention requirements?
- Legal -- what content is part of active (or impending) legal holds?
Once you’ve gotten an assessment of the content from these angles, you can begin to formulate a migration plan, the foundation of which is a protocol statement that sets the ground rules of how decisions about moving content will be made. For example:
Content will be migrated if it is
- required to be retained for active (or impending) legal holds
- required to be retained to comply with the records retention schedule
- required for regulatory compliance
- critical for business operations
You can also express the ground rules negatively, i.e., when content will not be migrated:
Learning Opportunities
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
Webinar
Apr
13
Accelerating Content Velocity Across the Digital Supply Chain
Learn to integrate DAM with upstream tools to improve workflow efficiency.
Webinar
Apr
13
Composable Commerce The Future of Retail
The Adobe Commerce approach to composable and why it's best in class
Webinar
Apr
18
Drive Business Growth Through Customer Service and Support
Defining the future of technology. What is AI’s role in the future of customer service?
Webinar
Apr
26
Future-proofing Your Marketing Through Better Customer Understanding
Understanding your customers and how to reach them in real-time across all channels
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
Content will be not migrated if it is not
- subject to active (or impending) legal holds
- required to be retained to comply with the records retention schedule
- required for regulatory compliance
- critical for business operations/has not been accessed in the last X time period (1 year, 2 years, 10 years, etc.)
Once the ground rules are in place and all the relevant stakeholders have agreed to play by them, you can sketch out what migration will look like for each group of users you bring onto SharePoint, which will be some combination of tried and true migration techniques:
- Bring over Tier 1, mission critical content and delete from shared drive
- Leave Tier 2 in place read only, and track levels of access to promote some to Tier 1 (and then migrate), demote some to Tier 3, and leave some at Tier 2
- Move Tier 3 to cheaper (e.g., off line, lower availability, etc.) storage
- Purge Tier 4
The Final Word
As you might suspect, the reality will get much messier than my description of the process, and at times you will feel like one of the personal organizers on Hoarders, standing in a sea of junk, holding up a 10-year-old cocktail napkin, asking timidly if we can throw it out, and having the hoarder refuse to get rid of it, begin to have a panic attack, and ask you to leave.
But you have no other option -- so stick with it. If you can get all the relevant stakeholders involved and facilitate properly, you’ll get past the initial roadblocks and arrive at a migration plan that, while not 100% for any one group, will be the best fit for the organization as a whole.
Next post we’ll wrap up with everybody’s favorite redheaded stepchildren: training and communication (along with some discussion of go live thrown in for good measure).
In the meantime, as always, I’d love to hear your thoughts on the process I’ve sketched out so far, your experiences with SharePoint development, or your own thoughts on how to get SharePoint right -- jump in, and let’s get the conversation started.
Title image courtesy of David Koscheck (Shutterstock).
Editor's Note: You may also be interested in reading:
