I wonder whether John Speare, one of Microsoft’s Senior Technical Writers, was overjoyed when he received the assignment to document the options that exist to move Exchange Public Folders to Office 365 in the form of a white paper that you can download from Microsoft’s web site.
On the surface this was an easy task because the answer is simple: there is no way to migrate Public Folders to Office 365 because Office 365 does not support Public Folders. However, taking this approach would have meant that the white paper was very short, maybe a title page, Microsoft copyright notices, table of contents, and a blunt statement along the lines of “Sorry, you’re out of luck if you expect to migrate all the folders and data that you’ve lovingly accumulated for years to our brand spanking-new all-singing all-dancing cloud platform.” All done and dusted in four pages, many trees around the planet saved, and printer manufacturer stock dropping because ink supplies are not consumed.
But Microsoft doesn’t do blunt. At least, it doesn’t when it has to dance around the sensitive and potentially-deployment blocking issue that Public Folders represents for Office 365. Today, Public Folders is one of three major issues that block migrations for many companies who run on-premises Exchange as they consider their future plans. The other two are lack of support for Outlook 2003 and BlackBerry. The latter should be solved soon (see Brian Winstead's article on the topic); the former won’t be ever supported but at least there’s an obvious solution (deploy Outlook 2007 or Outlook 2010).
So there’s a big need to lay out a coherent case for customers to reassure them that Microsoft has their best interests at heart and won’t leave Public Folders to rot. To be fair, some system Public Folders are obsoleted by Exchange 2010 because data such as the Offline Address Book (OAB) and free/busy information can be distributed through web distribution rather than accessed from a public folder. Outlook 2007 and Outlook 2010 can both use this method but Outlook 2003 can’t, so that’s one of the major reasons why Outlook 2003 will never darken the doors of Office 365.
Things get more difficult with non-system Public Folders. To understand why we have to go back through the mists of time to Exchange 4.0 when Microsoft presented Public Folders (or public fora as they were sometimes known) as the basis for organization-wide collaboration and sharing. Great things were promised: get data close to users through replication; build applications using the Electronic Forms Designer (EFD); remove information from user mailboxes and share it across the world, and so on. Even though it has been tweaked and improved, replication still works today pretty well as it did in 1996. EFD ended up as a dead-end street because it was a 16-bit application that was never upgraded. But users did share information with each other through Public Folders and did so for many different reasons that continue to add real value to companies today.
The question for folders that hold shared user data is twofold. Can we move the data to another repository that is equally easy to access and is there any associated function apart from simple access that we need to use with the data? Some companies use Public Folders as repositories for forms that are completed to authorize different things; some have simple workflow applications; some use Public Folders as dumping grounds for information that is kept “just in case”.
Microsoft’s white paper emphasizes SharePoint Online as a potential repository to replace Public Folders. Given that we do not have a seamless migration facility incorporated into Exchange that is capable of moving everything without operator intervention, it’s important to realize that any migration to SharePoint Online requires substantial effort from someone with knowledge of three different skills:
- What purpose the Public Folders serve, who uses the data, and how they access the data
- How Public Folders work in Exchange (whatever version you run)
- How to develop applications in SharePoint Online (or SharePoint 2010 if you plan to remain on-premises) – this might be anything from a simple list to something more complicated that requires InfoPath forms
Even equipped with such an array of knowledge the migration won’t be easy, unless you have just a few folders and nothing complicated. In all cases, it’s a good idea to ask the question whether you need any, all, or some of the Public Folders that are used today on the basis that some folders might have been created for a purpose long since forgotten, some have fallen into disuse, some have been bypassed by events, and some simply don’t contain anything of value. The aim here is to eliminate as much of the migration workload as early as possible during the project.
And if you despair because you have too many Public Folders to even know where best to start, you can always look for some external help. Companies who offer software that might help include Quest Software (Public Folder Migrator for SharePoint) and AvePoint (DocAve Public Folder Migrator for SharePoint). There are probably others and it’s a good idea to do the research and lots of testing before making any commitment to purchase. Attending an Exchange-related conference that has a trade show attached such as DevConnections or TechEd is a good way to meet lots of different companies in a short period of time as well as being able to share experiences and ideas with people who work with Exchange.
John Speare did the best job he could with content presented in the Microsoft white paper on moving Public Folders from Exchange to SharePoint Online. It’s not a panacea by any means but at least it starts the conversation before the topic becomes something that kills a potential move to Office 365.
