The Office 365 Virtual Journal feature brings with it the possibility to migrate large journal archives to Office 365, using multiple target mailbox/personal-archives and specifying criteria such as number of items and size of target. This article explains more detail about this splitting process.
Journal Archives in source environments are typically large. Their multiple terabyte nature makes it currently quite hard to migrate the data to Office 365 as there are limits imposed by Microsoft on both the mailbox and personal archive sizes. To be able to migrate a large journal archive to Office 365, the product introduced a concept of a ‘Journal Splitting’.
There are two processes in migrating a journal archive to Office 365. This can be via Journal Splitting or a Journal Transformation. Below are the steps for Journal Splitting.
The general process for doing this is:
- Define the naming scheme for the target. It is suggested to prefix or postfix names, eg AL- or -Departed. This makes the data easier to find in the target after the migration has completed.
- Define the allowed number of rolling licenses.
- Decide on the type of ‘hold’ to place on the migrated data.
- Configure the maximum number of items allowed per child container, and maximum size allowed.
- Perform the mapping.
In the background what will happen is:
a. Provisioning
- A user account will be created according to the naming scheme.
- A Personal Archive will be created if it was required in the mapping.
- The mailbox/personal archive will be placed on the selected type of hold.
- A license will be assigned from the pool.
- The data from Office 365 about the ‘user’ will be synchronized.
b. Migration
- Data will be exported after the provisioning process is done.
- Data will be imported soon after it is exported, when a particular child container is full, as determined by the system settings, a new one will be created.
c. Stage 2
- The license which was assigned in order to be able to ingest data in to the mailbox (or Personal Archive) will be removed (usually as the last step) and returned to the pool so that another mapping can take that license and complete the provisioning step.