Getting the source ready

This article covers the technical work that makes an IMAP source readable: what has to be true in each mailbox before VaultMe can migrate its mail, and how to confirm it really is true.

What does getting the source ready involve?

Getting the source ready means working through one question for every mailbox you plan to migrate: what has to be true here so that VaultMe can read everything you expect it to read? From an IMAP source that question has an unusually short answer. The mailbox is the only thing VaultMe migrates from this source, and email is the only content it holds, so there is no environment to connect and nothing else on the source side to prepare.

The work starts from the migration inventory you have already built, which from an IMAP source is simply the list of mailboxes in scope. Getting the source ready means making VaultMe able to read each mailbox on that list. Assembling the list itself is covered in "Building the migration inventory".

A mailbox is ready when two things are true of it:

1. VaultMe can connect to it and read it. The mailbox accepts an IMAP connection, and the credentials you supply are the right ones.
2. The mail you expect to migrate is on the server. Whatever should end up in the destination is held by the mail system rather than sitting in a desktop client on somebody's computer.

Get both right for every mailbox on the list, and what arrives in the destination will match what you expect.

For most IMAP projects this is quick work. A handful of reachable mailboxes whose mail has always lived on the server need little more than connecting and scanning. The work appears when IMAP access is switched off somewhere, when credentials are stale or incomplete, or when someone has been pulling mail down into a desktop client for years.

Deciding how the source connects, and handling the practicalities of collecting credentials, belong to "Choosing a connection method". The conditions on the mail system that a connection depends on are what this article covers.

One thing is worth saying before any of the detail. The only way to know a mailbox is ready is to create a project in VaultMe and run the free pre-migration scan against it. Credentials that look correct in a spreadsheet are not proof — the scan is what actually connects to the mailbox and reads it. The destination does not need to be ready first: a project with only the source connected checks the mailboxes on their own. The scan itself is described in "How VaultMe works".

By the end of this work, every mailbox in scope is connectable and its mail is confirmed to be on the server, proven by a scan that comes back clean. The final chapter folds all of it into a single checklist.

Making sure VaultMe can connect to each mailbox

Connecting an IMAP mailbox means supplying its IMAP credentials to VaultMe. There is no environment-wide admin grant available, and no provider sign-in screen for a mailbox holder to complete on your behalf. How you go about that, and who collects what from whom, are covered in "Choosing a connection method". What matters here is the state each mailbox has to be in for a connection to succeed at all.

Two conditions have to hold on the mail system itself:

• IMAP access is enabled for the mailbox. VaultMe reads an IMAP source through the IMAP protocol, so a mailbox with IMAP switched off cannot be connected however good the credentials are. On most mail systems this is a per-account or server-wide setting an administrator can turn on. Check it before connecting rather than after a connection fails.
• The credentials are valid and complete. VaultMe needs the correct server or host name, the login, and the password for each mailbox. Where the mail system enforces extra verification on the account, generate an app-specific password for it and supply that instead of the everyday password. The kind of multi-factor prompt that interrupts a provider sign-in generally does not apply to IMAP connections, so the gate here is valid credentials and IMAP being enabled, not getting hold of a person at the right moment.

Credentials supplied this way are stored encrypted. Password-based access is the exception rather than the norm for VaultMe — most providers are connected without a password ever being handed over — but where a protocol requires credentials, they are held under the same protections as everything else VaultMe stores. What that covers in detail is set out in "What data VaultMe processes during migration".

Once a mailbox is connected, leave its credentials and its IMAP setting alone. Resetting the password, rotating credentials, or disabling IMAP breaks the connection, and VaultMe pauses rather than continuing without it, waiting until the connection is restored. Between connecting a mailbox and running the migration, avoid changes of that kind entirely; where one is unavoidable, such as a scheduled password rotation, plan it so the mailbox is reconnected immediately afterwards.

Because no per-holder sign-in is involved, collecting the credentials centrally and connecting the mailboxes yourself is usually the easiest route on an IMAP source. There is nobody to chase for a sign-in, as long as whoever administers the mail system can supply or reset the credentials you need.

Making sure the mail is in the cloud

VaultMe reads only what the connected mailbox holds on the server. That sounds obvious, and it is still the biggest trap on an IMAP source. Mail that a desktop client downloaded and then removed from the server — the normal behavior of a POP setup — exists only as a local copy on someone's computer. VaultMe cannot see it, cannot report it as missing, and will not migrate it.

So the check runs per mailbox: open it in webmail, or in whatever other server-side view the mail system offers, and confirm that the mail that matters is genuinely there. Where someone works in a desktop client that pulls mail off the server, those messages have to be synced back up before the migration runs. Otherwise the run completes successfully and the destination mailbox is still short of years of mail, with nothing anywhere to say so.

A related boundary is worth naming while you are asking these questions. IMAP is a mail protocol, so email is the only content type VaultMe can migrate from this source. Calendars and contacts often live alongside the mail and feel like part of the same account, but they cannot be migrated through IMAP, and neither can files or anything else kept outside the mail system. That is not something getting the source ready can fix — it is a matter of scope, and it is covered in "Selecting content for migration".

Both of these land on you rather than on VaultMe for the same reason: VaultMe sees what a mailbox holds on the server and nothing else. It has no way of telling you that three years of mail is sitting on a laptop, or that a team also depends on a shared calendar. Confirming with the people who actually use each mailbox that the mail they expect to move really lives on the server is the one part of source readiness no tool can do for you.

Confirming the source is ready

The only way to confirm the source is ready is to create a migration project in VaultMe and run the pre-migration scan against the mailboxes. Everything described above can look right on paper and still fail in practice: IMAP left off on one account, a host name that is nearly correct, credentials that connect but do not give access to the whole mailbox. The scan is not a paperwork exercise — it connects to each mailbox and reads it, which is exactly what the migration will do.

A project with only the source connected is fine here, and it is the normal way to work. You do not need a destination in place to find out whether the mailboxes are reachable. The two sides are checked independently, and a source can be proven ready long before anything exists to receive its mail.

What comes back is per mailbox: whether VaultMe could connect and read it, and the real size and item count of what it found there. Those numbers are useful beyond readiness, because a mailbox you were unsure about becomes a decision you can make with figures instead of guesses. What the scan cannot see is mail that never reached the server, so the sweep described in "Making sure the mail is in the cloud" stays with you. For the wider picture of what has to be in place before a migration can run at all, see "Before you migrate".

Run the scan early. It is free, it can be repeated as often as you like, and each pass reports what still needs attention as a to-do tied to a specific mailbox. Fix what it flags, run it again, and keep going until it comes back clean — the loop is covered in the chapter on working through to-dos in "Running the pre-migration scan". None of this commits you to anything: no charge applies until a batch is paid for and started.

A checklist for source readiness

Once the mailbox list is settled, work through this from top to bottom:

1. IMAP access is enabled on the server. Confirmed for every mailbox in scope, since a mailbox with IMAP switched off cannot be connected at all.
2. Credentials are valid and complete. The server or host name, login, and password for each mailbox, plus an app-specific password wherever the mail system enforces extra verification.
3. The mail is on the server. Checked per mailbox in webmail or another server-side view, rather than assumed, and synced back up where a desktop client has pulled it down.
4. No credential or IMAP changes are pending. Nothing scheduled on an already-connected mailbox that would break its connection before the migration runs.
5. Non-mail data is accounted for. The people who depend on calendars, contacts, and files know that none of it migrates with the mail, and each of those has a separate plan and an owner.
6. The pre-migration scan comes back clean. A project created in VaultMe — with only the source connected, if that is all you have — the scan run against the mailboxes, every to-do cleared, and the reported sizes and item counts looking about right.

With a clean scan behind you, the source is proven and can be set aside; the next work is on the other side of the migration, in "Getting the destination ready". None of it is locked in either way — everything stays reversible until a batch is paid for and started.