Guide: Getting Started with Office 365 Migration Reporting
Need to free up your budget? Watch our webinar on-demand to learn how to “Save Money by Migrating More Workloads to Office 365!“
I often get asked, what are some of the key migration reporting tools we should consider for our upcoming migration project. While migration projects vary based on the source and destination environments, there are a number of general reporting capabilities that span across each type of migration project. To narrow things down a bit, reporting is generally organized across two dimensions: pre-migration reports and project-level migration reports.
Let’s start with the pre-migration reports. Migration discovery tools are used to perform basic usage patterns and environmental characteristics against your source environment. Many reports exist, including native administration tools, third party reporting scripts and the always handy PowerShell when dealing with the Microsoft ecosystem. We use the data collected through these reports to organize our sprint project methodology and look for outliers that may impede migration jobs and require further analysis.
What’s an outlier, you ask? Some examples include:
- A user that has 30% of all content
- A library that has a sudden massive influx of content in a short period of time
- Sites that are empty
- A document with thousands of versions
In other words, an outlier is anything that’s worth investigating further before migration activities take place. Having a clear understanding of the impact a date criteria has on your overall payload will help you make informed decisions on how this affects the amount of content planned to be migrated during each sprint.
Avoiding Migration Failures
Depending on your strategy for issue mitigation, some reports can also yield information on what content or environmental characteristics (think settings, customizations, incompatibilities between systems, etc.) may fail to migrate; especially if you are planning to migrate content across different systems or versions changes.
If performing a mail migration, focus on mailbox size to make sure that a source mailbox is within the size limits of the destination mailbox in Office 365.
When performing a legacy SharePoint migration, on the other hand, you may want to focus on customizations to further understand the approach you’ll need to take with transforming or remediating legacy customizations. (And while we’re on this topic, did you know that a library with custom columns that are of type MMS will fail to properly migrate until the site collection hosting the MMS has first been migrated? This is another reason to understand the data structure and topology before beginning any migration jobs.
And finally, if you happen to be migrating file share content, focus on URL length. While Microsoft has lowered restrictions on file types permitted to be migrated into Office 365, file path length issues is still the number one issue we see when performing these migrations (there are many other examples of pre-migration reports, but in the interest of time we’ll focus on this one).
Put plainly, don’t skip this step. It’s important and will go a long way in helping you better plan for and manage your upcoming migration project. As with everything else, the pre-migration reports are a collection of bits and bytes presented to you in different formats. Drawing conclusions and interpreting the message from the data is critical here.
Tools of the Trade
With pre-migration out of the way, you’ll need to start thinking about tools available to manage the migration process from an operational and project level.
Starting with operational reporting capabilities, we often recommend focusing on migration job reports as your first line of defense for ensuring that migration jobs have been executed successfully. Familiarize yourself with the structure and format of each job report by starting your migration project with either pilot migrations or small-scale migrations. I can’t emphasize this point enough. Fast-tracking dozens of migrations on day one will require you to be thoroughly versed with reading and parsing the information contained in the job reports. Partial or full job failure is to be expected for a variety of reasons and your ability to triage, determine a remediation plan, and execute reruns will represent a significant proportion of your time.
Having said that, some environments are less prone to errors than others, so prepare your operational process based on the complexity and size of your environment and any time restrictions you have on data migration activities. Depending on the size of your environment, reviewing each job report independently may work. Mining data through the migration job reporting database is also an option and one which AvePoint uses for large-scale migration projects.
Finally, preparing for a program-level reporting framework is your last area of focus. Start by asking your project team what information they are interested in seeing during the course of the migration project. Since migrations aren’t a frequent project that your team will have experience with, don’t be surprised if they don’t have a standard reporting framework to lean onto. Here are some examples of information that we find useful:
- Status of completed, in-progress and scheduled content sources. If you’re migrating mailboxes, this information should be organized by account. If you’re migrating SharePoint sites, this information can either be organized by the site collection name, the division or site owner that owns the site, or any other organizational metadata used to describe this content source.New to O365 migration reporting? Check out this guide: Click To Tweet
- Revisions to projected migration cutover schedule and overall project timelines. Your timeline will need to be frequently reviewed based on past job performance as a function of total payload and remaining content yet to be migrated. Unless you’re doing a one-time full migration with no incrementals, expect a lot of questions on how the current progress and forecasted schedule compares to original projections. Remember that a lot of people are counting on your team to migrate their content and alert them when it’s time to cut over to the new platform. Make sure to give yourself plenty of room to project this information to your end users to avoid any last-minute surprises.
- A List of users that are or will be scheduled to be included in an upcoming cutover for communication purposes.
- Quality. Issues that are being addressed by the migration team versus issues that cannot be handled by the migration product or migration team and must be brought to the attention of the business users or project team for further analysis.
- General statistics. At a minimum, include statistics like job success rate, object success rates, throttling events, speed profiles, etc.
We recommend that you establish a consistent reporting framework to use when working with your extended project team (e.g. PowerPoint, Word updates, Excel spreadsheets, SharePoint lists, etc.). We favor capturing the information in SharePoint lists and feeding this information into a series of PowerBi reports which abstract the data update process from the presentation process.
However, if you are more comfortable with PowerPoint or Excel, then that’s the platform that will work for you. Remember that you are using the reporting data to deliver a message to your constituents. The reports themselves wont deliver the message and are a byproduct of data collected during the course of the project. The migration team will be looking for you to summarize the information and help the team understand its meaning.
