Skip Ribbon Commands
Skip to main content

AMS User Guidance

Last Update: 7/21/2017 11:32 AM
This article has been moved to our new Help Center. Please update your bookmarks.


Archive Migration is a service provided by BitTitan to its Partners. Based on information provided by the Partner and/or customer, BitTitan will document customer migration requirements, create a statement of work, assign a team to perform the migration, and provide weekly reporting and feedback to the Partner to then provide to their customer. ​


Within the discovery process, it is crucial to think about and retrieve all the information necessary to complete our Archive Migration Service Intake Questionnaire. This information includes the following:

  • Number of active users to be migrated
  • Number of inactive users, and whether they are to be migrated
  • Size ​of the archive

This inf​ormation can be retrieved by using BitTitan's free scripts, which are run against the SQL database of the customer's third-party archiving system.


Servers, Securit​y and Accounts

The migration tool performs at its peak with two servers, whether physical or virtual. One server is used to perform the migration, while the second server hosts the database for the migration tool. The hardware requirements for the servers can be found in our Requirements document. Additionally, we require read access to the database of the third-party archiving system and the local files on the file server. Complete details can be found in the Requirements document. Finally, to migrate into Office 365, we require at least one, and optimally many, global administrator accounts with an active mailbox and with full access to the Destination mailboxes. BitTitan will provide guidance for this process. ​


​​​Many third-party archiving systems are used to perform journaling. These systems maintain a copy of every email sent and received by users. The system saves each message once, and each recipient gets a pointer to that item. When we migrate a journaling-based system into a non-journaling-based system like Office 365, every recipient needs to receive a copy of the item. This approach requires a different configuration, and we will work with you to provide the best solution.



We need to determine whether the customer wants to migrate the full archive or only a portion. Depending on legal or company compliance requirements, data may need to be saved for a defined number of years. We can migrate everything, or only enough information to meet the legal or compliance requirements. 

A crucial item in the discovery phase is identifying the Destination of the users. We support migration to multiple Destinations. We can migrate data to the following Destinations: On-Premises Exchange environments, Office 365, PST or MSG files. Depending on the user type, it might be advisable to target different Destinations. For example, for people who have left the company and have no active mailbox, it can be wise to export their data into a PST file. This approach would not require Partners or customers to pay for separate mailbox or archive licenses for these users on the Destination. These PSTs can be placed in secure storage in case of an audit or an eDiscovery. For instance, depending ​​​on the customer's usage of their archive, they may choose to migrate archive data younger than two years directly into the active mailbox instead of the archive mailbox, with everything older than two years migrated into the archive mailbox. In this way, Partners and customers can leverage the migration process to redistribute the email based on timeframe.

Migration s​​trategies

Now that we k​​now how many users and how much data we need to move, we need to determine the migration approach. We offer multiple approaches, each of which have value within a specific situation:

  • Migrat​​​​e archive mailbox independently of the active mailbox

The active mailbo​​x has already been migrated, or archive mailbox needs to be considered independently from the active mailbox. During the planning and migration, we do not take the active mailbox into consideration.

  • Migrate archive ma​​​ilbox together with active mailbox

Cut over the users' mailboxes all at once. The active and archive mailbox form one logical unit and need to be considered as one​​ entity. The migration of the archive mailbox, due to its size, will have to start first. At a certain point in time, depending on the timeframe and sch​eduling, the active mailbox migration is performed. With proper planning, they will complete together, enabling cutover at the same time.

  • Migrate a portion​​ of the archive mailbox for every user at the same time and backfill the rest

Cut over all of the users at the same time, but the size of the different archive mailboxes is preventing that. We can make sure that all the archive mailboxes contain the latest information (the timeframe needs to be determined by the customer). Once that ​​data is migrated for all of the users, they are cut over to the new system. Our migration tool will continue to migrate the legacy data so that, eventually, all the data is migrated to the new system. 


​Dealing with Stubs

In most ​​third-party archive systems, there is the concept of stubbing. Stubs, or shortcuts, are small files in the active mailbox replacing a​​n archived email, and pointing to the archived item. When users double-click on the stub, the original email will be loaded from the archive system. Our migration tool can deal with stubs in one of two ways:

  • Replace them with the original email, or
  • Remove the stubs

​When you replace the stubs with the original mail items, and you migrate the active and archive mail, this may result in duplication of some email. One email will be in the active mailbox, and another email will be in the archive mailbox.

In the second scenario, we remove the stubs, resulting in an active mailbox that does not contain the original emails. The archive mailbox will, however, contain that email.


Set customer expectation effectively and let end users know what to do, and what not to do, during a migration project. Communicate with end users about when the migration will be performed, and what to expect. Explain how their data will look in the new system.

If you are using a third-party archiving plug-in for Outlook, we recommend archiving until the migration has completed. In many cases, archives need time to synchronize with the mailboxes; you do not want the end user to see a different state of their new archive because of a sync delay. In most cases, the plug-in can be disabled by Group Policy.


We cannot migrate messages over 25MB. We have a filter in place to identify these messages. Once we have identified them​, we can export them to a PST file that can be given to the user.

​​​If at any time the files created by the archiving system are removed, we cannot migrate those messages. We will be able to identify them for audits, but recreation is not possible.


Every project is different, and speed calculation is not an exact science. Many factors, including bandwidth, internal network usage, number of concurrent connections, etc., may impact migration speed. We can achieve an average bandwidth of 600GB/day/connection. Multiple connections can be used. Note that for every connection used,​ an administrator account is required.