Journal Archive Migrations to Microsoft 365

As organizations continue to migrate their local solutions to Cloud vendors, this often includes the migration of local email archives to a Microsoft 365. These email archives can consist of individual mail user archives, single instance journal archives or a combination of both.  This blog posting will focus specifically around migrating a single instance journal archive to Microsoft 365.  First, let me explain what a single instance journal archive is.

A journal archive is an email archive that consists of a single instance of every message that flows through an email server prior to be delivered to the users.  This eliminates the need to archive from each user’s individual mailbox.  If archiving for retention purposes were employed on a per user mailbox basis, there would be significant numbers of duplicate data.  Each message, a copy would need to be created for each user listed in the To, From, CC and BCC fields.  This would require massive amount of diskspace to accommodate all these duplicate emails.  The purpose for the journal is to ensure that a single copy of every email is retained for legal purposes regardless of how many users are listed in the address fields or within distribution group.  This process also ensures that an end user cannot delete a message before their mailbox is archived.  

Within Microsoft 365, there is no such thing as one of these journal archive solutions.  With Microsoft 365, each mailbox must contain only the data for the individual user named for that mailbox and not mail for any other user.  This is called single custodian email accounts.  When a journal message is migrated to Microsoft 365, a copy of that message must be placed into each intended recipients’ mailbox.  This is the process of de-journaling the email; the single instance message must be replicated for each listed recipient, and the sender as well.  Given that until we look at an individual source journal email to determine first its size and then the number of recipients, we have truly no idea of how big this message will become once replicated to all recipients.

This image is an example of one email in a journal (the one with the magnifying glass) that lists 40 people within the header information.  To migrate this to Microsoft 365, a copy must be placed in each user mailbox.  So, in this case, that message is replicated 40 times. Now consider if this email contains images, or attachments; these too must be replicated to each user mailbox.

When we de-journal an archive, we do see a significant increase in size of the end data state.  It is this replicated email for each recipient listed in a journal message that accounts for larger data.  The process of any archive migration vendor is to determine all the source messages along with all the recipients of each email, and build a repository based upon each user.  Then as each email is processed, a copy is created for each listed recipient, and those emails are then migrated to corresponding Microsoft 365 mailbox.  While the data in the source may be small, the data written to the destination may be increased as much as 4-fold.  

So, as you can see the process is complicated, time consuming task that requires proper planning, co-ordination, and scheduling.

Migrating from Journal to O365

Trusted Data Solutions can help organizations with this unique problem.

Our team of expert Migration Engineers along with our migration solutions, are well positioned to help you migrate your journal archives to Microsoft 365.  Not only can we migrate the data, but we will account for every single message within your source archive and provide full chain of custody.  If you have questions or would like more information, please email us at [email protected]

Contact us today with your legacy data needs.