Getting the source ready

This article covers what has to be true in the source environment before VaultMe can read everything you plan to migrate, and how to confirm that it is.

What does getting the source ready involve?

One question runs through this whole stage, asked of every entry on the migration inventory: what has to be true in the source so VaultMe can read everything expected from it, with nothing quietly left behind? Once the answer is yes for every entry, the source can be set aside as ready and attention moves to the destination.

The inventory is the list of resources leaving the source. Most entries are user accounts, and VaultMe connects to and reads user accounts directly, so readiness is settled account by account. A managed environment can also hold resources that are not user accounts, and none of those has a sign-in of its own. In a Microsoft 365 tenant, that means shared mailboxes, SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups. Libraries and group files become ready through a connected user account that has access to them, while a shared mailbox is turned into a regular user account first; both paths are covered in "Getting non-user-account resources ready to migrate".

Ready means two things, and both have to hold for every entry on the inventory:

1. VaultMe can connect to the resource and read it. A user account is connected in its own right, either through an environment grant or on its own. Anything that is not a user account is reached through the connected account that carries it.
2. Everything expected from it is present in the cloud. VaultMe reads what a connected account holds with the provider for the content types in scope. Items that live only on a laptop or a phone, or in a different account or cloud, are invisible to it.

For many projects both conditions are close to true already. An inventory of active, in-use accounts whose content has always lived in the cloud, with no shared resources anyone needs, is a matter of connecting the source, running a scan, and moving on. The work grows with suspended accounts that have to be reactivated, shared resources that need a responsible user assigned, mail that still sits partly on an on-premises server, and third-party automation running against the accounts.

Connecting the source is part of readiness, but choosing how to connect it is a decision of its own: one environment grant from a top-tier admin covers every account inside the environment, while the alternative is connecting each account individually. That choice and the legwork behind it are covered in "Choosing a connection method". What follows here is only the source-side conditions a connection depends on, and what keeps it alive once it exists.

Everything in this article is about reading from the source. The matching work on the other side — provisioning accounts, assigning licenses, activating services, and confirming there is enough storage for what arrives — is covered in "Getting the destination ready".

There is also only one way to know the source is ready rather than believe it: create a migration project in VaultMe and run the free pre-migration scan against the in-scope accounts. A well-kept spreadsheet is a plan, not proof. The destination does not have to exist or be ready first — a project with only the source connected checks the source alone, which is a normal way to work rather than a workaround. What the scan does at each stage of a migration is described in "How VaultMe works".

One part of readiness stays with you no matter how thorough the scan is. VaultMe reads only what a connected account exposes in the cloud, and it cannot report what is missing from an account it never sees. If a department head's mail was pulled down into a desktop client years ago, nothing raises a flag: the migration succeeds, and the mail is simply not in the destination. Confirming that the expected content is where VaultMe can see it is your sweep, done with the people who know each account.

By the end of this stage every in-scope resource is readable, the content expected from each one is confirmed to be in the cloud, and a clean scan stands behind both claims. The last chapter gathers all of it into a single checklist.

Making sure VaultMe can connect to the source

The connection method and the mechanics of connecting belong to "Choosing a connection method". This chapter assumes that decision is made and covers what has to be true in the source for the connection to work, and what keeps it working afterwards.

Where the source is connected with admin authorization — the path to prefer in a managed environment — readiness means the environment grant is already in place, made from an account that genuinely holds top-tier privileges: a Global Administrator in the source tenant. A lower administrative role is not enough, and the privilege has to sit with whoever runs the migration rather than be borrowed for the moment of the grant, which is usually the slowest part of arranging it. Any MFA rule or admin policy that has to be adjusted for the grant to go through should be adjusted beforehand rather than in the middle of the attempt.

Every account in scope also has to be active and reachable in the source. A suspended or deactivated account cannot be signed into or read through, so it cannot be migrated while it stays in that state. Each one has to be reactivated before the run, or consciously dropped from scope. The inventory flagged these accounts when it was built; this is the stage where each of them is resolved one way or the other.

Where the source is connected account by account instead, each account has to be connectable on its own. That means the account holder is reachable and able to authorize access, or that credentials have been collected and whoever connects on the holder's behalf can clear that account's MFA challenge. This is people work rather than system work, and it usually sets the pace of the whole stage; the coordination side of it is covered in "Preparing stakeholders and end users".

A connection that exists can be dropped by ordinary administrative work. A password reset, a change to MFA, or an environment-level admin configuration change on a connected account invalidates the connection, and VaultMe pauses migration until it is restored. Between connecting the source and finishing the scan and the run, avoid those changes; where one genuinely cannot wait, plan it together with reconnecting the affected account. The rest of that housekeeping is in "Pre-migration hygiene on the source".

One reassurance is worth having ready, because it is the objection an environment-wide grant usually raises. A source connection is for reading: VaultMe copies content out of the source and does not modify, delete, or reorganize anything in it. And breadth of authorization is not breadth of use — VaultMe reads and indexes only the resources and content inside the configured migration scope, whatever the grant technically covers. "What VaultMe does not do with customer data" answers that question directly, and showing it to a hesitant administrator sometimes unlocks the grant.

Getting non-user-account resources ready to migrate

This chapter is about the entries on the migration inventory that are not user accounts: shared mailboxes, SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups. If the inventory has none of them, skip ahead.

None of these resources connects to VaultMe on its own. Each is either reached through a connected user account that has access to it, or converted into a user account first — and which path each one takes was already decided when the inventory was built, in "Building the migration inventory". Readiness here is not the decision again; it is carrying the assigned path out and recording that it is done. Two kinds of preparation follow from that:

• Shared mailboxes are converted into regular user accounts. A shared mailbox usually has no license and no password of its own, which is exactly why it cannot be connected. Assigning it a license and credentials turns it into an ordinary user account, and from that point it is connected and read like any other account — most often migrated as archived content rather than as an active seat. This is the one place where licensing is a source-side task, and it is unrelated to the licensing work waiting on the destination.
• Document libraries and the files behind teams and groups ride along with a user. These are migrated inside the file migration of a connected user account that has access to them, so preparing one means naming that user, confirming they are in scope and connected, and confirming they still have access. Where several connected users have access and all of them migrate the same content, each produces a separate copy in the destination, so assign one responsible user per resource and record who it is.

How each of these lands in the destination, and the provider specifics behind it, belong to the dedicated articles. At this stage the job is only to confirm the preparation is complete and noted next to the resource on the inventory sheet, so nothing arrives at the run half-assigned.

Making sure the content is in the cloud

VaultMe indexes and reads only what the connected account exposes in the cloud for the content types in scope. Content that exists solely on an end-user device, or in a different cloud, environment, or account, is not discoverable, and content VaultMe cannot discover does not migrate. This is how a migration finishes successfully and still leaves something behind: the missing items were never visible to VaultMe, so nothing reported them as missing. On a single laptop or phone, several clouds blend into one view, which makes it easy to assume content sits in an account when it does not.

Three sweeps cover almost every case, and each is a question to put to the people who actually use the accounts:

• Email. The mail in scope has to be on the server for the connected mailbox, and the check is simply whether it is visible in Outlook on the web. Where someone runs a desktop mail client configured to download messages and remove them from the server, only a local copy of that mail remains, and it has to be synced back to the server before the migration to be part of it. Where the organization still runs mail partly on its own servers, confirm that the mail in scope lives in the cloud mailbox VaultMe connects to rather than on the on-premises side.

• Files. One device can present several clouds at once — a personal OneDrive alongside the work account's OneDrive — so files routinely end up in the wrong one. Those files are not in the connected account until someone moves them there, and moving them is the only fix. Files that were shared with an account rather than owned by it follow separate rules, which are a content-selection decision rather than a readiness fix; they are covered in "Selecting content for migration".

• Contacts and calendars. Items kept only on a handset, in a local address book, or in a desktop calendar app, and never synced up to the account's cloud contacts and calendars, do not migrate. Confirm that syncing is switched on for those accounts and has actually run.

The task is not to move everything into the cloud right now, and for most accounts there is nothing to move. It is to confirm deliberately, account by account, that what people expect to arrive in the destination is somewhere VaultMe can see it — because the destination will hold what was in the cloud when the migration ran, and nothing else.

This is a question of presence, not of scope. Which content types are migrated at all is a separate decision, made in "Selecting content for migration".

Pre-migration hygiene on the source

The rest of the source-side preparation is light housekeeping. None of it changes what migrates; it keeps the connection intact and takes friction out of the run.

• Trim non-essential third-party apps and automation. Apps, scripts, and integrations connected to source accounts draw on the same provider limits the migration has to work within, so heavy automation running alongside a migration can slow it down. Changes those tools make while a migration is in progress also add reconciliation work afterwards. Disconnect what can safely be disconnected before the run — this is a judgment call about which tools the business can do without for a few days, not a requirement.
• Freeze identity changes on connected accounts. From the moment an account is connected through to the end of the scan and the run, avoid password resets, MFA changes, and environment-level admin configuration changes on it. Each of these can silently drop the connection, and VaultMe pauses until it is restored. Where such a change cannot be postponed, schedule it together with reconnecting the account rather than discovering the pause later.

Nothing else about the source needs tidying, and it is worth saying so plainly to anyone who assumes otherwise. VaultMe copies content: it does not modify, delete, or reorganize anything in the source, which stays intact and fully usable during the migration and after it. If an account holder wants to clean up before the run, that is their choice about their own account rather than something the migration asks for.

What end users should and should not do while their own account is migrating is part of the people side of the project, covered in "Preparing stakeholders and end users". This chapter is the admin-side preparation only.

Confirming the source is ready

Planning and checklists get the source close. They do not prove it is ready. The only proof is a migration project in VaultMe with the source connected and the free pre-migration scan run against the in-scope accounts. A connection that looks perfectly healthy in your VaultMe workspace can still be wrong — the wrong connection link used, permissions approved only in part — and none of that surfaces until something actually tries to read the account.

A source-only project is the normal way to do this. Create the project, connect the source, run the scan, and read the results; the destination is checked separately and later, because a destination can only be judged against the source it will receive. Waiting for the destination to exist before verifying the source just delays finding out what is wrong.

On the source side, a scan tells you three things:

• Whether each account is reachable and readable. VaultMe connects and reads rather than assuming, which is what makes the result worth more than the inventory sheet.
• What is observably wrong, as work you can act on. Anything the providers expose becomes a to-do — one item to fix on one account, such as an account that is suspended, a service that is not switched on, or permissions that fall short of what a migration needs. A shared mailbox converted for the migration but still missing its license shows up the same way. Where the same to-do appears across many accounts, VaultMe groups it into a pending action so the whole condition can be resolved at once. Both are described in "Running the pre-migration scan".
• The real size and item count of every account. These are measured numbers rather than estimates from storage reports, and they are what borderline accounts should be reconsidered against.

The wider set of conditions a migration depends on, and who owns each part of them, is laid out in "Before you migrate".

A clean scan means VaultMe can read the source. It does not mean everything about the source is perfect. The scan cannot see content that never reached the cloud, cannot tell you that an account holder you need next week is on leave, and cannot know which automation is still running against the accounts. Those parts of readiness stay with you, which is why the content sweep above is not something the scan replaces.

Run the scan early rather than on migration day. It is free, it can be run and re-run as often as you like, and its value comes from leaving time to fix what it flags and scan again. Nothing about the project is committed until a batch is paid for and started.

A checklist for source readiness

Run this top to bottom over the source before moving on:

1. The connection method is settled and the source is connected. Either an environment grant is in place from a genuine top-tier admin — a Global Administrator — or every in-scope account has been connected individually.
2. Every in-scope account is active and reachable. Suspended and deactivated accounts have been reactivated, or deliberately dropped from scope and removed from the inventory.
3. Resources that are not user accounts are prepared along the path the inventory assigned each one. Every shared mailbox in scope carries a license and credentials so it connects as a regular user account, and every document library or set of files behind a team or a group has one connected user account with access assigned to carry it.
4. The expected content is confirmed to be in the cloud. Mail is on the server rather than only in a desktop client, files are in the connected account rather than another cloud, and contacts and calendars are synced.
5. Housekeeping is done. Non-essential third-party apps and automation are trimmed, and no password, MFA, or admin configuration changes are pending on connected accounts.
6. A project has been created and the pre-migration scan run against the source. A source-only project is fine. Its to-dos are cleared, and the reported item counts look like what the accounts should contain.

With that, the source is read-ready and a scan proves it, so it can be set aside while the destination gets the same treatment in "Getting the destination ready". None of this locks anything in: everything decided here stays changeable until a batch is paid for and started.