Public Folders to Groups Migration
Public folders have been around since the dawn of Exchange and despite being “de-emphasized” for over 10 years now, getting rid of them has proved to be challenging. One of the reasons why organizations are still using public folders to date is because no viable replacement was offered. The initial guidance suggested SharePoint as a replacement, but this proved to be unpopular, as the functionality fell short in some areas, like usability (especially for mail-centric content), and many users found that the process for migrating was labor intensive, and overcomplicated. Despite the problems that plagued public folder deployments, and the lack of any new functionalities, many organizations were in too deep: they had sprawling public folder hierarchies, and their processes and workflows relied on them heavily. Migrating to an alternative, when the system was still functioning, and did not desperately need replacing, was not exactly appealing.
Things changed a bit with the introduction of Modern Public Folders, and their availability in Exchange Online. Initially no migration path was offered, but Microsoft went on to provide tools to migrate legacy and modern public folders to the cloud, or configure cross-premises access. The migration method is fairly complicated as it has somewhat restrictive requirements, and relies heavily on PowerShell scripts and CSV files. Another important factor to consider is the “all or nothing” approach used by the migration process, which can feel extremely drastic and unnecessary. When it comes to public folder migration, you probably don’t need to move everything, and the Microsoft tool doesn’t help to identify or filter redundant data that does not need to be migrated, and could be removed.
With the advent of new modalities, such as Office 365 Groups, Microsoft is now offering a different option to migrate your public folder content. Namely, they just introduced the public folder to Office 365 Groups migration. Obviously, not every public folder can be replaced with an Office 365 Group, and luckily the new migration method does not follow the “all or nothing” approach, instead allowing you to select which public folders to migrate. Let see how this process works.
Steps to perform the migration
Unfortunately, no UI tools are provided to govern the migration process from modern public folders to Office 365 Groups, and you have to use PowerShell scripts and CSV files. In addition to this, no tools are provided to analyze the contents of public folders either, which is important considering the migration only supports mail and calendar items. This means that the task of ensuring the selected source public folder is compliant with the migration process is left to you.
The target Office 365 Group objects are not automatically provisioned, so you will need to create these beforehand. Once you have the list of source public folders compatible with the requirements, and the list of target Office 365 groups, you will need to prepare a CSV file detailing the FolderPath, and TargetGroupMailbox values.
Once the CSV file(s) are prepared, the familiar New-MigrationBatch cmdlet is used to queue MRS move requests. As no incremental sync is supported, if you need to run another pass in order to cover any newly created items in the source public folder, you will have to remove and recreate the migration batch. On the positive side, since the same functionality used to migrate mailboxes is also used to migrate public folder content, once the batch is created you can monitor it via the Exchange Admin Center (EAC).
The last step in the migration process is to “lock” the source public folder by stripping all permissions, mail-disabling them, and transferring the SMTP aliases to the corresponding Office 365 Group. If you want to make sure that the same set of users will have access to the migrated content, you can run an additional PowerShell script that will “translate” the ACL entries, and add the corresponding users as either Members or Owners of the target Office 365 Group.
Where the migration process falls short
The migration process leaves a lot to be desired in terms of automation, but overall the steps to perform the actual migration are not that hard. On the other hand, finding the right source for public folders can be a challenging task. It is highly recommended to conduct a proper analysis of the public folder hierarchy as the first step in any migration project. This can help you to make sure that you identify the appropriate targets for your data, but also help clean up unused folders and surface potential issues.
Both modern (including Exchange Online) and legacy public folders are supported for migration. The lack of options for the target object however is a limiting factor – while Office 365 Groups offer a lot of functionality, they are not a suitable replacement for all scenarios. The fact that the target Office 365 Groups are not automatically provisioned is also disappointing.
Some other issues with the migration process are apparent. As already mentioned in the previous section, no incremental sync is supported, and if this is needed, then the migration batch needs to be recreated. In addition, the target Office 365 Group can only be referenced once in the CSV file, so if you want to migrate multiple source public folders of the same type to the same target, you need to create multiple migration batches. This means that if you’re aiming to “collapse” your public folder hierarchy, additional runs will be required. Similarly, a source public folder can only be migrated to one target Office 365 Group.
Are Groups a good target for public folders migration?
Just because this functionality is available doesn’t mean it’s necessarily the right move: it’s important to consider is whether Office 365 Groups are a suitable destination for your public folder content. The method described above only supports calendar and mail public folders, and it is not applicable for other types. For example, using a public folder for creating a company-wide repository for contacts is a common use, but one that cannot be recreated in Groups. Even for public folder types that are supported, a careful evaluation must be performed in order to make sure the Office 365 Group can be used as a viable replacement.
For users that are familiar with the hierarchical structure of public folders, the switch to Groups might take some getting used to. Moreover, Office 365 Groups only expose the Inbox folder of the underlying mailbox, which might be a problem for some scenarios. For example, even though spam processing is enabled for Group mailboxes by default, there is no functionality to access items that might end up in the Junk email folder. Similar issues exist around the Sent Items and Deleted Items folders, and even Clutter. Other features such as Inbox rules, or support for storing, and using Forms are also not available with Groups.
The Groups permission model is another thing to consider. While the self-service capabilities are akin those found in public folders, the “equal access” that all members of the Group share can be problematic in some scenarios, especially when it comes to the “conversation” part. For public Groups, everyone in the company will be able to access the content, and even delete files stored in the Group library, which is another thing to be wary of.
Per-user read status is another feature users might miss with the switch to Groups. The conversation style is also not configurable for Groups. The lack of ‘drag & drop’ support for copying/moving items can be off-putting as well, although there are certain workarounds you can use (and Microsoft has promised to deliver support for it soon). As mentioned above, handling sent and deleted items can also prove challenging, and in some cases using a Shared mailbox instead of Groups might be a better option.
Despite some restrictions and differences in capabilities, there are also some use cases where Groups would be an adequate replacement, and can even bring more functionality compared to public folders. Every scenario involving document handling for example would benefit from using the Group library and all the collaboration features available. It would have been a nice touch if file attachments were automatically copied directly to the Group library during the migration, but the Files view in OWA offers a somewhat acceptable alternative.
It is always good to see Microsoft acknowledging a customer issue that has been around for some time, and remains a prevalent obstacle for many organization’s journey into the cloud. To maximize the benefit of Office 365, enterprises must do more than simply move their legacy data, they need to be able to fully consolidate legacy systems with the new features and services available to them.
When we launched Public Folder Shuttle in September 2016, we saw that there were two sides to a successful public folder migration: the need to analyze, understand, and clean up legacy public folder data ahead of migration, and then the need to apply intelligence and automation to streamline the process itself. This is particularly true for larger enterprises who have accumulated huge volumes of legacy public folder data, and do not have the capacity to rely on script-based methods, or manual analysis of the suitability of their content for their target.