Finally moving your Enterprise Public Folders to the cloud? Understand protocols and options (spoiler alert! some are no more than wishful thinking)

If your first thought when you read this blog title, was “but do people still use Public Folders?”, the answer is YES!

Not only corporations still use Public Folders, but also they want to move them to the cloud and keep using them.

For the past year or two, working for a company that owns an outstanding migration product, MigrationWiz, I’ve seen a trend of large organizations worldwide getting to their final stages of the transition to the cloud. Usually, what that means in practical terms, is that they are addressing the more complex and harder to move or coexist workloads, which also translates to Public Folder migrations, amongst other things.

For many years Microsoft made it easy for Microsoft 365 users to access Public Folders on premises, and not that long ago they enabled on premises users to access Microsoft 365 Public Folders.

What Microsoft never supported, although it was technically possible, was two source of authorities for a Public Folder infrastructure, within a Hybrid Deployment. But all this flexibility pushed Public Folder migrations to the back of the “moving to the cloud” workload queue.

So now that we have a little bit of context on Public Folder migrations, lets address the options, when you decide to finally make the move.

How much data do you have to move?

From my experience, there are fundamental differences between two main types of migrations, you might be faced with. My first exercise, when trying to help a customer or a partner, plan their Public folder migration, is to determine if it’s a small or a large migration. Let me share with you where do a draw the line between both:

  • Small migrations: Migrations of up to 50GB of data, 1000 folders and 100k items
  • Large migrations: Anything above that

The main differences between a large and a small migration

Depending on the volume of data, or migration project can be simplified, or very complex. Here’s some bullet points on why:

  • Small migrations can easily be done with lift and shift protocols, like OA (Outlook Anywhere) or MRS (Mailbox Replication Service), however if you are looking at data transformation – this topic justifies a dedicated blog post, so won’t get into much detail on it here, but you can characterize migrating from Public Folders to Shared Mailboxes as an example of data transformation – and/or filtering or mapping the data differently from the source, you should use an EWS based migration product.
  • Small migrations do not require pre migration split work, to balance data between multiple destination mailboxes. In fact the lift and shit protocols do not require that.
  • Remember the wishful thinking mentioned on this blog title? Well trying to execute large migrations with lift and shift protocols, is exactly that. If you think you can migrate 2TB of Public folders with MRS, there’s no better way of saying this so I’ll just go for it: “YOU’RE WRONG”.
  • In addition to the above, large migrations also require pre migration work, that will basically focus on splitting the data into smaller chunks and pointing it to multiple target mailboxes, just so we never rely in the Microsoft auto splitting process for Public Folders.

Available protocols

Now that we outlined some of the biggest differences between large and small migrations, lets talk about the available protocols to migrate:

Outlook Anywhere

Outlook Anywhere is an old legacy protocol, that amongst other things, can be used to migrate Public Folders from Exchange 2010 to Exchange Online. But what are the main problems with Outlook Anywhere?

  • as stated above, the protocol is legacy and Microsoft actually stopped supporting it, in Exchange Online, back in 2017.
  • OA migrations are lift and shift and not feasible for large volumes of data
  • Setting up and/or troubleshooting OA can become complex really fast, in an Exchange version that is EOS since October 2020
  • Previous patching of the Exchange Server can be needed, before proceeding
  • Obviously it goes without saying but, OA does not support EXO (Exchange Online) as source

Mailbox Replication Service

MRS is a well established “migration-ish” protocol, that is very well know for it’s use in Hybrid migrations. For Exchange 2013+ that is the method used. Once again, where can things go wrong here?

  • With MRS, just like with OA, you’ll follow a lift and shift migration and face all the challenges that come with it, for large volumes of data
  • Being a lift and shift doesn’t only make it nearly impossible for some scenarios, it also makes it a non suitable option for mergers, acquisitions, hosted exchange and any scenario where you either have multi tenancy or you don’t want to target the entire Organization, in source or destination
  • The permissions the MRS requires can also be a road block, for the scenarios described in the bullet point above

Exchange Web Services

With Exchange Web Services the approach to migrate the data will be completely different. EWS will target each item in the source and create it in the destination (obviously this is done in batches of items). What that gives you is a whole bunch of options, such us:

  • When to migrate which data (folders, items) and to where (i.e PF to Shared mailboxes)
  • Split the source data to optimize speeds
  • Resume the migration from where it failed, when it does (believe me, at some point if your structure is huge, it will fail)
  • Migrate Terabytes of data
  • Scope source and destination permissions as needed
  • Target Public Folders in Hosted Exchange, per tenant
  • Migrate from Exchange Online

The bottom line

I hope that now that you read this, if you’re thinking about moving your decades old Public Folders into M365, at least you know the options you have.

There are pros to MRS (not so much to OA, to be honest), and if you have 5GB of PFs to migrate, an up to date Exchange with hybrid in place, then you can use it, but this blog post is focused in Enterprise customers, with hundreds of GBs or even TBs of data to move, and being very pragmatic, from my knowledge, that’s just not possible to do, with MRS.

Do let me know if you have any questions. Thank you for reading!