As Microsoft’s fastest-growing commercial product ever with more than 70 percent revenue growth in 2015, it’s clear that Office 365 is here to stay. Add to those impressive facts the ability to access familiar Office productivity tools with the ease of the cloud, it’s no wonder your organization has decided to make the leap to the Microsoft Cloud. But where do you start when it comes to your Office 365 migration project plan, and which path is best for you?
This post will review some best practices that will help you build out your Office 365 migration project plan. We’ll also share some options available to you when moving to the Microsoft Cloud, including how to get there easily according to your specific business needs.
Office 365 Migration Best Practices in Five Steps
A migration is a project that should be planned thoroughly and carefully. As you begin to plan your approach, a typical Office 365 migration project plan can be broken down into five key steps that each play a pivotal role in your overall success. I’ll cover each step below:
1. Office 365 Migration Project Plan: Discovery & Assessment
Know your environment! The discovery and assessment of the content in your environment is the foundation for your migration and crucial first step of the project. This phase gives you the opportunity to determine the data in your environment which is actively used as well as mission-critical content that needs to be migrated over to the new system. This is also the best time to take a look at the stale content throughout the environment and determine the appropriate manner to deal with it – whether that’s archiving or complete removal. The data you collect will help you properly plan your SharePoint co-existence strategy, information architecture, mappings, and content filtering necessary during the next phase.
2. Office 365 Migration Project Plan: Strategic Planning
After you’ve taken an inventory of all existing content and have a solid understanding of what you will be migrating, you can move on to the planning of the project. During this phase of your Office 365 migration project plan, you will take the information gathered during your discovery assessment and begin to plan your company’s future in the cloud.
The first thing you must do is determine how the organization will actually adopt Office 365. Are you going all in, or will you have a hybrid deployment? This answer is key to determining what stays on premises and what goes to the cloud. Some organizations may decide to leave business critical content and heavily customized business process solutions in the on-premises farm while moving collaboration workspaces and personal OneDrive containers to the cloud. Since Office 365 has a plethora of tools and unlimited OneDrive storage, you can take advantage of those features to enhance internal/external collaboration and lower storage costs.
On the other hand, some organizations have decided to take the plunge and fully adopt Office 365 across the organization – leaving nothing on premises. With easy-to-manage, low cost subscriptions; Microsoft handling all the heavy lifting for updates, patches, and upgrades; and the ability to work anywhere on any device, there is undeniable appeal in going fully into the cloud if you’re able.
Once you’ve determined your Office 365 migration project plan and strategy, you need to consider information architecture. You need to determine a few things in this step, such as:
- Will you restructure any of your existing architecture?
- What about Managed Metadata?
This step gives an opportunity to start off in Office 365 on a good foot by preparing for content and business rules to be followed across the environment. For example, you may choose to be a more site collection-centric organization to help with access and permissions management. In this example, you would need to move around and promote sites and sub-sites to become their own site collections in Office 365. You may also be adopting Managed Metadata in the destination to help with content organization and classification. In this case, you need to ensure you have mapped out your metadata terms and their purpose. This will come in handy when you set up your mappings in the next steps.
Once you’ve determined your strategy and information architecture, you can set up your Office 365 migration project plan. This step consists of setting up the mappings and content filtering that you will use during the migration. The baseline for this information was generated during the discovery and assessment phase, and content filters are added to ensure you are not bringing over items you no longer need – such as content that has not been accessed for some time or old versions of documents. You also need to consider user and/or domain mapping. With hybrid or all-in Office 365 deployments, proper user mapping is imperative to ensure content is migrated with the appropriate permissions and users don’t have any access issues when the new destination environment is ready.
After the Strategic Planning phase is complete you can move on to “smoke testing.”
3. Office 365 Migration Project Plan: Smoke Test
During this phase of your Office 365 migration project plan, you have the opportunity to:
- Migrate a small portion of content and verify the results
- Make any modifications based on your pilot migration output
- Do some quick testing of the plans and mapping created during the Planning and Assessment phase
You can also get an idea of what type of performance to expect throughout the migration and make the adjustments needed for optimal migration.
4. Office 365 Migration Project Plan: Migrate
Now you’ve reached the migration phase, and the proverbial heavy lifting can begin. Because you planned to execute your Office 365 migration project plan in batches, you can make adjustments to each batch if needed, causing only small delays. If you had not planned ahead of time and took the “‘close your eyes and pray to the SharePoint gods”’ approach, adjustments to the migration may have resulted in significant delays to the overall project timeline.
5. Office 365 Migration Project Plan: Validation and Remediation
Once the migration itself is over and you have breathed a heavy sigh of relief, it’s time for the last phase of the Office 365 migration project plan. You can now address any items altered or adjusted during the migration as well as finalize the destination content based on your information governance plan. You can also address sustainability items, including how to handle the old environment as well as how to assess and handle content growth in the future.
Common Technical Hurdles in your Office 365 Migration Project Plan
Since Office 365 is a multi-tenant service, Microsoft must limit the amount of API calls available to applications that interact with the platform to ensure performance does not degrade for other tenants on the service. Also, as the performance and responsiveness of Office 365 solely depends on the stability and available bandwidth of the network – the speed and data throughput during your migration is no different.
Microsoft imposes limitations on the number of Client Side Object Model (CSOM) calls a particular user can initiate on Office 365 within a given timeframe as well as the number of CSOM calls that can be initiated against a particular Office 365 tenant or SharePoint Online farm. This is referred to as user-based and tenant-based throttling, respectively. User-based throttling is a mechanism that ensures no single user or tenant is allowed to perform an excessive number of simultaneous requests and ensures the SharePoint Online farm does not become unhealthy due to excessive levels of activity. Along with the bandwidth limitations when copying content from on-premises environments to Office 365, these roadblocks could hinder any migration if not planned properly.
To help organizations moving to the cloud deal with this issue and migrate to the cloud faster than before, Microsoft introduced the Office 365 Migration API last year. To find out more about how we’re helping companies take advantage of the new API, check out my previous blog post.
Native Office 365 Migration Options
If you’re moving to Office 365 from SharePoint 2007 or SharePoint 2010, staging your migration to SharePoint 2013 is required. From there, a database attach is needed to complete the migration. This introduces several limitations, and an in-place upgrade is no longer supported for SharePoint 2013 because of the risks and complications that it introduced in previous versions.
The database attach method allows for you to upgrade only the environment’s content – not permissions or other settings. This method is faster than an in-place migration, as multiple databases can be upgraded in parallel, and multiple farms can be combined into one farm. This path also only supports the next version of the platform – so to upgrade from a SharePoint 2007 farm, you would need to first go to SharePoint 2010, and then finally to SharePoint 2013. Another factor that needs to be considered is that all content will be read-only for end users during the upgrade, which may or may not be acceptable to the business depending on the content you are migrating in your Office 365 migration project plan.
Database attach also requires that you create a web app in the new environment for every web app in the old environment. As an IT project, database attach will also take resources for organizations to identify where their customizations are deployed, what content is still business critical, and what the business expectations are for the source environment. For larger environments where there exists an organizational disconnect between the business and IT, this may be a costly, complex, and time-consuming exploration process. Finding out what it is that you want to move can be an even bigger project than actually moving it.
AvePoint Solutions for your Office 365 Migration Project Plan
To get around native limitations and ensure your Office 365 migration project plan is carried out efficiently according to your specific business needs, AvePoint is here to help. Our DocAve Migrators for SharePoint support all stages of your migration project – providing you with assessment, planning, and reporting capabilities – to efficiently migrate from previous versions of SharePoint or other legacy collaboration systems to Office 365 with minimal business disruption. With DocAve, you can:
- Simplify migration planning and execution: Easily inventory, plan, schedule, and migrate from more than 14 legacy sources directly to Office 365 – SharePoint Online and OneDrive for Business.
- Migrate to Office 365 at high speed: Move terabytes of content to Office 365 up to five times faster than before through integration with the SharePoint Online Migration API and Azure technology.
- Preserve data integrity: Full-fidelity migration ensures that all relevant metadata remains intact so you don’t lose valuable information moving to Office 365.
SharePoint migration is not just about moving content, databases, and sites to a new platform! It’s also an opportunity for the organization to support its operational vision through new technology as well as empower end users and stakeholders to get involved in the process. This is a good time to evaluate the organization’s entire environment to determine whether it’s working as effectively as intended when it was originally implemented. You can gain a better understanding of what’s working well and what needs to change. This will go a long way to driving user adoption and ensuring users love their new Office 365 environment.
Need more advice to ensure your Office 365 migration project plan is a success? For our strategy guide to unlocking the full potential of Office 365, be sure to check out AvePoint’s Cloud Arcade. You can also learn more about making the right decisions when choosing your cloud, on-premises, or hybrid deployment by watching our on demand webinar, AvePoint’s Cloud Arcade Presents: Mastering the Cloud Game.