Kirk Liemohn is a Principal Software Engineer at ThreeWill. He has over 20 years of software development experience with most of that time spent in software consulting.
Introduction to Migrating to Office 365
To get started, we’ll look at a couple of questions that you should address when migrating to Office 365. The first is to look at your organization and assess whether you’re prepared to do the migration successfully. The next thing we address is whether to automate the migration and/or use migration tools. Next, we’ll cover is to break the migration out into discrete phases – we describe the phases and provide guidance on what happens during each phase. A key proven step that should not be skipped is including a pilot for the project – this gives you a chance to send “water through the pipes” for the entire migration process and address any issues/risks. Issues will come up. The next step is to plan how you are going to triage issues. Next thing we’ll discuss is defining the support process for the migration. We’ve learned through the years that having an archive strategy can be a key component to keeping a cap on the budget and the overall migration time. Finally, we’ll cover where and when to use offshore resources for migration projects.
Editor’s Note – We originally developed this guide just for targeting complex SharePoint online migrations, so many of the technical aspects of this guide are related to SharePoint. We are taking this content in a more holistic view based on what we are doing with customers including migrating content into not just SharePoint online, but also Microsoft Teams, Yammer, and products that are a part of the Office 365 suite.
Ready to get started? Let’s jump into discussing your organizational preparedness for the upcoming migration.
Step One – Is Your Organization Prepared?
Is your organization prepared to do a migration to Office 365? There are a lot of considerations. Many of them are outlined in the rest of this guide, but here a few related to organizational preparedness:
- Experience – Has your organization performed large-scale migrations with any platforms in the past? If so, you have some valuable experiences to draw upon. If you’ve done SharePoint migrations the most analogous experience may be comparing a SharePoint 2010 to SharePoint 2013 migration to a SharePoint 2013 to SharePoint 2016 migration. Keep in mind that migrating to SharePoint Online has several important differences when compared to migrations involving on-prem SharePoint for the source and target, so be careful not to over-state your experience.
- Skilled Resource Availability – Does your organization have the people required to handle a large and complex migration? Skilled individuals are necessary from the core technical migration team through project management, helpdesk, and communications. Also, some migrations require doing a lot of work in a relatively short amount of time. Having enough skilled resources during that time may be a challenge.
- Helpdesk/Support Preparedness – Do you have a ticketing system for migration support? Can the system handle the increased volume that may occur with a large-scale migration? Do you have the individuals behind the system (Level 1, 2, and 3 support) that can handle the increased load? Do they have SharePoint skills?
- Communications – There are several questions to consider regarding communications within your organization. How does your organization deal with mass communications? Do you have a complicated or restrictive approval process? Does your company culture foster the type of communication that will be necessary for site owners and users? Do you have a good understanding of how to communicate with users and site owners? Communications is arguably one of the most important aspects of a migration, so these questions should not be taken lightly.
- Compute Resource Availability – With a large migration, it may require a lot of computing resources to physically move the bits from one environment to another. This is highly dependent on the method of migration. For example, using CSOM (Client-side Object Model) to copy content from SharePoint on-prem to SharePoint Online requires a lot more computing resources than the database attach approach that can be done when you are moving from one on-prem farm to another. Local severs can be used regardless of the approach, but with moves to SharePoint Online, it may make more sense to use Azure virtual machines as it can be physically closer to the SharePoint Online datacenters.
- Time – Is there a required timeline for completing the migration? Is the timeline reasonable given all the steps that need to be performed during the migration? Review “Step Three – Break the Process into Stages” for more details on what steps to consider.
- Senior Executive Advocates – is the migration supported by senior executives within the company? Are they aware of some of the tradeoffs that will need to occur as part of the migration? Do they understand enough of the complexity to defend decisions made in the Policy Document? Will they defend timeline and scope that are reasonable given the nature of the migration? Without having support from C-level individuals, the migration may be at risk of being canceled or put on hold.
Step Two – Should You Automate?
Another key question to tackle is how to perform the physical migration. Are you using a migration tool? Are you manually configuring the tool? Should you automate the process?
Answering these questions depends on several factors:
- What method do you plan on using to migrate? Migrations to SharePoint Online cannot use a database attach, so a migration tool is required for all but the smallest of migrations. A site collection backup/restore is also out of the question.
- Are many site collections undergoing a “lift and shift” approach where there are few high-touch changes required? These are more likely to be candidates for automation.
- Is the overall number of site collections very large (hundreds or thousands)? Having many site collections can be tedious to keep with using just a migration tool, so automation may help. However, the effort involved for automating may not have enough ROI unless there are a very large number of site collections.
- Do you have use cases that are not covered by migration tools? Automating those use cases through a custom effort may be beneficial if the use case is pervasive enough. Depending on the scenario, the custom logic may run before, during, or after the migration is executed by the migration tool.
Step Three – Break the Process into Stages
Any large or complex migration needs to have a process in place for managing the migration. ThreeWill breaks up our migration process into four stages:
In the Assessment stage, we work with the client to understand the high-level migration needs. We like to do this in a workshop where we devote some focused time over a few days to gain a better understanding of what is needed. This may take the form of a couple of full-day sessions or several half-day sessions.
During the Assessment stage, we review the overall vision and strategy for the migration and discuss the scope of the migration. Then we develop a high-level plan for the migration including tasks, resources, and tools required to complete the migration. We break the plan into a high-level Product Backlog. From this, we can identify an estimated budget and schedule for the migration.
For more details on terms such as “Product Backlog” and for an overview on how ThreeWill runs our projects, see ThreeWill Approach.
During the workshop, we also discuss the current state and desired future state including key future state capabilities as well as project risks. The output of the workshop is a baseline of the Migration Project Charter which includes:
- SharePoint Vision, Strategy, Objectives, and Critical Success Factors
- Migration Approach and Plan (Roadmap)
- Resource Plan
- Migration Schedule
- Initial Risk Assessment
- Initial Communication Plan
- Estimated Budget for Migration
Failure to plan is planning to fail.
It sounds trite, but with large and complex migrations it is very true. You need to plan with a detailed approach to be successful. It’s no coincidence that the Plan portion of the process is the largest subject. We break this stage into the following components:
A big part of the plan is understanding what is being migrated, so we need to create an inventory. At a high level, the inventory includes:
- Site collections
- Customizations (e.g., custom branding or web parts)
- 3rd party products (e.g., Nintex Workflow)
- Integrations with Other Systems (e.g., BCS connections)
- Users and user permissions
There are a lot of details that can go into the inventory for each site collection such as the site collection administrators (useful for communications), quota used (size), time zone, language, running/configured workflows, views that exceed the list view threshold, and many more. Information considered critical to the migration is used to create a complexity score for each site collection which can be used to help schedule the migration as well as understand the effort involved. If your inventory is accessible to site owners, it can also be used to show the status of the site’s migration.
Tools are available to aid with creating an inventory:
- Microsoft’s inventory, planning, and reporting tool: Microsoft Assessment and Planning Toolkit.
- Many migration tool vendors have an inventory tool as well.
After the inventory is cataloged, the mapping can be done. The most obvious mapping exercise is mapping the source site collections to the target site collections. Sometimes this is a “lift and shift” exercise where the mapping is little more than a URL change. Other times the mapping can be more involved (e.g., mapping a single site collection into multiple site collections). The Archive Strategy can play a big part in this as well, where some of the source content is archived and not migrated.
There are several other types of mapping to consider as well, including:
- Mapping source and target site templates – when moving to a different version of SharePoint (e.g., SharePoint 2013 to SharePoint Online) some site templates in use in the source environment may not exist in the new environment.
- Mapping users – if you are not moving from one user directory to another, this is not necessary. However, when moving from on-prem to online, you will likely need to map windows accounts to Office 365 accounts. This may require feeding a tool with mapping data or a mapping transformation script (for an example from one tool, you can read more on Metalogix Content Matrix transformations here).
- Mapping customizations/integrations – another aspect of “mapping” is determining how to handle customizations, 3rd party integrations, and custom requirements. Some may or may not be supported in the new environment. Once cataloged, each case should be examined. If required, proof of concepts (POC) should be put in the plan to address any unknowns.
Note: If you are moving from SharePoint on-prem to SharePoint Online, mapping customizations and integrations is a critical exercise. Many of these will not move over easily. Full Trust Code (FTC) is not supported in SharePoint Online and many home-grown and 3rd party integrations rely on FTC. Migrating each application that uses FTC is a project by itself. FTC applications must be re-architected to use the Cloud Add-in (or “App”) Model (CAM) if you want to migrate them to SharePoint Online. Site owners must be given lead time to convert their applications if needed, so early communication is important.
Even if FTC is not used, there can be complications moving custom applications. There are even issues migrating custom applications built on SharePoint when moving from one on-prem version to another on-prem version. For example, the REST API changed significantly between SharePoint 2010 and SharePoint 2013.
After the mapping exercise is well underway, patterns can be found on how to do the migration. Efficiencies may be gained by automating based on those patterns. For example, if you are migrating many site collections in a “lift and shift” manner, you can automate the migration of those site collections using custom code and a migration tool. Even for those cases where custom automation is not warranted, you may need to plan for testing various methods of migration to determine which will work best for you.
POCs were mentioned for mapping customizations and integrations. They can also be beneficial for testing critical use cases with the migration tool. If not already decided during the Assessment stage, the migration tool (or tools/utilities) is usually determined during the Plan stage. All migration tools are not created equal and source/target environments play a critical role in what is and are not supported by the tool. For example, do you need running workflows migrated? What about external users? There are a lot of scenarios to consider especially when changing versions of SharePoint or hosting environments.
Finally, during the Plan stage, significant effort must be devoted to communications. What is going to be communicated, to and by whom will it be communicated, and when will it be communicated? How and when are pilot site owners contacted? See Communication for more details. Make sure you allow for ample time to create the appropriate communication documents during this stage.
The output of the Plan stage includes the plan itself. We do this in the form of a more detailed Product Backlog broken out into Sprints with a timeline. See ThreeWill Approach for more details. Other updates include:
- Custom requirements
- An update to the communication plan
- An update to the Migration Project Charter
The Verify stage starts with several activities including:
- Performing POCs outlined in the Plan stage.
- Writing and testing any custom migration code/scripts.
- Testing critical use cases with the migration tool.
- Refining the communication plan and updating documentation as needed.
- Ensuring support and triage processes are in place
After those activities are complete and pilot owners are ready, the pilot process can begin. This is discussed in greater detail in Step Four – Always Include a Pilot.
Results from the pilot(s) and from other tests are fed back into the plan. The scope may need to be adjusted based on findings. The plan and Migration Project Charter are adjusted accordingly. This could involve a change to the timeline or scope.
The Execute stage is when the real migration is done. Content is moved by manually configuring the migration tool or through automation. Issues are triaged and handled with the support process. Sites are cut over to the new environment. Other sites are archived. Incremental migrations are performed as needed. Communication is provided to all parties as planned.
Note: Surprises during the Execute stage are going to happen. If enough time was not given to the Verify stage, then the chances of surprises having an impact on the project are more likely. These may require adjustment to scope and/or budget during the Execute stage.
Finally, at the end of the migration, the migration project itself is transitioned to a sustainment team.
Step Four – Communication is Critical
Communication is a critical part of all projects, but it is particularly important for migrations. There are several parties we need to communicate with including users, site owners, support personnel, IT, and upper management. Without proper preparation, the communication to these parties may be too little, too late, or nonexistent. Setting aside enough time to consider how you are going to handle communications is key.
With large migrations, more of the preparation tends to be delegated to Site Owners since the IT organization many times does not have the bandwidth to deal with individual sites or site collections. In these cases, you’ll want to have several artifacts that can be used by site owners as well as some artifacts for end users or support personnel:
- Policy Document – describes what the migration supports and more importantly, what it does not support. It should describe who the policy applies to such as Site Owners and what actions should be taken by those individuals. An example might be that in a migration from SP 2013 on-prem to SharePoint Online you are not supporting farm solutions. In this case, you might instruct Site Owners to come up with a plan to move off of farm solutions for their sites and execute on that plan before the migration date for each site they own.
- Run Book – contains a migration checklist of steps to take before and after a migration of a site or set of sites. This checklist may have actions to take based on items in the Policy Document. For example, the new environment may have stricter list view thresholds, so Site Owners may be asked to make sure that their large lists are properly indexed. After migration, a Site Owner may need to do validation or perform manual steps that the migration does not cover.
- Self Help – provides documentation for end users and can alleviate the load on support personnel. This could involve understanding the changes in the new environment and how to make corrections on migration issues that are known to occur in some situations. An example article could be correcting web part configuration that may not transfer over completely during migration.
- Knowledgebase – provides technical documentation for helpdesk and support personnel on how to correct issues that are known to occur in some circumstances. An example article could be around how to deal with custom master page issues.
Not only is the content of the communication important, but the timing is also important. Well before the migration, the policies and run book should be provided to Site Owners to give them enough time to take the necessary steps to be prepared for the migration. For example, if Site Owners are responsible for re-architecting farm solution applications into applications that will work in SharePoint Online, they will need time to make that happen. They also may need to be able to reschedule migration to a different time based on business needs.
In addition to early communications, you will want timely communications such as reminder emails to go out to site owners or all users of a site or banners displayed on the sites at a time. Banners can be effective as they can cover all active users of a site. Email can also be effective if you know the users of a site (i.e., the site does not give access to All Authenticated Users) but may include users that no longer use the site. Much of this can be automated for migrations that involve many sites. In addition, the effectiveness of both emails and banners can be measured in terms of who has opened/viewed them.
Depending on the technique and tool used, some sites cannot be migrated overnight or even over a weekend. In those cases, and for other reasons, you may want to allow the source and target site to be available at the same time and perform incremental migrations until it can be cut over and the old site can be shut down.
The timeline below shows an example of how these communications can occur over time.
There are other types of communication as well. The helpdesk and support teams need to be ready for the migration. They need a clear understanding of their role and what to expect. Depending on the number of users affected, a robust ticketing system may be needed.
Finally, communication with upper management and key stakeholders is crucial for a successful migration. Without proper buy-in from these individuals on the reasons for doing the migration and the overall ROI, it may be hard to have backing for funding and company-wide communications.
In Summary, having a communication plan that considers the complexity of what to communicate and when to communicate it is a key component to a successful migration. Having clear ownership for the overall communication plan is important as well.
Step Five – Always Include a Pilot
A pilot involves getting a set of users and sites to agree to be part of the early adopters to move to the new environment – or at least to test moving to the new environment. Ideally, this group of individuals is a good cross-section of the organization and can be flexible while you work through the kinks in the migration process.
The pilot process for migrations is intended to test the “water through the pipes” of the entire process. This clearly needs to involve migrating various types of sites in your organization, but it also needs to test communications, support processes, and issue remediation processes.
With end-to-end tests of these processes, issues found during pilot can be addressed before large-scale production migrations occur. Otherwise, issues are found when the spigots are fully open and it can be hard to update your processes if helpdesk and issue remediation is consuming a lot of bandwidth.
The pilot process can tell you how effective you are with your communications. Are your policies and run book and sufficient for your Site Owners? Are the users able to use your self-help documentation? Is your support organization able to use the knowledgebase documentation? Are banner and email communications effective?
Tip: Don’t confuse initial test migrations with the pilot. Before any pilots, you will want to perform test or proof of concept (POC) migrations of content to validate that the migration tool can successfully move data from the source environment to the target environment. During these tests, you may uncover some gaps in what the tool can do for some specific sites or test cases in your organization. These test migrations can also be used to validate any automation or customizations you are putting in place around the migration tool. These tests are done in the Plan and/or Verify stages of the project.
Once the initial testing is done, the pilot process can further vet your migration tool and any automation. Ideally, the number of pilot sites is large enough that you expand the variability beyond the initial testing and learn about more improvements for your content migration process.
In addition to testing different types of sites and content, the pilot should include actual users to review the results of the migration. Their feedback is crucial as they represent all of the individuals that use the system after it is migrated. You need to make sure the pilot participants are willing and able to provide feedback in a timely manner. It is very easy for those users to get caught up in their daily activities and not take the time to pitch in. Getting feedback too late from pilot participants can impact the schedule.
After content is migrated, the pilot process helps uncover holes in your support and issue remediation process. Is your ticketing system ready for migration? Does your helpdesk or first line of support have proper instructions on how to handle incoming issues? Can they properly hand off issues to Tier 2 or 3 support? Your triage process will likely be improved during the pilot. New types of issues may be discovered and techniques for handling them either proactively (maybe through automation or manual tweaks in the process) or after-the-fact.
With large and complex migrations, each one is unique. The pilot process can help answer and resolve many issues that show up in migrations in a more controlled way. For more complex migrations, running at least 2 pilots is suggested, but early planning is key to allow for the time to prepare for the pilots and make course corrections with information gathered during them. Without including the entire process during the pilots, the value will be limited to only those aspects of the process that are in the pilots, adding risk to those parts of the processes that are not being exercised until full-on production migration.
Step Six – Have a Plan for Triaging Issues
Triage typically refers to sorting or prioritizing patients in need of medical care. For migrations, we are referring to the process of sorting and prioritizing issues that occur during the migration process.
There are plenty of issues that can occur with large and complex migrations, so you want to have a way of processing these issues that don’t overwhelm the team supporting the migration. Early testing can give you an understanding of many, but not all issues. Running Pilots will help even more. Some issues may be reported by the migration tool or automated checks, but others may only be found through visual inspection.
Ideally, many of the issues found during testing and pilots are later prevented by modifying the migration process. Some examples of this could be:
- Using the migration tool to map missing users to a service account and communicating via the Policy Document that migrating user accounts for terminated or inactive individual accounts is not supported.
- Migrating very large sites using a more measured approach – maybe migrating one subsite or library at a time instead of the whole site collection at once.
- Writing scripts to overcome deficiencies in the tool for your given scenario. Maybe the tool does not properly configure information management policies or some obscure feature in SharePoint that is a critical use case for your organization.
Even if you can overcome many issues proactively, you may find that you need to have a process for handling them after-the-fact as well. If you are migrating enough content, an automated triage system may be warranted. This system can be used to check for migration issues and compare them to known issues – we call them Issue Definitions. The Issue Definitions can prioritize the issue and assist in assigning the issue (i.e., to a site owner, tier 1 support, tier 2 support, etc.). It can also describe how to fix the issue by referencing Knowledgebase articles. Alternatively, it may indicate that solving this issue is not supported as discussed in the Policy Document.
The POCs may give insight to some initial Issue Definitions, but during the pilot processes, the Issue Definitions really start to take shape. It is during those pilots that the automated triage system is refined and improved as new issues come in that don’t match up to existing Issue Definitions. This feedback loop is important and can even be continued during production migration.
The objective of triage in migration scenarios is to identify and classify typical and unique challenges, issues, or anomalies that exist in a specific environment. In small migrations, the objective may simply be to enable prioritization of help desk calls. In massive migrations, the triage can assist in informing the other components of the migration that may impact the business; e.g. issues that impact revenue or customer facing resources.
Step Seven – Define the Support Process
A large migration requires a well-defined support process that has been communicated and tested thoroughly, beginning with the Pilot testing. The support process must in all cases complete in-incident resolution and address the following issues:
- Inputs from multiple sources: As discussed in Step Five, some issues can be discovered by the migration tool or by the internal migration team. Other issues will be reported by site owners and users through a service desk or other communication methods.
- Closed documentation feedback loop: As incidents are resolved, support documentation (knowledgebase, self-help, policies, run books) should be reviewed and updated as needed. This ensures future incidents can be resolved more efficiently and opportunities to improve the migration process are more easily identifiable.
- Escalation path: In efforts to resolve incidents, support resources will need a process to raise issues with migration engineers, developers and other team members. This requires a well-defined escalation path with a return to support process.
- Clear path to resolution: All support processes for incident management should have a clear path to incident resolution, minimizing opportunities for issues to go unresolved.
Here is a simplified flow diagram on how the support process may look. Larger migrations will need to have a ticketing system and may want to use the corporate help-desk system if one is already in place.
Step Eight – Use an Archive Strategy
If there is a lot of content to migrate, an archive strategy can be a key component to keeping a cap on the budget and the overall migration time. The general idea is to archive content that is no longer needed or actively used and only migrate content that is needed going forward. This can reduce clutter in the newer environment and can vastly reduce the migration effort and schedule if enough content is archived.
The first step is to determine the guidelines or rules for what will be archived or deleted instead of being migrated. Some factors that may influence this decision include:
- Recent activity (or lack thereof)
- Amount of content – e.g., a team site may be created and no significant content was ever added or a user created a blog site, created 1 or 2 posts, and then stopped updating the content
- Known business circumstances – e.g., divisions that have spun off or teams that no longer exist
- Compliance reasons – governance, eDiscovery, audit, etc.
You will also want to decide on the granularity of what is archived or deleted (e.g., site collection, subsite, library). Once the factors are agreed upon, this can be fed into the Inventory and mapping exercises as discussed in Step Three.
The next step is to determine how to archive the content. Third-party migration and archive tools are one option for this. If SharePoint is on-prem, you may also want to consider site collection backups or content database backups. Keep in mind that depending on the approach the backup may not contain everything that is used by a SharePoint site such as farm solutions or files stored on the SharePoint server file system (aka, the “SharePoint Hive”).
For all content that is archived, you will want to have a strategy in place to restore that content if it is needed at a future date. Keep in mind that some content (such as the aforementioned farm solutions and server files) may require extra attention. The steps required to handle the restore process should be understood by those maintaining the environment(s).
An alternative to an archive strategy that still reduces the number of migrated sites is to consider a hybrid environment where some content remains available on the old farm until its end-of-life. This may make sense for farm solutions that have a limited lifespan when moving from SharePoint on-prem to SharePoint Online, or for business solutions or applications that have a limited lifetime or ROI.
When choosing a hybrid solution, consider integrations that may be useful to assist when going across multiple farms for navigation, searching, and profiles. There are plenty of articles on a hybrid strategy with SharePoint, especially with regards to a hybrid between SharePoint on-pre and SharePoint Online. One place to start is here.
Step Nine – Using Offshore Resources
With a large and complex migration, the amount of time and effort to complete a migration can be quite extensive. To reduce some of the costs, offshore resources may be a good option. Some areas to consider help from offshore resources include:
- Tooling – if your migration is large and complex enough to warrant custom tooling, such as the automation of a migration tool and/or custom scripts as part of the migration, then some of this effort can be offloaded to offshore resources. Usually, the requirements for the tooling can be clearly specified which helps when working with an offshore team.
- Triage – as issues are discovered by the migration team during testing, pilot, and production, the issues need to be mapped to Issue Definitions (see Step Five) and those Issue Definitions need to be defined, prioritized, and there may need to be an action plan for them as well. The action plan may include updating documentation (see Step Four) or improving any configuration or automation scripts to help prevent the occurrence of this issue. Since the issues that are encountered in a migration can be as varied as the content being migrated, researching and documenting each issue can be extremely costly, some of which can be offset with a little offshore help.
- Support – as issues are discovered by users during pilot or production migration, the issues may be initially processed by level 1 support. However, level 1 support may not be knowledgeable in SharePoint so those issues may need to be escalated to level 2 which hopefully understands SharePoint. Unfortunately, many enterprises won’t have the bandwidth for level 2 support during a large migration, so an offshore team could complement an existing level 2 support team and use the Knowledgebase (see Step Four) to assist with that effort. If level 2 support is having trouble they may escalate it to level 3 support which may involve the core migration team (see Step Six).
Time zone differences can be challenging with offshore resources. India Standard Time (IST), for example, is 9 1/2 hours ahead of Eastern Daylight Time (EDT) and 10 1/2 hours ahead of Eastern Standard Time (EST). It is even worse for other US time zones. However, the time difference can be used to your advantage as well.
During pilot migrations, and especially during production migrations, the care and feeding of the migration process can be done during off-hours. If your organization is primarily in one region (e.g., the US), then you may want to do much of the migration during off hours to avoid downtime for the sites or to avoid incremental migrations. Babysitting the migration or performing triage during this time may be beneficial and may be well suited for an offshore team. Their time zone may also be better suited to provide level 2 support for some regions outside of your core region (e.g., Europe).
Using an offshore team can be valuable. However, using them must be weighed against the additional overhead of using another team that may not know your business, maybe on a different time zone, and may have some communication challenges. At ThreeWill, we will often include an option to use offshore resources when we think that this will help to meet the client’s restraints (typically time and cost). Although, we factor in the risks involved and include some overhead for managing the team (clear and constant communication is essential).
Conclusion and Next Steps
You’ve now got a better understanding of the steps required for a successful Office 365 migration. Notice how important the approach is to the migration and how many steps are about reducing risk (for example, doing a pilot first to test out all your processes). Let’s take a final look of each of the steps.
- Is Your Organization Prepared? Evaluate your internal experience, availability, and resources required for the migration.
- Should You Automate? Research automation options based on factors like whether you’re doing a “lift and shift” and the number of site collections that need to be migrated.
- Break the Process into Stages – We’ve identified 8 distinct phases – Assess, Plan, Inventory, Map, Streamline, Communicate, Verify and Execute.
- Communicate, Communicate, Communicate
- Always Include a Pilot – This is a non-negotiable if you want to be successful.
- Have a Plan for Triaging Issues – Issues will come up. Design an appropriate Triage Plan to handle them when they do.
- Well-Defined Support Process – You’ll need to handle input from multiple sources, document resolutions to incidents, and have a clear path to resolution of incidents.
- Use an Archive Strategy – An archive strategy can be a key component to keeping a cap on the budget and the overall migration time.
- Using Offshore Resources – Certain activities are appropriate for offshore resources when migrating large and complex SharePoint environments. You need to weigh the risk and overhead in managing these teams against the benefits of increased velocity and lower costs.
If you’re embarking on a large and complex SharePoint migration and looking for a partner to help you pull this off successfully, please learn more about SharePoint Migration service offering – https://threewill.com/services/sharepoint-migrations/. We also have niche expertise on two particular types of complex migrations – both Jive to SharePoint migrations (https://threewill.com/services/jive-to-sharepoint-migrations/) and Dedicated to Multi-Tenant SharePoint migrations (https://threewill.com/services/dedicated-to-multitenant-migrations/). If you’re in a time crunch and ready to get an estimate for help with a migration, please take our pre-migration questionnaire – https://threewill.com/next-steps/pre-migration-questionnaire/. Thank you for taking the time to read this eBook.