Many organizations are looking to replace their legacy on-premises environments and platforms. This blog will highlight how to approach your SharePoint migration plan and review a few tried and tested actions to help you get started on your big move. It’ll also detail how you can successfully define your roadmap, strategy, and goals for a successful SharePoint migration.
Before we dive into how you can set up your pre-migration strategy and overall SharePoint migration plan, let’s first discuss the four big transitions you’ll have to consider.
The different approaches to cloud migration
Let’s review the four approaches for migrating to the cloud.
Cloud-only
- The Cloud-only approach is perfect for startups, as there is no need for a migration. Essentially, everything is created in the cloud using Microsoft 365 and Microsoft Azure. Think cloud and cloud-only. Anything on-premises is left behind.
Big Bang Transition
- The Big Bang approach is often considered the riskiest strategy, as it is the most aggressive and performed in the shortest time frame. Any content migration problems may not be resolved in time.
Group by Group Transition
- The Group by Group transition is the most organized migration strategy, as organizations can migrate by workload (email, OneDrive, SharePoint, Teams, etc.) or by business user group.
Iterative (Co-management)
- The Iterative transition helps build bridges between on-premises and online – also known as a hybrid setup. In many cases, this is the most complex and expensive path because it requires that two environments must coexist and be co-managed.
Choose the migration strategy that best suits your organization and your strategic objective. Next, you should plan your pre-migration tasks.
Gathering input from stakeholders
Many migrations fail not because of their technical limitations, but because basic concepts are fundamentally unacknowledged. As the SharePoint or Office 365 administrator or architect, you should gather input from stakeholders who will be impacted by the project:
- Don’t view the migration as an as-is migration and assume that everything will suddenly work without implementing any architectural changes. Check for deprecated or added features on the target platform. Be prepared to modify your topology. For example, SharePoint 2010 workflows will not run on SharePoint Online. You should contact the development teams and ask for their concerns about the migration.
- Review your custom solutions. Custom solutions can be extremely critical to your business owners; but may not be supported as is on the target platform. Review these concerns with the business owners of the custom solutions.
- Communicate with your champions and organize meetings. Assess what your business owners’ concerns and requirements are. They may have to make concessions in order to take advantage of what the new platform provides. They may also need time to prepare for the migration and the changes to their business processes.
- Understand the culture of the organization. Ideally, the business and business requirements should drive the technology, not the other way around. However, this is a good opportunity to demonstrate the new technologies available to support the business and evaluate if they meet the business requirements. For example, the migration project may be the right time to consolidate teamwork and communication onto one platform (e.g. Microsoft Teams).
- To know about the organization’s culture, collect feedback through surveys.
- Organize 1-on-1 champion/influencer/stakeholder interviews.
- Review SharePoint-related ticket history for at least 1 year back.
- Ask the help desk what the big issues are.
Review your current SharePoint on-premises environment
A key step to a successful SharePoint migration is knowing how your SharePoint environment is looking—hopefully, it’s not overloaded. Unfortunately, many organizations struggle with managing their legacy SharePoint on-premise environments.
The following should be addressed as part of the review.
1. Think about your present needs.
- How many users do you have? How many sites and site collections?
- What’s the average size of your database?
- What are the geographical needs of your organization?
- Are stand by terms familiar within the organization?
- How critical are these sites?
2. Think about your future needs.
- What will the size of your databases be in the future?
- What is the expected user growth?
- Is topology scalability a must for your next environment?
3. Are there any customizations that can be replaced by out-of-the-box capabilities?
- What kinds of customization do you have in the organization?
- How many do you have? Can they be replaced by OOTB features?
- Is there integration with other applications or complex workflows?
- Are there any custom master pages?
4. Time is money.
- How many waves do you have? (e.g. Pre-production, Qualify, DR, HA, if you are still on-premises.)
- How long do you have per wave?
- Are your wave priorities set depending on goals, vision, strategy, and roadmap?
5. Does your schedule include monitoring, identity federation, network optimizations, etc.?
6. Prepare a test scenario for your newly created environment.
- Ensure that everything is migrated successfully
- Run/test all workloads
- Including solutions – think full trust solutions
- Worst-case scenarios – think disaster recovery environment
- New capabilities and their integration – think Power Automate Flow, PowerApps
- New experiences – think collaboration with Microsoft Teams
- Check all user permissions
- Remove access to the old SharePoint environment and prepare to shut it down
7. Always remember that each SharePoint site should be “RTMified.”
- Remove
- Legacy files and unused sites.
- Unnecessary connections to third parties.
- Transform
- Get rid of legacy applications and use PowerApps, Flow, Planner, Delve, etc.
- Use out-of-the-box functionalities and capabilities when possible.
- Migrate
- SharePoint migrations can be complex and time-consuming, consider enlisting a third-party SharePoint online migration tool, as well as getting assistance with your Office 365 pre-migration analysis and management to ensure a smoother, faster migration process.
Create the strategy
Your SharePoint migration plan should contain 3 parts: the definition, vision, and goals.
Here is a real-world example:
Definition
- Migrate applications, files, and content from on-premises to Microsoft 365 and use modern online applications like Microsoft Teams for collaboration.
- Future application development will be supported online only.
Vision
- Organization X wants to improve their productivity and collaboration by providing the modern. workplace powered by Microsoft 365 and Microsoft Azure.
Goals
- Complete the migration in phases over 24 months.
- Reduce the on-premises services to zero.
As you can see, the example has a clear definition. We want to use modern collaboration solutions and plan for future development to be performed online.
Start building a more detailed roadmap that takes the strategy and adds high-level tasks (based on the migration approach you chose earlier) and sets timelines in order to meet the goals.
One solution. Many workloads.
Communication
We mentioned communication earlier as part of gathering input from stakeholders. Now it’s time to communicate back to the stakeholders. You will have to ask your stakeholders to validate the strategy and the roadmap. Communicate the following to your stakeholders using your existing communication methods (and consider trying the new communication methods when they are available):
- Communicate your strategy (definition, vision, and goals).
- Communicate your detailed roadmap.
Don’t:
- Communicate what you can’t produce.
- Communicate what’s out of scope.
- Communicate too fast.
Now it’s time to begin your SharePoint migration project.
SharePoint migration planning and preparation
Migrations aren’t easy. They require an understanding of legacy and new technologies and involve a lot of planning and communication with stakeholders.
In the end, it’s important to consider the following advice:
- Migrations are often phased and require flexibility. Technology should not be the key driver.
- Migrations are often iterative – requiring a need to iteratively plan, execute, and release. Your migration approach will determine how much iteration is required.
- Migrations are error-prone. Be prepared for errors due to differences in the source and target platform and supporting the migration of legacy content. In addition, each workload has its own challenges that can impact other workloads.
- Remember to inventory and define what will be removed, transformed, or modified.
- Communicate the changes early and often and communicate what’s coming next.
