Building the migration inventory

This article covers the first planning decision in a migration project: which mailboxes are migrated, and how each one should arrive in the destination.

What goes into building the migration inventory?

When a handful of mailboxes obviously need to be migrated, this takes a few minutes: write them down, put them all in scope, and go on to the next decision. The rest of this article is for bigger projects and murkier ones — a mail system that has collected mailboxes nobody can account for, addresses that may or may not still be read, people who left years ago. If none of that describes your situation, skim.

The migration inventory is the list of what the project migrates. VaultMe reads your source mail system through IMAP, and IMAP is a protocol for mail, so the mail held in a mailbox is the only thing it can migrate — which makes the inventory a list of mailboxes and nothing else. There are no calendars, contacts, or files to inventory on the source side, because none of them can be migrated through IMAP at all. That has real consequences for the organization, and they are the subject of "How is everything that isn't a mailbox handled?".

On anything larger than a handful of mailboxes, this is the first decision to settle, because the ones that follow are built on the answer: how many mailboxes have to be connected and who has to help with each, whether the project runs as one batch or several, and how long the whole thing takes. None of those can be worked out against a list that is still moving.

It is also a budget decision, and more directly than admins tend to expect. VaultMe bills per migrated user account, so every mailbox left on the list carries a price — a base migration fee plus fees for the volume of mail it holds; what a single migrated account costs is set out in "Pricing and payment". Past a handful of mailboxes, that total is usually something a manager or a budget holder has to approve, so plan for a review round with whoever holds the budget rather than an afternoon of decisions made alone.

One dependency is worth knowing about while the list is still taking shape: there is no central authorization that connects your source mail system in a single step. Each mailbox is connected on its own, using that mailbox's IMAP credentials, so every row on the list is a small piece of work in its own right — and in practice the schedule waits on the person who uses the mailbox, or someone else with access to it, being able to supply what the connection needs. How that works in detail is covered in "Choosing a connection method"; the point here is that it is worth planning while the list is being built, not on setup day.

None of these calls are VaultMe's to make, and on this path VaultMe cannot even tell you what the choices are. It has no view of the mail system beyond the individual mailboxes it has been given credentials for: no directory to read, no addresses to suggest, no way to notice that a mailbox exists but was left off the list. What exists, and what still matters, comes entirely from the organization.

Two decisions come out of the work:

1. Which mailboxes are migrated. Not every mailbox on a mail server is worth migrating, and the list usually gets shorter rather than longer as it is reviewed.
2. Whether each surviving mailbox is migrated as active or as an archive. This is about what the mailbox is for afterwards, and it changes how the mail is organized in the destination and what the destination side costs.

Both are recorded per mailbox, and "A checklist for finalizing the inventory" folds them into a single pass at the end.

How is the migration inventory built?

There is no single answer to where the list comes from, because IMAP describes a protocol rather than a product. The source might be a mail server run in-house, a mailbox package bought from a hosting provider, or a small business mail platform nobody has looked at closely in years. VaultMe knows only that it can speak IMAP to it; whether the system has a central administration interface at all, and what that interface looks like if it does, is outside what VaultMe can know. So there is no console to point you to and no export to describe.

In practice the list is assembled from whichever of these is available:

• Mail server or hosting provider tools. Where the system has a control panel or a server-side administration interface, it is usually the closest thing to a directory of mailboxes that exists.
• Billing and DNS records. Invoices from a hosting provider often itemize the mailboxes being paid for, and the mail-routing records for a domain show which domains receive mail, and therefore which addresses could be in use.
• The people in the organization. Whoever set the mail system up, the office manager, the team leads. On many IMAP systems this is the most reliable source there is, and the only one that knows which addresses anyone actually reads.

Often there is no tidy directory anywhere, and the list has to be reconstructed by hand out of those fragments.

Keep it in a spreadsheet. On this path you will most likely be typing it in rather than exporting it, which makes the sheet the original record rather than a copy of one. How much formality it needs scales with the project: three or four mailboxes can be tracked informally, a couple of dozen really wants a sheet, and once the rollout splits into more than one batch the sheet stops being optional.

The reason is how VaultMe is used rather than how it is priced. VaultMe works on one migration project at a time and launches batches one by one, rather than holding a whole multi-batch rollout open at once, so a plan that spans several batches cannot live in the app. Later stages lean on extra temporary projects as well, spun up to run a free pre-migration scan and confirm that a batch's mailboxes are genuinely ready before the real run — a scan that reports what it finds without committing you to anything, as described in "How VaultMe works". The same sets of mailboxes therefore get assembled again and again, and the sheet is the only place the full picture exists. It also saves the retyping, because VaultMe's setup screens accept rows pasted straight from a spreadsheet: when a batch's turn comes, filter the sheet to that batch and paste its addresses in.

While you are building the sheet, record who can get into each mailbox. Mailboxes are connected one at a time, so access to the individual mailbox — IMAP enabled for it on the server, and valid credentials someone can supply — is what most often holds an IMAP project up, rather than anything that can be settled centrally.

That suggests the columns worth having from the start:

1. The email address. The mailbox's own address, exactly as the server knows it.
2. The person or the function behind it. A name for a personal mailbox, or what the address is for when it belongs to a role rather than a person.
3. Whether it is still in use. A first, rough judgment: actively read, or abandoned but still enabled.
4. Who can confirm it should be migrated. The person whose answer settles it, which is not always the admin.
5. Who can complete the connection. The person who uses the mailbox, or whoever else can supply its credentials.
6. An empty keep, drop, or archive column. Filled in by the two decisions the next chapters walk through.

VaultMe does not build this list and cannot help you build it. With no central administration to read, assembling the inventory here is more manual than it would be in a managed environment, and the app only becomes useful once the list exists and can be checked against the mailboxes themselves.

Which mailboxes actually need to be migrated?

This decision is mostly subtraction. A mail system that has been running for years collects mailboxes nobody actively uses: role addresses set up for a team that no longer exists, mailboxes still enabled months after the person using them left, the mailbox behind a catch-all address or a set of aliases, test accounts created during some earlier setup. As far as the server is concerned every one of them is a real mailbox, and not one of them is automatically worth migrating.

The cost points in one direction. Because VaultMe bills per migrated user account, each mailbox that stays on the list adds a base migration fee plus the data fees for the mail it holds; the rates behind that are in "Pricing and payment", and it is worth having them in front of whoever reviews the list. An inventory that keeps everything just in case is straightforwardly more expensive than one that has been trimmed, and once the arithmetic is visible these reviews reliably go the same way: stakeholders cut mailboxes, they do not add them.

The awkward cases are rarely the admin's to decide alone. An abandoned mailbox, or a former employee's mail, may still matter to the business — for continuity, because a customer conversation lives in it, or because someone in the organization has a retention obligation nobody has written down. Those calls need management input, and getting an answer takes longer than asking the question, so raise them at the start of the pass rather than at the end of it.

For each row, the questions that decide it:

1. Is anyone still using it, and does anyone still need the mail in it? A mailbox nobody reads and nobody needs the history of is the easiest cut on the list.
2. Is it a role, catch-all, or test address that is no longer needed? These accumulate quietly and are worth checking individually, because a few of them turn out to be the only place a particular kind of correspondence ever landed.
3. Can VaultMe connect to it at all? IMAP has to be enabled on the server for that mailbox, and someone has to be able to complete the connection with valid credentials. A mailbox nobody can get into cannot be migrated whatever it holds, and the server-side conditions behind that are covered in "Getting the source ready".
4. Is there a legal or retention obligation to keep the mail regardless? If there is, the mailbox stays in scope whether or not anyone reads it, and the next chapter decides how it arrives.

None of this is locked in. A mailbox can be added or dropped right up until a batch is paid for and started, and the pre-migration scan puts real numbers behind the borderline cases: it reports each mailbox's actual size and item count, so a mailbox everyone assumed was enormous can be reconsidered once it turns out to hold a few hundred messages.

Should a mailbox be migrated as active or archived?

Every mailbox that survives the trim needs one more decision, and it is about purpose rather than mechanics: will somebody be working in the destination mailbox afterwards, or is the point only to preserve the mail and keep it findable? The first is an active migration, the second an archive, and each maps to one of the two ways VaultMe organizes migrated mail in the destination.

• An active mailbox is migrated with the merge method. VaultMe matches the source mailbox's folders to the corresponding folders of the destination mailbox — the inbox to the inbox, sent mail to sent mail — and adds the migrated mail into them, so the destination mailbox becomes the single mailbox its user works in. Where the destination mailbox already holds mail, the migrated mail is added alongside it rather than replacing anything.
• An archived mailbox is migrated with the separate method. VaultMe creates a folder of its own in the destination mailbox — typically named after the source mailbox's address — and replicates the source mailbox's folder structure inside it, so the archive stays clearly apart from anything else the destination mailbox holds and is easy to locate and recover from later.

Both methods are described more fully in "How VaultMe works".

The clearest case for an archive is the mailbox of someone who has left. The business may need to keep the mail for continuity or for a legal reason, but nobody is going to work in it day to day, and standing up a whole new destination mailbox for someone who is gone is hard to justify. Archiving that mail into a destination mailbox that already exists gets the same result: the separate method keeps it in its own clearly labeled folder, the mail is preserved and findable, and nothing new has to be created to hold it.

The decision is made per mailbox and driven by what that mailbox is for, not set once for the project. Most projects end up mixing the two: current staff migrated as active, plus a few archives for people who have left or for role addresses being retired but kept for the record. Each mailbox's disposition becomes a setting on its account when the project is configured — see "Choosing migration options".

It is worth making deliberately rather than marking everything active by default, because the two have different consequences on the destination side. An active mailbox needs a destination mailbox of its own, whereas archived mail can be consolidated — several source mailboxes archived into one destination mailbox, each in its own folder. In Microsoft 365, a mailbox of its own means a licensed seat of its own, so consolidating archives into fewer accounts reduces the licenses the organization has to buy and keep paying for.

What has to be in place on the receiving side, for either choice, is covered in "Getting the destination ready".

How is everything that isn't a mailbox handled?

Everything above has been about mailboxes, and that is not a matter of framing: the mail in a connected mailbox is genuinely the only thing VaultMe migrates here. It reaches your source mail system over IMAP, IMAP carries mail and nothing else, and so mail is the whole of what can be read out.

The assumption most likely to cause trouble is the one about calendars and contacts. On most mail systems they sit right next to the mail, in what looks like the same account, so it is natural to expect that connecting the mailbox brings them along. It does not. They cannot be migrated through IMAP at all, so the organization has to plan for them separately; "Selecting content for migration" goes through what that leaves out in more detail.

This is the part of the inventory where the work falls squarely on you, because VaultMe cannot help with it. It sees only the mailboxes it has credentials for and knows nothing else about the system, so it cannot hand you a list of what is being left behind. That list has to be produced deliberately, by sitting down with the people who know how the organization actually runs and asking what else they depend on.

What the sweep turns up is worth sorting into two kinds, because they get missed for different reasons:

• Non-mail content inside the same accounts. Calendars and contacts, most commonly. These are the dangerous ones: they feel like part of the mailbox, so nobody thinks to plan for something they assume is already covered.
• Everything kept outside the mail system. File shares, documents, and whatever other tools and services the organization has accumulated. Nobody expects these to arrive with a mail migration, but they still need a plan and someone responsible for it if the source is going to be retired.

Anything outside the mailboxes is out of scope for this migration and has to be handled separately. Making sure that is a decision rather than a discovery is the job here; actually moving file shares or standing up a new calendar system is a project of its own, and not one VaultMe is built for, as "What is VaultMe" explains.

So the inventory has two sides to it. Every mailbox that matters is on the list, and everything else the organization depends on has been accounted for somewhere other than this migration — starting with the calendars and contacts, because those are the ones that look like they are coming.

A checklist for finalizing the inventory

One pass, top to bottom. When every line is true, the migration inventory is finished and the decisions waiting on it can be made.

1. Reconstructed the list of mailboxes from whatever source of truth exists — server or hosting provider tools, billing and mail-routing records, or the people who know which addresses are in use.
2. Confirmed each mailbox is still needed, and dropped the rest. Role addresses nobody reads, test accounts, and mailboxes left enabled out of habit come off the list.
3. Secured sign-off on the awkward ones. Abandoned mailboxes and former employees' mail kept or dropped on management's decision, not the admin's guess.
4. Marked each surviving mailbox active or archive. Active ones are migrated with the merge method, archived ones with the separate method.
5. Confirmed each mailbox can be connected. IMAP enabled on the server for it, and someone able to complete the connection with valid credentials.
6. Confirmed with IT and management that non-mail content will not be migrated. Calendars, contacts, files, and shares stay behind, and each has a plan of its own with someone responsible for it.
7. Recorded a clear decision on every row. No blanks: a mailbox with an empty decision is the one that gets missed on launch day.

With the list settled, the decisions that were waiting on it can be made — how each mailbox is connected, in "Choosing a connection method", and whether the project runs as one batch or several, in "Choosing a migration strategy", which in turn is what the schedule in "Planning the migration timeline" is built from. All of it stays changeable: nothing is committed until a batch is paid for and started.