Selecting content for migration

This article covers the second scope decision in a migration project: which content VaultMe copies out of the mailboxes already on the migration inventory, and what it leaves behind.

What goes into selecting content for migration?

In most migration projects, selecting content is a genuine choice. VaultMe migrates four content types — email, files, calendars, and contacts — and each user account can bring across any combination of them. From an IMAP-compatible mail system, the choice has already been made for you. IMAP is a mail protocol: it exposes a mailbox's mail and nothing else, so email is the only content type VaultMe migrates.

That makes this a short decision, but not one to skip past. It rests on the list of mailboxes built in "Building the migration inventory", and it asks a different question of that list — not which mailboxes migrate, but what comes out of them, and what does not.

Two things should be true once the decision is settled:

• A clear picture of what migrates. What email covers, and what each destination mailbox holds once the migration finishes.
• An accounted-for list of what stays behind. Calendars, contacts, files, and anything else the organization relies on are written down, each with a plan and a person attached.

What does VaultMe migrate from an IMAP-compatible mail system?

Email, and only email. What that covers is the mail the connected mailbox holds:

• Messages, with their attachments. Every message VaultMe finds in the mailbox is copied into the destination mailbox with its original content and its attachments intact.
• Read and unread state. A message that was unread in the source mailbox arrives unread, so nobody has to work through a destination mailbox where every message looks new.
• The folder structure. VaultMe replicates the mailbox's folder structure in the destination and places each message where it sat in the source, so people find their mail roughly where they left it.

Whether that structure blends into mail already in the destination mailbox or stays clearly apart from it is not decided here. It follows from the active-or-archived choice recorded against each mailbox in the migration inventory, which is covered in "Building the migration inventory".

One limit belongs in the scope conversation rather than in the technical work later on. VaultMe reads each mailbox through IMAP, so it migrates the mail the server still holds for that mailbox — anything the server no longer has is invisible to it. The case that catches organizations out is a desktop client set up to download messages and delete them from the server: the mail still exists, but only as a local copy on one computer, and a migration that reports every discovered message as copied will still leave it behind. Confirming per mailbox that the expected mail is visible in webmail, or in another server-side view, is part of "Getting the source ready".

Can just part of the mailbox be migrated?

No, and that is a deliberate design choice rather than a gap. VaultMe indexes every message it can discover in the source mailbox and then works through that index message by message, aiming for a complete copy. There is no setting for migrating only the last two years of mail, or only a chosen set of folders.

The reasoning is that each message is a business record, and importance does not track gigabytes. The one message that turns out to matter, three folders deep and six years old, is indistinguishable by any rule a tool could apply from the ten thousand around it, while storage is cheap enough that keeping all of it is rarely the expensive part of a migration. VaultMe preserves everything instead of guessing what is safe to drop; this thinking is set out at more length in VaultMe's migration philosophy.

Experience points the same way. The call would have to be made blind, before anyone has looked at what is actually in the mailboxes, and no date cutoff or folder subset is reliably the right one — the exclusions people regret are the ones that looked obviously safe at planning time. Rather than provide a lever that cannot be pulled safely, VaultMe leaves it out.

If the volume genuinely has to come down, the reliable way is cleanup at the source by the people who know what the mail is. The price of each migrated user account rises with the data volume and the number of items it brings, as "Pricing and payment" explains, so a smaller mailbox does cost less. Ask mailbox holders to work through their own mailboxes and move what they no longer need to the trash folder, which is not migrated. It is a low-risk request: the source is being decommissioned later anyway, trash remains recoverable in the meantime, and hesitating over whether to trash something is usually a sign that it still matters.

What can't VaultMe migrate from an IMAP-compatible mail system?

Everything that is not email. That is the most important sentence in this article, because the assumption most likely to cause trouble later is that a whole user account comes across. Its mail comes across.

It is worth separating what stays behind into two kinds, so that the data sitting inside the same accounts is not quietly assumed to be safe:

• Non-mail data in the same accounts. Calendars and contacts usually live alongside mail, show up in the same app, and are reached with the same login, which makes them feel like part of the mailbox. IMAP does not carry them, so they cannot be migrated.
• Everything kept outside the mail system. File shares, document stores, and the other tools and services the organization runs on were never within reach of a mail migration, but they still belong on someone's list, because the source is going away.

Turning that limitation into a deliberate sweep is admin-side work, and it has to be, because VaultMe cannot do it. VaultMe connects to individual mailboxes with the credentials it is given and reads mail through them; it has no view of the mail system as a whole and no view of anything outside it. It therefore cannot hand over a list of what is being left behind, and neither can the pre-migration scan. That list gets produced by making a conscious pass through the setup with the people who know it — whoever administers the mail system, and the people who use it daily and would notice a missing calendar the morning after cutover.

Anything the sweep turns up is out of scope for this migration and needs a plan of its own: exported, moved by hand, handled with another tool, or consciously abandoned. Working out which of those applies is beyond what this article covers. Making sure nobody is expecting it to arrive alongside the mail is the whole point. The same boundary is drawn from the inventory side in "Building the migration inventory".

Settling content scope for the project

From an IMAP-compatible mail system, content scope comes down to three confirmations. Run them top to bottom and record the result alongside the mailbox list:

1. Email is the only content type that migrates. Everyone with a say in the project understands this, including the stakeholders who approve the budget and the people whose mailboxes are moving.
2. The mail is on the server for every mailbox in scope. Each mailbox has been checked in webmail or another server-side view, and any mail that a desktop client pulled off the server has been synced back up before the migration runs.
3. Non-mail data has a plan and an owner. Calendars, contacts, files, and everything else the sweep turned up are written down, each with a named person responsible for it, so none of it is left to be discovered after the source is gone.

None of it is locked in. Nothing is committed until a batch is paid for and started, and the free pre-migration scan happens well before that point and reports the real size and item count of each mailbox — so a borderline mailbox can be revisited with actual numbers rather than estimates. What the scan checks is covered in "How VaultMe works", and when payment is due in "Pricing and payment".

With content scope settled, the decisions that follow are about access rather than scope: "Choosing a connection method" covers how each mailbox is connected, and "Getting the source ready" covers what has to be true on the server before VaultMe can read it.