Getting the destination ready

This article covers the technical work that makes the destination writable: what has to be true in each mailbox before VaultMe can connect to it and write mail into it, and how to confirm it well before the migration runs.

What does getting the destination ready involve?

There is one question to keep asking, once per mailbox: what has to be true in this mailbox so VaultMe can write everything headed to it? When the answer is "nothing more" for every mailbox in scope, the destination is done and you can set it aside and stop thinking about it. On an IMAP destination that point arrives quickly, because there is unusually little to prepare.

The list of things to prepare comes straight from the migration inventory assembled in "Building the migration inventory", which already names what migrates and which destination each source maps to. On the destination side there is only one kind of thing on that list: the mailbox on the destination server. No organization or tenant to stand up, no licenses to assign, no services to switch on — just mailboxes, and the same short check for each one. Only mail can arrive, too, since IMAP is a mail protocol and the destination server has no way to accept anything else through it.

For each mailbox, "ready" means two things:

• VaultMe can connect to the mailbox and write into it. The mailbox exists on the destination server, IMAP access is enabled for it, and the credentials supplied for it are valid. A destination connection grants both read and write access, because VaultMe has to add mail to the mailbox rather than just read what is there.
• The mailbox has enough storage for the mail its source will deliver. IMAP servers set a storage quota per mailbox, and the mail arriving has to fit inside it, with something left over for the mail that arrives afterward.

For most projects that is genuinely all of it. Mailboxes that already exist on a server you administer, with IMAP enabled and generous quotas, need no preparation beyond connecting them and running a scan. Real work appears in specific situations: a mailbox that has not been created yet, IMAP switched off, credentials that have gone stale since someone last wrote them down, or quotas set tight enough that a full mailbox's worth of mail will not fit.

Connecting is part of readiness, but choosing how each side connects and supplying the credentials is its own decision, covered in "Choosing a connection method". What that article leaves to this one is the other half: the conditions on the destination server that a connection depends on, and what keeps a connection working once it exists.

One thing is worth stating before any of the detail, because it is what the rest of this article comes back to: none of this counts as proven until you create a migration project in VaultMe with both the source and the destination connected and run the free pre-migration scan, which is described in "How VaultMe works". Credentials that look right in a spreadsheet are not proof that a mailbox will accept mail, and storage cannot be judged at all without knowing how much mail is coming — a figure only the scan produces, by measuring the source.

Work through this article and you should end up with every in-scope mailbox connectable, writable, and holding enough storage for its share of the migration, all of it confirmed by a scan run against the source. The last chapter collects the whole thing into a single checklist.

Making sure VaultMe can connect to each mailbox

On IMAP there is no environment-wide grant, and no sign-in screen for the person who uses the mailbox to click through. Connecting a mailbox means supplying its IMAP credentials, and VaultMe uses them to reach the mailbox directly. That connection grants read and write access, since VaultMe has to add migrated mail to the mailbox. How the connection is made and where the credentials go belongs to "Choosing a connection method".

Three things have to be true on the server for that connection to work:

• The mailbox exists on the destination server. VaultMe fills destination mailboxes, it does not create them. Each one has to be created first by whoever administers the destination server — until it exists there is nothing to connect and nowhere for mail to land.
• IMAP access is enabled for the mailbox. VaultMe writes mail through IMAP, so a mailbox with IMAP switched off cannot be connected at all. Where that switch lives depends on the mail system: it is often a per-mailbox setting, sometimes a server-wide one, and occasionally both have to be on. Turn it on before you try to connect rather than after a connection attempt fails.
• The credentials are valid and complete. That means the server host name, the login, and the password — all three, exactly as the server expects them. Where the mail system enforces extra verification on the mailbox, generate an app-specific password for it and supply that instead of the everyday password. The multi-factor prompts that gate Google and Microsoft sign-ins usually do not apply to IMAP connections, which changes the character of the work: the gate here is valid credentials and IMAP being enabled, not reaching a person and walking them through a sign-in.

Because a mailbox is connected with a password, VaultMe has to store that password. IMAP credentials are kept encrypted at rest, on infrastructure that is not reachable from the public internet, and used only to connect the mailbox they belong to. What VaultMe holds and what it never asks for is set out in "What data VaultMe processes during migration", which is often the reassurance a cautious server administrator wants before handing over a list of logins.

Once a mailbox is connected, the credentials need to stay put. Changing a mailbox password or disabling IMAP for it breaks the connection, and without a live connection VaultMe cannot write: a running migration pauses and waits until the connection is restored. So avoid password rotations and IMAP setting changes on connected mailboxes between the moment you connect them and the end of the run. Where a change genuinely cannot wait — an expiring password, a security policy with a deadline — plan it together with reconnecting the affected mailboxes rather than discovering the effect from a paused batch.

Connecting by credentials rather than by sign-in also decides who does the work. On most destinations, connecting resources one at a time means distributing links and chasing the people who have to act on them. On IMAP there is nobody to chase: collecting the credentials for every in-scope mailbox centrally, from whoever administers the server, and connecting the mailboxes yourself is usually the fastest route by a wide margin. Treat that credential list as sensitive material and dispose of it once the migration is done.

Making sure there's sufficient storage

Every destination mailbox needs enough storage for the mail headed to it. IMAP servers enforce a quota per mailbox, and once a mailbox reaches that quota the server stops accepting mail. Mid-migration, that means VaultMe pauses and waits until more storage is provisioned, then resumes where it left off. Nothing already migrated is lost, but that mailbox makes no further progress until somebody raises the quota, which is a slow way to find out the quota was too small.

The subtler risk is sizing the mailbox so the migration just fits. A mailbox that is exactly full the moment the migration finishes has nowhere to put the mail that arrives the next morning, and the person using it hits a hard limit on their first day on the new system. Size each mailbox for the mail arriving plus headroom for what it will receive afterward, not for the migration alone.

Headroom matters for a second reason: migrated mail does not necessarily occupy the same amount of storage at the destination as it did at the source. The destination server reformats and repackages each message as it accepts it, rather than storing it byte for byte, so the total can come out somewhat higher or somewhat lower than the figure measured on the source. It is not a large effect, but it is enough to make a plan built on an exact match unwise.

Here IMAP differs from every other destination in a way that changes what you have to do. VaultMe cannot read how much storage a destination mailbox has left, so the pre-migration scan will not catch a mailbox that is too small: on other destinations a shortfall like that comes back automatically as a to-do to resolve, and here it does not. That makes storage the one readiness condition that stays manual, and the one most worth being deliberate about. The procedure is straightforward: take the size the scan reports for each source, then confirm with whoever administers the destination server that the mailbox mapped to it has at least that much free, with headroom on top.

Where a mailbox comes up short, there are two levers:

• Raise the quota on the server. Usually a per-mailbox setting the server administrator can change in minutes, and the right answer whenever the storage is available. Raising it before the run costs nothing; raising it after a migration has stalled costs the time the batch spent waiting.
• Trim what is coming from the source. Reducing the volume on the source side works too, and is the better answer when the destination genuinely cannot grow. What can and cannot be narrowed is covered in "Selecting content for migration".

Confirming the destination is ready

Everything above is preparation you can do on the server, and none of it is proof. The only way to know a destination mailbox is ready is to create a migration project in VaultMe with both the source and the destination connected, and run the free pre-migration scan. Credentials that look right can still fail in ways nobody spots by reading them: IMAP left off for one mailbox out of thirty, a host name that points at the wrong server, a login that authenticates but has no permission to add mail to the mailbox. The scan actually connects to each mailbox and confirms that VaultMe can write to it.

This is where destination readiness is harder to establish than source readiness, and the reason is worth understanding. A source can be checked on its own — a project with only the source connected scans those mailboxes and reports what is in them, as "Getting the source ready" describes. A destination cannot be checked that way, because a destination mailbox is only "ready" relative to the source it is going to receive. The scan pairs each source with the destination mailbox it maps to, and it reports the real size of each source — the number the whole storage check depends on, and the number you cannot get any other way.

So the scan and the manual check divide the work:

• What the scan confirms. Each destination mailbox connects and accepts mail from VaultMe. It also reports the real size and item count of each source, which replaces whatever estimate you were working from. Anything that fails comes back as a to-do tied to the mailbox it belongs to, so you know exactly which one to fix. What a to-do is and how one is cleared is covered in "Running the pre-migration scan".
• What it cannot check. Available storage on the destination is not visible to VaultMe over IMAP, so comparing each source's scanned size against the free storage in its destination mailbox stays your job, as described in "Making sure there's sufficient storage".

Run the scan early, and treat it as a working tool rather than a final exam. It costs nothing, requires no payment method, and can be run as often as you like: scan, fix what it flags, scan again. Finding out on migration day that IMAP is switched off on several mailboxes leaves no time to react, while finding out a week earlier costs an email to the server administrator; how much lead time to reserve for that is part of "Planning the migration timeline". Nothing is committed either way until a batch is paid for and started.

A checklist for destination readiness

Run this top to bottom before you consider the destination ready:

1. Every destination mailbox exists on the server. Each mailbox in the inventory has been created on the destination server, by whoever administers it.
2. IMAP access is enabled for every in-scope mailbox. Check each one rather than assuming a server-wide setting covers them all.
3. Each mailbox is connected to VaultMe with write access. The credentials used are valid and complete: server host name, login, password, and an app-specific password where the mail system requires one.
4. Each mailbox has enough storage for the mail its source will deliver. This one is confirmed by hand against the size the scan reports for that source, since VaultMe cannot read IMAP storage quotas. Where a mailbox is short, raise its quota on the server or trim the source scope.
5. No credential or IMAP setting changes are pending on connected mailboxes. Password rotations and IMAP changes are coordinated with reconnection, not left to land mid-run.
6. Non-mail content is accounted for. The people who know the setup have confirmed that calendars, contacts, and files will not arrive through IMAP and have a plan of their own; what is and is not in scope is covered in "Selecting content for migration".
7. A scan has proven all of it. A project exists in VaultMe with both the source and the destination connected, the pre-migration scan has run, its to-dos are cleared, and every mailbox is confirmed to connect and accept mail — with storage checked manually, per the fourth item.

With that done, the destination is proven against the source it will receive, and both sides of the migration are ready. What remains is shaping the rollout: how many batches and what goes in each is settled in "Choosing a migration strategy", when each one runs in "Planning the migration timeline", and how the switch to the destination lands afterward in "Planning the cutover and domain switch". None of it is locked in — nothing is committed until a batch is paid for and started, so scope and schedule stay changeable right up to that point.