Getting the destination ready

Getting the destination ready is the technical work that makes every account VaultMe will write into able to receive what is headed for it. This article covers what that takes, and how to prove it before the migration runs.

What does getting the destination ready involve?

There is remarkably little to prepare on the destination side. No environment has to be stood up, no licenses bought or assigned, no domains registered or verified. The accounts already exist in Outlook, or their holders create them, and everything the provider supplies comes with them. What remains is narrow enough to state in one line: every account that will receive content has to be reachable by VaultMe, and it has to have sufficient storage for what its source will deliver.

Which accounts those are was settled when the migration inventory was built in "Building the migration inventory". Each source in scope is mapped to the destination account that will receive its content, and destination readiness is judged one account at a time against that mapping. There is nothing else on this side to get ready.

"Ready" comes down to two conditions, and both have to hold for every account in the inventory:

1. VaultMe can connect to the account and write into it. The account exists, it is not locked or otherwise unreachable, someone can authorize access to it, and the connection is still live when the migration runs.
2. The account has sufficient storage for what its source will deliver. Enough of the account's storage quota is free to hold the content headed its way, with the size of that content measured rather than guessed.

Most projects of this shape are small, and the work matches: a handful of accounts, holders who answer quickly, and destination accounts that are new or barely used. Where that describes yours, this is a short exercise — connect each account, run the scan, and move on. The rest of this article is about the places where it is not that simple.

Connecting is its own topic, and the mechanics belong to "Choosing a connection method". The short version is that in a Microsoft 365 to Outlook migration there is no environment-wide admin grant available on the destination: each account is connected on its own, authorized by the person who holds it, and a destination connection grants both read and write access. This article covers only what has to be true for that connection to be made, and to keep working afterward.

One point is worth making before the details, because everything below returns to it. The only way to know a destination account is ready is to create a migration project in VaultMe with the source and the destination both connected, and run the free pre-migration scan described in "How VaultMe works". A destination cannot be checked on its own — only against the source it has to receive. Whether an account has sufficient storage is really a question about how much content is coming, and that number does not exist until the source has been scanned.

VaultMe does not create destination accounts and does not buy storage for them; both are the customer's to arrange, and VaultMe's part starts once the accounts exist and are connected. Done properly, this leaves every destination account connected with write access and holding sufficient storage for its source, with a scan to prove it. The last chapter collects the whole thing into a single checklist.

Making sure VaultMe can connect to each account

Each destination account is connected to VaultMe on its own, and that connection grants read as well as write access: VaultMe writes migrated content in, and reads enough of the account to fit what arrives around the content already there. How the connection is made — sending each holder a connection link, or collecting credentials and connecting the accounts yourself — is covered in "Choosing a connection method". What matters here are the conditions on the destination side that let a connection happen at all, and keep it alive until the migration is over.

The binding constraint is people rather than technology. Each account is connected by someone who can authorize access to it — normally its holder — and that person has to be able to clear whatever multi-factor authentication (MFA) challenge the provider presents. Until that has happened for an account, nothing else about it can be proven, so line the holders up early rather than discovering at the end that two of them are on leave. The wider job of briefing and chasing those people is covered in "Preparing stakeholders and end users".

Two things have to be true of the account itself before anyone can connect it:

• The account exists and is active. VaultMe does not create destination accounts, so each one has to be created by its holder first, and it has to be a working account rather than a name someone intends to register later.
• The account is genuinely accessible. An account that is locked, suspended, or stuck part-way through a recovery or verification flow cannot be connected, however willing its holder is. Sort those out before the connection step rather than during it.

A connection that works today can also stop working before the migration runs. Password resets, changes to MFA, and other provider-side security changes on a connected account invalidate the connection, and VaultMe pauses any migration that depends on it until the connection is restored. Restoring it is not automatic: the same connection method has to be repeated for the affected account. So the instruction to holders is a simple one — no password changes and no MFA changes from the moment they connect until the migration is over, including any sync-up migration (delta migration) that picks up later changes. Where a change genuinely cannot wait, coordinate it so the account is reconnected immediately afterward.

One piece of optional housekeeping is worth passing on at the same time. Rules that automatically file, forward, or delete mail in a destination account will act on migrated mail as it arrives, and can file it out of sight or send copies somewhere nobody expects. Turning those rules off until the migration is finished avoids the surprise; none of it changes what VaultMe migrates.

Holders who are cautious about authorizing access to their own account are usually reassured by where the boundary sits: the connection lets VaultMe write the content the migration is configured to cover and reach nothing else in the account. "What VaultMe does not do with customer data" spells that out in full and is a reasonable thing to forward to someone who asks.

Making sure there's sufficient storage

Storage is the one place a destination account is genuinely likely to fall short. The storage quota that comes with the account is fixed until someone pays to raise it, and a migration that delivers more content than the account has free will stall part-way through, with some of the content landed and the rest waiting.

How much an account needs cannot be worked out by looking at the destination, and it cannot be eyeballed from the source either. It depends on how much content the source actually holds, which is a figure the pre-migration scan produces and nothing else does. Nor is the source's own reported size a reliable stand-in: migrated content is not expected to occupy the same amount of storage at the destination as it did at the source, and it can end up either larger or smaller. The effect is clearest for email and documents, which the destination provider reformats and repackages as it accepts them rather than storing the source's bytes unchanged. Ordinary files kept in cloud file storage are the exception — destinations take those as they are, so their size carries over.

When an account does turn out to be short, there are two levers. The usual one is to upgrade its storage plan, which is a purchase the account holder or whoever pays for the account has to make. The other is to send less: narrowing the content types in scope, or leaving out content that does not need to come along, both reduce what has to fit. "Selecting content for migration" covers that decision.

Confirming the destination is ready

Everything above can be in place and still leave the destination unproven. An account can connect without trouble and turn out to be short of storage. It can connect and carry the wrong permissions, because a source connection link was used where a destination one was needed, or because its holder approved only part of the permission set VaultMe requested. The only way to settle it is to create a migration project in VaultMe with the source and the destination both connected, and run the pre-migration scan.

This is the sharpest difference between the two sides of readiness. A source can be scanned by itself, as the confirming chapter of "Getting the source ready" describes — its content is there to be counted regardless of where it is going. A destination cannot, because "ready" is a statement about what it is about to receive. The scan pairs each source with the destination account mapped to it and asks its questions about the pair, not about either side alone.

For each destination account, the scan establishes:

• Whether VaultMe can write into it. The account is reached through its live connection and the granted permissions are checked against what the migration needs, which is where a wrong link or a partial approval finally shows up.
• How much content its source actually holds. Per-account item counts and volumes come out of the source side of the scan, and they are the numbers the storage question is settled with.
• Whether its storage is sufficient for that content. The two figures are compared for the pair, which is a comparison no destination-only check can make.

Anything that fails becomes a to-do — a single flagged item tied to one account, naming the action needed to clear it. Work through them, fix what they point at, and run the scan again — that loop is covered in "Running the pre-migration scan".

Do this early rather than on migration day. Creating a project and running scans costs nothing, and payment only enters the picture when a batch is actually started, so there is no reason to hold off. Everything the scan can flag needs lead time to fix: a holder who never opened their connection link, an account whose storage plan has to be upgraded, permissions that have to be approved again. "Planning the migration timeline" covers how much of that time to reserve.

A checklist for destination readiness

Working top to bottom, the destination is ready when:

1. Every destination account exists, is active, and is connected to VaultMe with write access. For each one, the account holder is reachable and able to clear multi-factor authentication (MFA) challenges, and the account is not locked or stuck in a recovery or verification flow.
2. Each account has sufficient storage for what its source will deliver. Where it does not, either its storage plan has been upgraded or the content in scope has been trimmed.
3. Holders have been asked not to change passwords or MFA settings on connected accounts until the migration and any sync-up migration (delta migration) are finished, and automatic filing, forwarding, and deletion rules have been turned off in the destination accounts.
4. A migration project has been created in VaultMe with the source and the destination both connected, and the pre-migration scan has been run. Its to-dos are cleared, and every account is confirmed to have sufficient storage for the source it is paired with.

With the destination proven against the source, both sides are ready and what is left is shape and timing: how the accounts are grouped into batches in "Choosing a migration strategy", when each batch runs in "Planning the migration timeline", and how the switch away from the source is handled once VaultMe has finished in "Planning the cutover and domain switch". None of it is locked in yet — nothing is committed until a batch is paid for and started.