Getting the source ready

Getting the source ready means making sure VaultMe can read every account you plan to migrate from, and that everything you expect it to read is actually there. On a personal source the list of conditions is short, and most of the work is coordination rather than configuration.

What does getting the source ready involve?

On a personal source there is barely anything to prepare technically. There is no organization or tenant sitting behind the accounts, nothing to license or provision, and no central console to configure — the accounts themselves are the whole source. That leaves two things to get right: being able to reach the person behind each account so it can be connected, and being sure the content you expect is held in the cloud rather than on someone's laptop or phone. Once both are true, the source is done and you can turn to the destination.

The starting point is the migration inventory you already built, described in "Building the migration inventory". From a personal source that inventory is simply a list of user accounts, and there is nothing else in it to get ready. So source readiness reduces to a single question asked once per account in the inventory: can VaultMe read this account, and will it find what you expect inside it?

"Ready" therefore means two reading conditions, both true for every account you plan to migrate from:

1. VaultMe can connect to the account and read it. The account can be signed in to, someone is available to authorize access, and the connection holds until the migration finishes.
2. The content you expect is in the account's cloud. Every message, file, contact, and calendar entry the business needs is held in the cloud for that account, not only on someone's laptop or phone and not in a different personal account they also use.

For most projects this is confirmation rather than work. A handful of accounts in daily use, account holders who answer their email, and content that has always lived in the cloud add up to a source that is already ready: connect the accounts, scan them, move on. The effort grows when an account is locked or half-forgotten, when an account holder is hard to reach, or when someone has been reading their mail in a desktop client that pulls messages off the server.

How the connection itself is made is a separate topic. Personal accounts are connected one at a time, each one authorized by its own account holder, because there is no environment-wide admin grant that can cover them all; the choice between sending connection links and collecting credentials yourself is covered in "Choosing a connection method". This article is about the conditions that let that connection succeed and keep working afterward.

One point is worth making before anything else, because it decides how you will use everything below: the only way to know an account is ready is to create a migration project in VaultMe and run the free pre-migration scan against it, as described in "How VaultMe works". Reasoning from a spreadsheet is not proof. The destination does not have to exist yet — a project with only the source side connected checks those accounts on their own, which is a normal and expected way to work.

The part VaultMe cannot do for you is worth naming too. With no directory to read, VaultMe cannot discover which personal accounts your business uses, and it cannot report content missing from a place it has no way to see. Both halves of the confirmation are yours, and both are done with the people who hold the accounts rather than from a console.

What you are aiming for, then, is a source where every in-scope account can be connected and read, and where the content everyone expects has been confirmed to be in the cloud — with a clean scan as the evidence. "A checklist for source readiness" collects the whole thing into one list.

Making sure VaultMe can connect to each account

Each user account is connected on its own, either by its account holder opening a connection link and authorizing access, or by you signing in with credentials that holder gives you. Those mechanics belong to "Choosing a connection method"; what matters here is the handful of conditions that decide whether the connection succeeds and survives.

• Someone has to be reachable for every account. The binding constraint on a personal source is people rather than technology. For each account there has to be a person who can sign in — normally the account holder, and for an account several people share, such as a support or billing login, one designated person who acts for it. That person also has to be able to clear whatever multi-factor authentication the account uses, whether that is a code, an app prompt, or a security key, and to approve the full set of permissions VaultMe asks for; a partly approved connection leaves VaultMe short of what the migration needs. Lining these people up is usually the slowest part of the project, so start early — "Preparing stakeholders and end users" covers that side of the work.
• The account has to be active and accessible. An account that is locked, suspended, or stuck in a recovery or verification loop cannot be connected, because nothing can be read through an account nobody can sign in to. That has to be resolved with the provider before the account is connected, and if it cannot be resolved, the account consciously stays out of scope.
• The connection has to stay alive once it exists. A password reset, or a change to the account's multi-factor authentication settings, revokes the access that was granted and drops the connection. VaultMe pauses the migration until it is restored, and restoring it means connecting that account again the same way it was connected the first time. The practical guard is to ask account holders not to change passwords or authentication settings on a connected account between connecting it and the end of the run, and to coordinate any change that genuinely cannot wait with reconnecting afterward.

Beyond those, trimming unused third-party apps and automation from an account is optional housekeeping rather than a readiness requirement. Automation running against an account uses up the same provider limits the migration has to work within, so trimming what you safely can may make the run a little smoother — but readiness does not hinge on it.

Account holders are sometimes wary of connecting a personal account, especially one that carries private content alongside work, and the reassurance is concrete. A source connection asks for read access: VaultMe reads content out of the account and never changes, reorganizes, or deletes anything in it, and the account stays fully usable while the migration runs. Which content is actually migrated is a separate decision, made with the account holder rather than for them, and "Selecting content for migration" walks through it.

Making sure everything is in the cloud

VaultMe indexes and copies only what the connected user account holds in the cloud for the content types in scope. Anything that exists only on a device, or in the cloud of a different account, is invisible to VaultMe: it is not indexed, it is never reported as missing, and it does not arrive in the destination. This is the one condition that can leave a migration looking entirely successful while content the business cares about stays behind.

Personal accounts trip on this more often than managed ones, because a personal laptop or phone blends several clouds into one screen. A mail app shows two accounts side by side, a folder on the desktop syncs to one drive while files from another sit next to it, and a phone's address book mixes entries from everywhere. It is easy for someone to think of content as being "in the account" when the account never held it.

Three checks cover almost every case, and each one is a question to ask the person who uses the account:

• Email. The mail has to still be on the server for the account being connected, and the check is simply whether the account holder can see it in Outlook.com in a browser. If someone reads their mail in a desktop client set up to download messages and remove them from the server — the older POP style of mail access, still common on long-lived personal accounts — only a local copy is left on that computer, and that mail is not discoverable. It has to be synced back up to the account before the migration runs.
• Files. A single device can be signed in to more than one account at once — a second personal OneDrive, or a work one, sitting alongside the OneDrive of the account being connected — so files easily end up in the wrong one. Files sitting in another account's drive are not part of the connected account until someone moves them there. Files that were shared with the account rather than created in it are a different matter, decided when content is selected rather than fixed here — see the shared files chapter of "Selecting content for migration".
• Contacts and calendars. Entries kept only on a handset, or in a local address book or calendar app, and never synced up to the account's contacts and calendars, do not migrate. Ask each account holder to confirm that what they rely on is syncing to the account rather than living only on the phone in their hand.

The task is not to reorganize anyone's content or to move everything into the cloud right now. It is to consciously confirm, account by account and with the people who use them, that what the business expects to arrive is in the cloud today — because the destination will hold what was in the cloud when the migration ran, and VaultMe cannot surface what it never saw.

Confirming the source is ready

Everything above is judgment; the pre-migration scan is proof. To get it, create a migration project in VaultMe with the in-scope user accounts connected as the source and run the scan against them. It is free, it commits you to nothing, and it can be re-run as often as you like.

The reason it is the only real proof is that a connection can look perfectly healthy and still be wrong. An account may have been connected with the destination link rather than the source one, which asks the provider for a different set of permissions, so the connection appears successful while the migration cannot start. The scan is the first step that actually connects to each account and reads it.

You do not need destination accounts to do this. A project with only the source connected checks the accounts on their own, which is the normal way to prove one side while the other is still being prepared; the destination side has its own readiness work, covered in "Getting the destination ready".

Against the source, the scan tells you three useful things:

• Each in-scope account is reachable and readable. The connection is live, and the permissions granted with it are enough for VaultMe to read the account.
• Anything observably wrong comes back as a to-do. An account VaultMe cannot reach, or permissions that fall short of what the migration needs, are raised as specific items tied to that account rather than as a vague warning. What a to-do is and how one is cleared is covered in "Running the pre-migration scan".
• Real per-account size and item counts. These are worth reading rather than skimming: an account that comes back far smaller than its account holder describes is a strong hint that content is stranded outside the cloud.

What the scan cannot see is exactly the sweep from the previous chapter. It has no way to know about mail sitting in a desktop client or files in someone's other drive, so that confirmation stays with you and the account holders. A clean scan means VaultMe can read the source, not that the project is ready; "Before you migrate" sets out what readiness covers overall.

Run it early rather than on migration day. The value of the scan is the time it leaves you to fix what it flags and run it again, and nothing is committed until a batch is paid for and started — see "Planning the migration timeline" for where this fits in the schedule.

A checklist for source readiness

Run this top to bottom, once for the whole source:

1. Every in-scope user account is active and accessible, with a reachable person who can sign in as that account and clear any multi-factor authentication it requires.
2. The content you expect is confirmed in the cloud for each account — mail still on the server rather than only in a desktop client, files in the connected account rather than in another OneDrive, and contacts and calendars synced up rather than living on a phone.
3. Account holders have been asked not to change passwords or authentication settings on a connected account until the scan and the migration are done, with any unavoidable change coordinated with reconnecting.
4. A migration project has been created in VaultMe and the pre-migration scan has been run against the accounts — a source-only project is fine — its to-dos cleared, and the reported sizes and item counts sanity-checked against what the account holders describe.

With a clean scan behind you, the source is proven and you can set it aside: the next work is on the destination accounts that will receive the content, covered in "Getting the destination ready". None of this is final either, since nothing is committed until a batch is paid for and started, so an account can still be added, dropped, or reconnected as the picture changes.