Choosing a connection method

Nothing can be migrated until both the source and the destination are connected to VaultMe, and the way each side gets connected decides how much of the preparation work lands on you and on the people whose accounts are being migrated. This article is about choosing that method for each side and knowing what it will cost in practice.

What does choosing a connection method involve?

Start from the rule that everything else here follows from: VaultMe cannot touch either end of a migration until that end has been connected to it. The source is connected so VaultMe can read content out of it, and the destination is connected so VaultMe can write that content in. A connection is always established with the provider that hosts the account — someone signs in there and approves the access VaultMe asks for — and both sides have to stay connected for as long as migrations are running, including any follow-up run later on. What a connection is as a channel, rather than how one is arranged, is covered in "How VaultMe authentication works".

Everything in the migration inventory falls under that requirement, not just the obvious accounts: nothing on that list can be read from or written to until it has been connected. If that list is not settled yet, "Building the migration inventory" is where it gets built. What the VaultMe app connects, though, is user accounts — the source accounts that content is read out of, and the destination accounts that it is written into.

In an Outlook to IMAP-compatible mail system migration, there is no gap between the two: every row in the migration inventory is a user account, so the list you have already built is the list of connections to arrange — the source account on each row, plus the destination account it maps to. All that is left to settle is how each of those accounts gets connected.

There are two ways a side can be connected, and which of them is even available is decided by the side itself:

• Admin authorization. An administrator connects a whole managed environment — a Google Workspace organization or a Microsoft 365 tenant — to VaultMe once, and VaultMe can then reach the user accounts inside it without anyone connecting them individually. It exists only for those two kinds of environment, because they are the only ones with central administration to grant it.
• Resource-level authorization. Each user account is connected on its own, with authorization scoped to that one account. It is the only option for accounts that belong to no such environment, and it is also the fallback on a managed side where the administrative privileges an admin grant needs cannot be secured.

In an Outlook to IMAP-compatible mail system migration, neither side is a managed environment, so there is no central grant to lean on: every account on both sides is connected on its own, one at a time. The work is almost entirely coordination — reaching the people whose accounts are being migrated, or gathering what you need to connect those accounts yourself.

What is left to decide is how those individual connections are made, and that can differ between the two sides. The next two chapters explain each method in turn, and the two after them apply the methods to the source and the destination, with the specifics each provider brings.

Almost all of the work behind a connection method is preparation rather than clicking: securing an administrator's cooperation, distributing links, chasing the people who have to act, and working out how multi-factor authentication (MFA) will be cleared. Connections are also the first thing in the whole preparation phase that can be checked rather than assumed, which is worth doing as connections start to exist instead of on migration day — see "Planning the migration timeline" for where that fits in the schedule.

By the end of this article you should have a method for each side of your Outlook to IMAP-compatible mail system migration, and a realistic read on what each one costs: who has to act, how long they are likely to take, and what can quietly go wrong while you wait.

How does connecting with admin authorization work?

Admin authorization is the method where an administrator connects an entire managed environment to VaultMe in one step, after which VaultMe can reach the user accounts inside it without anyone connecting them individually. Only a Google Workspace organization or a Microsoft 365 tenant can be connected that way. In an Outlook to IMAP-compatible mail system migration, neither side is one of those, so the method does not apply and there is no central grant to pursue on either side. Every account is connected with resource-level authorization instead, which the next chapter covers.

How does connecting with resource-level authorization work?

Resource-level authorization connects one user account at a time. The authorization is scoped to that single account: whoever completes it signs in as that account, approves the access VaultMe requests, and the resulting connection covers nothing beyond that one account. It applies to any side not connected with an administrator grant, including a managed side where such a grant could not be secured.

The consequence to plan around is that somebody has to be able to get into each account. Whoever completes a connection must clear whatever sign-in challenge the account has, multi-factor authentication (MFA) included. A mailbox reached over IMAP is the exception: it is connected with its own credentials rather than a provider sign-in, so the gate there is having valid credentials in hand rather than passing a challenge.

There are two ways to arrange that, and a project can use both on different sides: hand each account holder a connection link so they connect their own account, or gather what you need and connect the accounts yourself. Distributing links is the recommended approach, because it keeps every sign-in with the person it belongs to.

Distributing connection links

A connection link is how VaultMe delegates a single connection to the person who can complete it. The sequence is short:

1. You send the link to the account holder.
2. The holder opens it and signs in with the provider as themselves.
3. They approve the full set of permissions VaultMe requests.
4. The connection appears in your VaultMe workspace, ready to be used in a migration project.

The links themselves are generated in the workspace as soon as the source and destination providers are chosen — one source link and one destination link for the whole project, not one per account. Each is tied to that workspace and that pair of providers, neither expires, and either can be handed to as many people as the project needs. No standing access is being passed around: a link lets someone establish a connection that can only be used inside your workspace.

The two links are not interchangeable. They request different permissions, because the two roles need different access: the source link asks for read access, the destination link asks for read and write. Using the wrong one is the mistake worth designing against, precisely because it does not look like a mistake — the account connects, the workspace shows a connection, and the permissions behind it are wrong for the role, which is enough to stop a migration from starting.

The practical guard is to send a separate email per side, each spelling out exactly what the recipient should do: which account to connect, which side of the migration it is for, and that every permission on the consent screen has to be approved. Where the same person holds an account on each side, they get two emails rather than one with both links in it.

Two gaps in the VaultMe app shape the outreach:

• Distribution is yours to do. VaultMe does not send connection links to end users, so getting each link in front of the right person — by email, chat, or whatever actually reaches people — is part of your plan rather than something the app handles.
• Nothing tells you when someone connects. VaultMe does not notify you as connections arrive; the only way to know where things stand is to look at the workspace. Track who has connected in the migration inventory, alongside everything else recorded per account — see "Building the migration inventory".

The things that actually go wrong, in rough order of how often they cost time:

1. The email is ignored or never opened. This is the single biggest source of delay. Plan to follow up and re-send; with holidays and absences in the mix, waiting on a handful of unresponsive people can stretch a side's connection work into weeks.
2. The wrong account is connected. Someone signs in with a different account they hold rather than the one on your list.
3. The wrong side is connected. A source link is used for a destination account, or the other way round.
4. Permissions are approved only in part. Some providers let the user clear individual items on the consent screen. The connection exists, looks healthy, and cannot carry a migration.
5. A holder runs into a problem and says nothing. From your side it is indistinguishable from someone who has not got round to it yet.

Partial approvals are worth one extra note, because VaultMe can catch them for you but not immediately. It validates the permissions actually granted and flags what is short, and it does that once a migration project exists — the workspace's own view of a connection does not show it. So verify early: create a project and run the free pre-migration scan as connections start arriving, rather than discovering a permission shortfall on migration day. See "How VaultMe works" for what that scan covers.

Collecting credentials and connecting accounts yourself

The alternative removes the waiting. Instead of depending on each account holder to act, you gather what is needed to sign in as each account — often a spreadsheet of logins and passwords, sometimes passwords you reset yourself — and then connect the accounts one after another. For mailboxes reached over IMAP this is usually the practical route, since there is no provider sign-in for a holder to complete in the first place.

MFA is the crux of this approach, and it has to be settled before you start rather than discovered at the third account. There are three ways through it, none of them comfortable: adjust the MFA policy temporarily, which on some providers can only be done for the environment as a whole and so relaxes it for everyone; turn MFA off for individual accounts for the duration; or keep each account holder on hand to clear their own challenge as you reach their account. The first two carry a genuine security trade-off that somebody senior should agree to, and the third hands back some of the coordination you were trying to avoid.

Two habits keep this approach from creating problems of its own:

• Connect each account in its own private or incognito browser session. Providers make it awkward to hold several identities in one session, and a leftover session from the previous account is exactly how the wrong account ends up connected.
• Treat the collected credentials as the sensitive material they are. A list of logins and passwords is as sensitive as anything else in the project, so keep it tightly held and dispose of it once the connections are made. Where accounts are connected through Google or Microsoft, VaultMe never receives the password — sign-in happens on the provider's own page and VaultMe is handed a token instead — so what you collect exists only for your own sign-in step. Mailboxes connected over IMAP are the exception, because the protocol has no equivalent of that token: the credentials are supplied to VaultMe, which stores them encrypted.

Either way, resource-level authorization makes the project depend on people — whether every account holder can be reached, and whether each can clear their account's MFA at the moment it matters. "Preparing stakeholders and end users" covers that side of the work. What belongs in the plan is who performs each connection and what they need in hand; generating the links and working through the accounts in the VaultMe app is covered in "Connecting and adding user accounts".

How is the source connected?

A source connection grants read access. VaultMe reads content out of the source accounts and writes nothing back into them, so the permissions on this side are the narrower of the two. Which method carries that connection depends on the source alone.

Because Outlook accounts belong to no environment an administrator can connect, there is no central grant to pursue: every source account is connected on its own. In most projects that means sending the source connection link to each account holder and having them sign in to Outlook as themselves, which also keeps the decision to hand over an account with the person who owns it.

Where waiting on people is the greater risk, you can collect credentials and connect the accounts yourself instead — with MFA handling arranged in advance, since these accounts are protected by their holders' own settings rather than by a central policy you control.

How is the destination connected?

A destination connection grants read and write access: VaultMe writes migrated content into the destination accounts, and reads the destination as it goes so that content lands in the right place. Getting those accounts into a state where they can be connected at all is separate work — see "Getting the destination ready".

Because your destination mail system is reached over IMAP, connecting the destination is not a provider sign-in. Each destination mailbox is connected by supplying its IMAP credentials — the server or host name, the login, and the password or an app-specific password where the mail system demands one — and IMAP access has to be enabled on the destination server for that mailbox. What you supply is stored encrypted.

Because no account holder has to sign in, this side is usually connected centrally: gather the credentials for every destination mailbox, then connect them one after another.

A checklist for choosing the connection method

Run through this once per project. Every account on both sides is connected on its own, so there is no method to choose per side — only how those connections get made and who makes them.

1. Decide how connections get made on each side. Connection links are the recommended approach; connecting the accounts yourself is the alternative when waiting on people is the bigger risk. The two sides can differ.
2. If you distribute links: generate the source and destination links, write one email per side with exact instructions, plan to follow up and re-send, and watch for the wrong account, the wrong side, partial approvals, and silence.
3. If you connect the accounts yourself: settle MFA handling before you start, use a separate private browser session per account, and keep the credential list tightly held.
4. Confirm what each connection depends on. Every account holder you need is reachable, knows what is coming, and can clear their account's MFA when asked. For mailboxes reached over IMAP the dependency is the server rather than a person: confirm IMAP access is enabled for each mailbox and that its credentials, including app-specific passwords where they are required, are valid and complete.

Everything on that list is planning: securing access, deciding who acts, and getting what each connection needs into place. Each of those decisions is then carried out in the VaultMe app, in the same flow that adds the accounts to a migration project — see "Connecting and adding user accounts".

Once connections exist, confirm them rather than assuming them. Create a migration project and run the free pre-migration scan against the connected accounts: it uses the connections for real and reports what is missing, including permission shortfalls that the VaultMe workspace shows as healthy. See "How VaultMe works" for what else that scan tells you, and do it well before migration day.

The method settled for each side is where readiness work on that side begins, because until a connection exists nothing else about the source or the destination can be proven — "Getting the source ready" and "Getting the destination ready" pick up from there. Where accounts are connected one at a time, the legwork also paces the project: who is ready when depends on who has connected, which is why this work resurfaces as soon as the rollout is shaped into batches, in "Choosing a migration strategy".