Back to blog

Email migration to Office 365: Part 5 – Interdependencies and data elimination

Mar 8, 2017 by Emma Robinson

This post is part of an eight-part series looking at the key components of email migration to Office 365.

Previously, we’ve explored the reasons why Office 365 email migration would be right for your organisation, the common mistakes made during a migration, and the technical considerations you should be aware of before you start.

Most recently we discussed managing your data volume, and in this post we’re focusing on interdependencies and data elimination.

Managing logic and interdependencies

Email is a corporate record. Before beginning any migration, you need to ensure fundamental audit trails can be preserved, together with clear chain-of-custody (chronological documentation), and that specific roles and policies can be defined to control administrator access. Similarly, retaining data access throughout the project – so normal business isn’t interrupted – is vital.

Most email users regularly access not only the live mail server, but also archives, public folders and local files stored in PST format. Shortcuts and ‘stubs’ between them need to be preserved as far as possible, in order to avoid disruption.

Office 365 does not recognise existing shortcuts to Enterprise Vault archives. If you’re considering virtual desktop infrastructures (VDI) based on Microsoft’s Azure cloud platform, it’s vital you’re aware that running Office 365 with tools such as Azure RemoteApp won’t work with PST mailboxes or old EV shortcuts.

As such, it is important to carefully consider and plan for these factors before your migration begins, otherwise they can cause a whole array of issues and complications during the process.

How do I ensure I don’t break the existing logic and interdependencies within my system?

You should be able to reconcile mailbox accounts against individual, named users (if users have left the company, you still need to be able to archive and retrieve their emails) and in the first post of this series we touched on the necessity of tracking down rogue PT files. This exercise should be carried out early in the planning stage to provide an insight into the scale of any problem and understand how it can best be addressed.

What should I do with our archives?

When possible, there are various cost and performance benefits to migrating your email archive straight into Office 365. With generous storage available and ways to archive leavers’ mailboxes at no additional cost – not to mention the option to centralise all your data into one accessible system – Office 365 certainly provides a tempting feature-set for those looking to move their archive out of third-party or legacy services.

Whether your archive moves with you or not, it’s important to discover and understand what you have, and plan for it to remain accessible, readily discoverable and workable post-migration. The specifics of this vary from company to company, but can quite easily involve extracting blobs (binary large objects) and rebuilding the archive elsewhere with the relevant links ‘rehydrated’ from the main system.
Now another challenge arises in the form of older public folders. Over the years these folders expand quickly, and ad hoc, as team members use them as shared repositories for all manner of documents (which are not always email). The folder hierarchies are controlled by users, which means it can be extremely challenging for IT admins, as they are unable to govern or manage these folders effectively.

Fortunately, there are several possible targets for legacy public folder data if you are switching off an old Exchange installation, such as modern public folders, Office 365 Groups and SharePoint Online. However, it’s important to avoid a ‘move everything’ approach, as the result is likely to involved moving huge volumes of potentially old, unused or irrelevant data unnecessarily. Take this route and you run the risk of making your new environment as obtuse, cluttered and inaccessible as the one you’re moving from.

Eradicating and discarding data

Having decided what data needs to be migrated to Office 365 (and how to ensure everything is accessible and discoverable once the move has completed) – what happens to everything that appears to be redundant and no longer needed? Can you just ignore it and move on?

As Steve Goodman mentions, the answer is almost certainly no, and “your goal should be reducing the footprint of your on-premises Exchange infrastructure to a bare minimum or removing it entirely.”

What do I do with the data I no longer need?

You have to be extremely careful about deleting data. Retention policies must be obeyed, and even if you believe that the files will never need to see the light of day again – there is always a possibility that one of those files could be requested and cited in a court case one day. This means that if you are going to eliminate old data, you need to do so in a demonstrable way and be able to explain the reasons for that decision.

Consider a scenario whereby you’re trying to defend a patent at some point in the future, or perhaps you’re dealing with an employee dispute that ends up in court. The reality is some of these files, hiding amongst duplicates, corrupted files, low quality, and business-irrelevant files, still hold value. These files, and the data within them, need to be retained securely and entirely, so they’re available if they’re ever needed.
Whilst this process is determined by your own retention and compliance policies (or dictated by law), keeping accurate records is a process that should be automated wherever possible. Doing so demonstrates compliance and ensures accuracy.

This is one of the main reasons eradication is a genuine technical challenge. You must retain accurate, defensible reports relating to what has been deleted and is no longer accessible. ‘Cleaning up’ and reporting effectively after switchover is ultimately one of the most vital technical challenges affecting migration.

Golden rules?

It perhaps sounds too simple, but to meet the golden rules of migrating only the data you need, making sure relevant items remain available and disposing of unwanted data effectively, you need the right technology – which is precisely what we will be exploring in our next post in this series.