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 a Microsoft 365 to IMAP-compatible mail system migration, for most of the inventory there is no gap between the two, because a user account is what each row already is. Anything on the list that is not an account becomes one, or rides inside one, before it can be connected: a shared mailbox is converted into a licensed user account and then connected like any other account, while document libraries and the files behind Teams and Microsoft 365 Groups are migrated inside the file migration of a connected user account that has access to them. Which account carries which of those is a question the inventory answers rather than this article — see "Building the migration inventory".

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 a Microsoft 365 to IMAP-compatible mail system migration, only the source is a managed environment. One administrator grant can connect it along with every account in scope inside it, while the destination has no equivalent: each destination account is connected on its own, which means either the person behind it takes part or you sign in as that account yourself. Expect the destination side to carry most of the coordination.

The two sides are decided independently of each other, so the method on one side never constrains the other. 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 Microsoft 365 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?

Where it is available, admin authorization is the method to aim for. An administrator connects the environment itself, once, and VaultMe can then discover the user accounts inside it and reach the ones selected for migration — no per-account sign-in, nothing to distribute, nobody to chase. The single step covers ten accounts or a thousand, which is why this is the method built for batch migrations.

The mechanics are the same whichever side is connected this way. The administrator connects the environment to VaultMe and approves the access it requests, and VaultMe receives environment-level access from the provider. A grant on the source side carries the read access VaultMe needs to read content out of the accounts in scope; a grant on the destination side carries the read and write access it needs to place content into them. Each grant stands alone, so one is needed per environment being connected.

The requirement that decides whether any of this is realistic is who can perform the grant. Whoever runs the migration has to be able to sign in as an account that holds the provider's top-tier administrative privileges in the environment being connected, and nothing lower will substitute. In a Microsoft 365 tenant, it is the Global Administrator role.

For an admin migrating their own organization, that is usually a formality — the role is either already theirs or can be assigned internally. Migrations run on behalf of another organization are where it gets difficult. There are only two ways to satisfy the requirement — the organization's own top-tier administrator runs the migration themselves, or whoever is running it is given access to an account that holds the role, whether by having their own account elevated or by being handed a dedicated administrator account — and organizations are frequently unwilling to put privileges of that level in an outsider's hands. Treat it as work to budget for rather than a box to tick: on larger projects it is not unusual to have to track a customer's administrator down in person before the grant actually happens.

Two properties of the grant are worth knowing before arranging one:

• The approval is all or nothing. Whoever performs the grant is shown the full set of permissions VaultMe requests and approves it as a whole; neither provider offers a way to approve some permissions and decline others at connection time. There is no reduced version of the grant to fall back on if the list turns out longer than expected.
• The access is environment-wide. An environment-level grant technically reaches everything the environment holds, which is how the providers' administrative grants work rather than something VaultMe chooses. What bounds it in practice is VaultMe's own behavior: it reads and writes only the user accounts and content inside the migration scope you configure, and nothing else in the environment is read, indexed, or migrated. Where the grant has to be signed off by someone other than the person arranging it — a security review, or an organization deciding whether to admit an outside migration operator — "What VaultMe does not do with customer data" states those limits directly.

Being available is not the same as being obtainable, and the gap between the two is worth testing early. Admin authorization can apply to a side in principle and still not happen in practice:

• Policy forbids the grant. Some organizations rule out environment-level access for any external application, whatever it is for.
• Nobody will hand over the privileges. Granting top-tier access to whoever runs the migration is the usual sticking point when the work is done on behalf of another organization.
• The approval takes too long. The grant itself is a single step, but waiting for the right administrator to be free, or for a change-approval process to run its course, is not.
• Admin access has been lost. It sounds unlikely, but it does happen: an environment set up years ago by someone who has since left, with nobody holding working top-tier credentials today.

Where that is the case, the side is connected account by account instead, as covered in "How does connecting with resource-level authorization work?". It is a normal outcome rather than a planning failure, and because the two sides are settled separately, losing admin authorization on one side does not cost it on the other — it stays the better choice on any side where it can be secured.

Two things stay with you under an admin connection:

• Selecting which user accounts are in scope. The grant makes the accounts in the environment reachable, not migrated; which of them a migration actually covers remains your decision.
• Making any provider-side change the grant depends on. In practice that means a temporary adjustment to a multi-factor authentication (MFA) policy or to an administrative policy that would otherwise block the connection.

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 Microsoft 365 is a managed environment, the source side can be connected with a single admin grant, and that is the route to aim for: it connects the source tenant once, after which VaultMe can discover the user accounts in it and read the ones in scope. The grant has to be performed by whoever runs the migration, signed in as an account that holds the Global Administrator role in the source tenant — so the first thing to establish is who will run it and whether they can get such an account.

Where that privilege cannot be secured, the source side falls back to resource-level authorization: every source account in the inventory is connected on its own, with the source connection link sent to its holder or with credentials you collect and use yourself. Nothing about the migration changes; what changes is how much coordination the source side takes.

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. The two sides are settled independently, and mixed projects are ordinary rather than a compromise — an administrator grant on one side and account-by-account connections on the other is a normal shape, as is the same method on both.

1. Decide the source-side method. Choose admin authorization if top-tier administrative privileges can be secured in the source environment for the person running the migration; otherwise the source is connected account by account.

2. Nothing to decide on the destination side. With no environment to grant, every destination account is connected on its own.

3. Secure top-tier administrator access for every side on admin authorization. The grant can only be performed by whoever runs the migration, signed in as an account holding top-tier privileges in that environment: the Global Administrator role in a Microsoft 365 tenant; settle whether that person is the organization's own administrator or someone being given such an account, book the time it takes, expect an all-or-nothing approval, have the scope boundary ready for the questions it raises, and plan any provider-side MFA or administrative-policy change the grant depends on.

4. For any side connected account by account, choose how. Connection links are the recommended approach; connecting the accounts yourself is the alternative when waiting on people is the bigger risk.

   • 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.
   • 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.

5. 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".