Building the migration inventory

This article covers how to build the list of resources that will be migrated out of the source, and how to decide what belongs on it.

What goes into building the migration inventory?

On a small project this is a short exercise. A handful of user accounts, everybody still with the organization, nothing shared that anyone needs to keep — then everyone moves, the list is short, and it takes minutes to write down. If that describes the project, do exactly that, and skim the rest of this article for the two or three points that apply.

The migration inventory is the list of resources leaving the source, with a decision recorded against each one. Generally speaking, a resource is a place in the cloud that holds business content and is migrated as a unit; and the user account is by far the most common one. Everything in the environment falls into one of three groups:

• User accounts. The bulk of almost every inventory, and the subject of most of this article: which of them are worth migrating, and how each one is migrated.
• Resources that are not user accounts. These hold business content too, but they are usually shared and often have nobody who obviously looks after them. Shared mailboxes, SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups all fall into this group. VaultMe can migrate them, but none of them travels automatically and each needs preparation first.
• Things VaultMe cannot migrate at all. Group structures, addresses that are not accounts, and environment-level configuration are administrative wiring rather than content, and VaultMe does not migrate them. They still belong on the list, so that nothing is quietly assumed to be coming along.

The deeper work in this article earns its keep on the bigger and murkier projects: dozens or hundreds of user accounts, some of which are not worth the spend; people who left years ago whose content somebody may still need; shared resources nobody has thought about since they were created. Large migrations usually qualify, small ones rarely do, so read the chapters that match the project and skip the ones that do not.

On anything beyond a small project, this is also the decision everything else waits on. The batch split, the connection method, the schedule, and the price are all sized from this list, which is why it comes before them rather than alongside them. Nothing further can be planned with any confidence until the list exists.

Past a handful of user accounts, the inventory stops being a purely technical list and becomes a budget decision. VaultMe bills per migrated user account, so every account that stays on the list adds to the invoice, and the total usually needs sign-off from someone other than the admin running the migration — management, department heads, or whoever holds the budget. Plan for at least one round of review rather than an afternoon of guessing; a first draft of the list rarely survives circulation unchanged.

None of these calls belong to VaultMe, and it cannot make them. It does not know who left the organization last year, whose content still matters, who is going to keep working in a destination account, or which shared resources the business actually relies on. Its part starts once the inventory exists and the resources on it are connected: from that point it can discover the user accounts inside a connected environment, scan them, and report exactly how much content each one holds.

Worked through, this article produces four things:

1. The user accounts in scope. Which of them are migrated, and which are dropped.
2. A decision for each one. Whether the account is migrated as an active account someone keeps working in, or archived so its content is preserved and stays findable.
3. The other resources included. Which resources that are not user accounts come along, and how each of them is migrated.
4. A record of what is out of scope. Written down, so nothing is silently assumed to be migrating when it cannot.

The final chapter folds all four into a single checklist.

How is the migration inventory built?

Start with the user accounts, because they are most of the migration inventory and the only part of it that can be produced mechanically. Every managed environment keeps a central directory of its user accounts and can export it. In a Microsoft 365 tenant, that directory lives in the Microsoft 365 admin center. Producing the export is admin-side work in the source environment: VaultMe does not generate the list and never needs to receive it.

Turn the export into a spreadsheet. How much that matters scales with the project. For a handful of user accounts it is optional and an informal list is fine. As the count grows it becomes genuinely helpful. Once the rollout splits into more than one batch, it is close to essential.

The reason for that last point is worth spelling out, because it is about how VaultMe is used rather than how a spreadsheet is useful in general. The VaultMe app works on one migration project at a time and launches batches one by one; a multi-batch rollout is never held open in the app all at once, so there is no in-app view of the whole plan. Later stages assemble the same groups of user accounts repeatedly — temporary projects are commonly created to run a pre-migration scan and confirm that a batch's accounts are ready before the real run, so a given set gets put together again for scans, for the launch itself, and for any re-runs. The spreadsheet is the only place the cross-batch picture exists. It also saves the retyping: when a batch's turn comes, its addresses can be filtered out and pasted straight into VaultMe's account-list screens. How the batches themselves are tracked is covered in the batch-tracking chapter of "Choosing a migration strategy".

From here on the sheet is the backbone of the project. Nearly every later decision adds a column to it: whether the account is migrated at all, active or archived, which content types it takes, how it connects, which batch it belongs to, and whether it is ready. Most of those columns are filled in later, which is not a reason to start the sheet later — the rows are the same rows either way.

For each user account, capture at least:

1. The source email address. The account's identifier for the rest of the project, and what eventually gets pasted into VaultMe.
2. The person or function behind it. A named individual, a role address that the business still uses, or nothing at all.
3. Its current state. Active, suspended, or belonging to somebody who has left.
4. A department, or a person who can answer for it. Who to ask when the account's fate is not obvious from the directory.
5. An empty column for the decision. Keep, drop, or archive — filled in over the next two chapters.

One thing the directory export will not contain is the resources that are not user accounts, since they do not appear in a user directory at all. Keep a short second section or a separate tab for them; a project that has none can ignore this. Which of them VaultMe can migrate, and how, is covered in "Which non-user-account resources can VaultMe migrate?".

The tool and the format are the admin's call. Most teams use Excel or a Google Sheet, and VaultMe has no opinion on the matter: it requires no plan document, no template, and no upload. The sheet exists for the people running the migration, not for the app.

Which user accounts actually need to be migrated?

This chapter is a single pass over the user accounts on the list, deciding which of them are actually migrated. The useful mindset is trimming rather than collecting. A directory that has been running for a few years holds far more accounts than anyone wants to pay to migrate: deactivated accounts nobody ever removed, former staff kept on "just in case", test and service accounts created for a project that ended, duplicates left behind by a rename.

Cost is the reason to be strict. Migration is billed per migrated user account, so every account kept on the list adds to the total, and that tends to change the tone of the conversation: once each account has to be justified, stakeholders start cutting the list rather than growing it. The common arc is a full directory export that comes back noticeably shorter. What each account costs is set out in "Pricing and payment".

One question stalls this exercise more often than any other, and it is rarely the admin's to answer alone: does a departed employee's content still matter? Sometimes it does, for a legal or retention obligation, for business continuity, or because a handover was never finished. Sometimes nobody has looked at it in three years. Answering it needs management or the relevant department, and it is the single item most likely to turn "we will finish the list today" into "we will finish it next week". Raise it at the start of the exercise rather than at the end.

For each user account on the list, work through:

1. Is there a person or an active function behind it? An account that nobody uses and nothing depends on is the easiest thing to drop.
2. If the person has left, does anyone still need the content, and who decides? Name the decision-maker rather than guessing on their behalf.
3. Is it a duplicate, test, or service account that has outlived its purpose? These are usually obvious once someone reads the list properly, and they are pure cost if they stay.
4. Is the account reachable? A suspended or deactivated account cannot be read as it stands, so it either gets resolved before the run or stays out of scope. Resolving it is part of the source-readiness work in "Getting the source ready".
5. Is there a legal, compliance, or retention obligation attached to it, whoever used it? An obligation outranks the cost argument, and it applies to accounts that would otherwise be dropped without a second thought.

Nothing here is locked in. No commitment is made until a batch is paid for and started, and the free pre-migration scan reports the real size and item count of every connected account, so borderline cases can be revisited with numbers instead of guesses. The scan is described in "How VaultMe works".

Should a user account be migrated as active or archived?

The second decision is made for every resource that survived the first one, and it comes down to purpose: is somebody going to keep working in the destination account, or does the content only need to be preserved and stay findable? The first case is an active migration, the second an archive. VaultMe puts the content in a different shape for each:

• Active accounts use the merge method. Migrated content blends into the destination account that person will work in, whether they are already using it or it was provisioned for them ahead of the migration. VaultMe matches source structures to their equivalents in the destination, so the account holder finds migrated content where they expect it rather than in a separate copy of the source.
• Archived accounts use the separate method. Migrated content goes into a dedicated container inside the destination account — a folder, or the destination's equivalent of one, named after the source account — with the source structure rebuilt inside it. Nothing mixes with what is already in the destination, and the whole archive is easy to locate and recover from later.

Because the two methods produce visibly different destinations, this decision is worth making deliberately rather than accepting a default. What each method does to the destination is described in "How VaultMe works", and the disposition recorded here becomes a per-account setting when the project is configured — see "Choosing migration options".

The clearest case for archiving is the departed employee whose content is kept for continuity or for legal reasons. Nobody is going to work in that account, so standing up and paying for a fresh destination account for someone who has left is wasted money. Archiving it instead puts the content into an existing or consolidated destination account, in its own labelled container, where it can be produced when somebody asks for it.

This is a per-resource decision, not a single project-wide setting, and one project routinely mixes both: current staff migrate as active, while everyone who left over the past few years lands as an archive. Resources that are not user accounts need the same decision, but it is not made for them separately: each of them is migrated inside a connected user account, so it inherits the call made for that account. The exception is a shared mailbox, which becomes a user account in its own right before it is migrated, and so gets a call of its own — usually archive. The next chapter covers which resources these are and how each one travels.

The split also has a direct consequence for the destination, which is why it is settled now rather than during setup. Every account migrated as active needs a destination account of its own, provisioned and ready before the run. Archived content can be consolidated, with several source accounts landing in one destination account and each sitting in its own container, which keeps the number of destination accounts and the cost of hosting them down. Provisioning the destination to match the split is covered in "Getting the destination ready".

Which non-user-account resources can VaultMe migrate?

Beyond user accounts, the migration inventory can include other resources that VaultMe migrates. They are not accounts: they are usually shared, they often have no single person responsible for them, and they always need some preparation before they can be migrated. If the environment has none that anyone still needs, skip this chapter.

There is one assumption worth correcting before anything else. Connecting the environment reaches the user accounts inside it, and only those: VaultMe discovers user accounts, and a shared resource does not come along merely because the environment it lives in is connected. What connecting an environment does and does not cover is described in the admin-authorization chapter of "Choosing a connection method". The resources easiest to miss are exactly the ones nobody thinks of as theirs, so gather them deliberately — a pass with IT and with management before the inventory is finalized — rather than waiting for somebody to notice after cutover.

Two kinds of resources qualify here, and they are migrated in completely different ways:

• Shared mailboxes. A shared mailbox is usually unlicensed, has no password of its own, and is not a normal account, so there is nothing for VaultMe to connect to as it stands. To migrate one, convert it into a regular licensed user account by assigning it a license and credentials. It then becomes connectable, joins the main user-account list, and is treated exactly like any other account from that point on — including the active-or-archive decision from the previous chapter, which for a shared mailbox is usually archive.
• SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups. These are migrated inside the file migration of a connected user account that has access to them, not as resources in their own right. Every connected user account with access migrates its own copy, so a library visible to five people who are all in the batch arrives in the destination five times. Pick one account holder to carry each one across, and write down which one; switching them off for every other account is done when the project's migration options are set, as "Choosing migration options" describes.

Record the path each of these resources takes next to the resource on the sheet, along with the name of whoever carries it. That record is what gets executed later: preparing each of them is covered in "Getting the source ready".

It is worth being plain about how far the VaultMe app goes today. These resources can be part of the migration inventory, but the app does not treat them as first-class units the way it treats user accounts: it does not connect to one, scan it, or bill it on its own. Everything reaches them through a user account — either one that carries the resource, or one the resource was converted into.

That shapes the bill in a predictable way. A resource carried inside a connected user account adds no migration fee of its own; its content simply counts towards that account's data and item volume. A shared mailbox converted into a user account, by contrast, is a user account for billing too, and carries the same per-account fee as any other. How these resources are priced is set out in "Pricing and payment".

What can't VaultMe migrate?

Some of what lives in the environment is not a migratable resource at all. These are administrative structures rather than places that hold business content — the wiring that organizes people and addresses, not the content itself. Listing them while the migration inventory is being built is worth the few minutes it takes, because it turns them into work somebody has planned for rather than a gap discovered after cutover.

The main items are:

• Microsoft 365 Groups and Teams. The group or team as a structure, and its membership, are not migrated.
• Distribution lists. These are addressing structures rather than accounts, and are not migrated.
• Resource and room mailboxes. These belong to the tenant's configuration rather than to any user account.
• Public folders. These are not migrated.
• Alias and proxy addresses. An alternate address on an account is not an account, and is not migrated as one.
• Service and automation accounts as identities. Whatever integration or script an account exists to run does not come across with it.
• Tenant-level settings. How the environment itself is configured stays behind.

The line that matters here runs between structure and content, and it is easy to blur. What cannot be migrated is the structure: who belongs to a group, what an address points at, how the environment is configured. The files behind a Team or a Microsoft 365 Group are content, and they can be migrated through a connected user account that has access, as the previous chapter describes. The team itself — its membership, its channels, its configuration — cannot.

Stated once and plainly: VaultMe migrates in-scope content out of connected resources. It does not create user accounts, migrate groups and their memberships, or carry over environment-level settings, because those are administrative structures rather than resource content. Anything on the list above is recreated by hand on the destination. The wider boundary is drawn in "What is VaultMe".

For that reason, record each of these items on the sheet as well, alongside the other resources that are not user accounts, with a name against every one. An item written down with somebody's name next to it becomes manual follow-up work that has been scheduled; the same item left off the list becomes a surprise.

A checklist for finalizing the inventory

Everything above, in one pass. Run it top to bottom; the migration inventory is finished when every line is true.

1. Exported the user directory into a spreadsheet, one row per user account, with the source address and enough context to answer for each one.
2. Reviewed every user account and dropped the ones that are not needed — deactivated accounts, departed staff whose content nobody needs, test and service accounts, duplicates.
3. Secured sign-off on the trimmed list from management or the relevant department heads, and specifically on the keep-or-drop call for departed employees.
4. Marked each surviving user account active or archived. Active accounts merge into a live destination account; archived accounts are kept separate inside one.
5. Swept the environment for resources that are not user accounts and assigned each one a path — converting a shared mailbox into a licensed user account, or naming the account holder who carries a document library or a Team's files across.
6. Listed what is genuinely out of scope — group structures and memberships, addresses that are not accounts, room and resource calendars, environment-level settings — and gave each item a name for manual follow-up.
7. Confirmed what the active-and-archive split requires on the destination with whoever is responsible for it: a destination account ready to receive each active migration, and consolidated destinations for archived content. Any shared mailbox being converted into a user account counts here too.
8. Recorded a clear decision on every row, so no row is left blank and no resource is migrated, or left behind, by accident.

With the inventory settled, the next decisions build directly on it. "Selecting content for migration" covers which content types each account migrates, "Choosing a connection method" covers how each resource is connected to VaultMe, and "Choosing a migration strategy" covers how the rollout splits into batches. None of it is a commitment: everything stays reversible until a batch is paid for and started.