Building the migration inventory

The migration inventory is the list of user accounts a project migrates, with a decision recorded against each one. This article covers how to build and settle that list when the accounts being migrated are personal Gmail accounts.

What goes into building the migration inventory?

For most businesses moving off personal accounts, this is a short exercise. If there are a handful of user accounts and everyone already knows whose they are, write them down, check that nobody has been forgotten, and go straight on to the next decisions.

The situation behind most of these projects is the same one. A business started out on whatever email its founders already had, took on a few people, added a shared address or two, and never stopped. Now it needs everyone on a new set of accounts, and wants the mail, files, calendars, and contacts that have piled up in those personal Gmail accounts to come across. More often than not the destination is brand new — a Microsoft 365 tenant created for this move rather than one the business has been running for years. Nowhere in that story is there a system that knows which accounts exist. The list is in the owner's head, in a spreadsheet somebody keeps, or in both.

The migration inventory is that list, written down and decided on: every user account the project will migrate, and how each one is migrated. From personal accounts there is nothing else to put on it — no environment sitting above the accounts, and nothing alongside them to bring along — so building the inventory comes down to naming the accounts and settling two things about each one.

What makes this different from a migration out of a business environment is that there is no central administration to work from. Personal providers have no admin console holding a directory you can export, and no single grant that gives VaultMe access to everybody at once. Each user account is connected on its own, and its account holder has to authorize that connection.

That dependency is worth planning around from the beginning rather than treating it as a setup detail. The project moves at the pace of the people behind the accounts: every account you add is an account whose holder has to be found, asked, and walked through authorizing access. How the connection itself works is covered in "Choosing a connection method".

At the larger end of small — a few dozen user accounts rather than five — the list starts to carry real consequences. Migrations are billed per migrated user account, so the inventory is also the budget, and every account on it depends on getting hold of one particular person. That is enough to be worth an hour of planning and a second conversation rather than an afternoon of scrambling on the day.

None of this is work VaultMe can take off you. With no organization to read, VaultMe cannot discover which accounts exist, and it certainly cannot judge which ones matter, who has left, or what the business still needs. Its part begins once the accounts are on your list and connected. The only source of truth for the list itself is the people who know the business.

By the end, the inventory answers two questions for every user account:

1. Is it in scope? Whether the account holds business content the company needs, and whether its holder agrees to it being migrated.
2. Active or archived? Whether someone will carry on working in the destination account, or whether the point is only to preserve what the source account holds.

Both are pulled together in "A checklist for finalizing the inventory" at the end of this article.

How is the migration inventory built?

There is nothing to export. Personal accounts have no central administration over them — no admin console, no directory of who has what, no report to run — and the provider has no idea that six of its accounts belong to the same business. The migration inventory cannot be pulled from anywhere. It has to be reconstructed from what people know.

In practice that means sitting down with the person or people who actually run the business and going through it out loud. Who has a work email address? Which addresses does the business publish or hand out to customers? Who has been handling invoices, the website, or the support queue, and what do they sign in with? Expect the first pass to be incomplete. Accounts surface late — the one used only for a supplier portal, the one a part-timer set up two years ago and still checks — so plan a second round a few days later, once people have had time to remember.

Keep the result in a spreadsheet, built by hand rather than exported. How much that matters scales with the project: with three or four user accounts you can track them in a note, as the count grows a sheet stops things falling through, and once the rollout splits into more than one batch it becomes close to essential.

That last point is worth explaining rather than asserting, even though it rarely bites at this scale. You work in one migration project at a time and launch batches one by one, so a multi-batch rollout is never held open in the VaultMe app all at once. Later stages add to that: confirming accounts are ready means creating a project and running a pre-migration scan against them, and some of those projects are spun up for the check and discarded afterwards. The same sets of accounts get assembled over and over, and the sheet is the one record that survives between them. It also saves retyping, since each launch can take its accounts straight out of it.

One column on that sheet carries more weight than the rest, and it is the one most often left off. Personal accounts are connected one at a time, each authorized by its account holder — there is no license to assign or console setting to flip that connects them centrally. So for every account, record who can actually authorize it. Reaching that person is what holds these projects up far more often than anything technical does.

For each user account, capture:

1. The email address. The personal address as it is actually used, which is what identifies the account everywhere downstream.
2. Who holds it. The person the account belongs to, by name rather than by role, since roles blur in a small business.
3. What it is used for. A few words are enough — customer mail, invoicing, the enquiries address — but they are what makes the keep-or-drop conversation possible later.
4. Whether it stays in use. Whether the business intends to carry on using this address after the migration or retire it. The answer feeds straight into the active-or-archive decision.
5. Who can authorize access. Usually the account holder, but not always: if the person has moved on, note who can sign in as that account instead, or that nobody can.
6. Keep, drop, or archive. Left empty for now. The next two chapters fill it in.

Which accounts actually need to be migrated?

The pool here is small, so this is less about trimming a long list than about being sure of a short one. The risk is not that you pay to migrate a user account nobody needed; it is that the migration finishes and somebody realizes the address the business gave its accountant four years ago was never on the list. The work is making sure every account holding business content has been identified, while deliberately leaving out the ones that should not be touched.

That second half is specific to personal accounts, and it is the part that needs care. These accounts belong to individuals, and some of them mix business and personal content in one inbox — the same address that carries supplier invoices also carries a doctor's appointment and a family thread. Migrating an account means migrating the content that account holds for the content types the project includes, so putting an account on the list is a decision to be made with its account holder rather than for them. Some accounts that look business-adjacent should stay out entirely. Which content types are in scope is a separate decision, covered in "Selecting content for migration".

Cost is a smaller factor here than it would be on a bigger project, but it is worth knowing. Each migrated user account carries a base fee plus fees based on how much data and how many items come across, and a batch costs the sum of its accounts, so the list is also the bill — see "Pricing and payment". At a handful of accounts that rarely decides anything; the binding constraint is usually whether you can get hold of each account holder, not the budget.

For each user account on the list, answer:

1. Does it hold business content the company still needs? Not whether it holds anything at all, but whether losing access to it would cost the business something.
2. Who can authorize access as the account holder? An account nobody can sign in to cannot be connected, and therefore cannot be migrated, however much the business would like it.
3. Is it genuinely a business account, or a personal one that should be left alone? Some addresses only look like work accounts. If the business content in one is marginal and the personal content is not, leaving it out is the right answer.
4. Has the person left? If so, who still needs what is in the account, and who is entitled to decide that it migrates? This is the one question here most likely to need an answer from somebody other than you, so raise it early.

None of these answers are locked in. The list stays a working document until a batch is paid for and started: setup and pre-migration scanning happen before any payment, and the scan reports the real size and item count of every connected account, so a borderline account can be settled with numbers rather than guesses. What the scan does is covered in "How VaultMe works".

Should an account be migrated as active or archived?

The second decision is made per user account, and it comes down to one question: will someone carry on working in the destination account, or is the point simply to preserve what the source account holds and keep it findable?

Out of personal accounts, the first answer is usually the right one. The typical case is a person who has been running their working life out of a personal address and is now getting an account they will use every day, with the migration putting their history into it. That is an active migration, and VaultMe organizes it with the merge method: content is matched to the structures the destination account already has and blends into them, so the person opens their new account and finds their old mail, files, calendars, and contacts where they would expect them.

Archiving is for accounts nobody is going to work in — an account whose holder has moved on, or an address kept only for the record it holds. Here VaultMe uses the separate method: migrated content goes into a dedicated container inside the destination account — a folder of its own, or its own label in a mailbox — named after the source account it came from. An archive therefore sits clearly apart from whatever else is in that destination account, and can be found and pulled back out years later. Both methods are described in "How VaultMe works".

A worked example, since the archive case is the one people hesitate over. A contractor did the company's bookkeeping for two years, corresponded with the accountant from her own address, and has since moved on. The business needs that correspondence and has to be able to produce it on request, but she is not coming back and there is no sense in standing up an account for someone who will never sign into it. Her mail is archived into an account somebody already uses — the office manager's, or a general business account — where it lands in its own clearly labelled container instead of mixing into that person's own mail.

This is a per-account call rather than a project-wide setting, and small projects routinely mix the two. Four current people migrated as active with a couple of departed holders archived alongside them is an ordinary shape for a single batch. Each account's disposition becomes a setting on it when the project is configured — see "Choosing migration options".

The split has a consequence on the destination side that is worth flagging now, because it decides what has to be in place there. Every user account migrated as active needs a destination account of its own for its holder to work in. Archived content does not: several archives can be consolidated into a smaller number of destination accounts, each in its own container. Since destination accounts are licensed per user, that difference shows up directly in what the destination costs to run. What has to be provisioned, and when, is covered in "Getting the destination ready".

How are non-user-account items handled?

The question that comes up at this point is what else belongs on the list. From personal accounts the answer is short: the user account is the only thing VaultMe migrates, so nothing joins the inventory that is not one. That does not make the question pointless, though, because the things missed at this stage are exactly the ones nobody thinks of as theirs. Two kinds are worth sweeping for deliberately, and they end up in opposite places.

• Shared logins, which are still user accounts. Nearly every business grown this way has one or two: an address set up for finance, or support, or a general info line, that several people sign into with the same password. It is easy to skip because it is nobody's personal account, but as far as VaultMe is concerned it is an ordinary user account and belongs on the main list with the rest.

  What it needs is people work rather than technical work. Someone has to be designated to act as its account holder, the people who use it have to agree it is moving and where to, and somebody has to be able to sign in when the time comes to connect it. That last point catches projects out when the password lives in a note nobody has opened since the person who wrote it left.

• Content that lives outside Gmail entirely. A business that grew on personal accounts tends to have filled its gaps with whatever tool fit at the time: a file-sharing service, a notes app, a chat or project tool that has quietly accumulated years of decisions. VaultMe migrates content out of connected user accounts, so anything held in a different service is out of scope and needs a plan of its own — exported by hand, left where it is, or replaced as part of the same move. Naming it here is what turns it into a decision with an owner instead of a gap discovered after the fact.

Neither of these surfaces on the first pass, and they surface the same way when they do. Ask the people who run the business what they actually use in a working day beyond their own inbox: what they sign into, what they share with each other, where things get written down. Shared logins and side tools almost never come up in answer to "which accounts do we have".

Set against a migration out of a business environment, this chapter is short for a good reason. There is no organization or tenant above these accounts and none of the shared structures a business environment accumulates — no shared drives, no shared mailboxes, no sites or groups to untangle. The whole job is making sure every user account that matters is on the list, shared-function ones included, and that everything the business depends on which VaultMe does not migrate has somewhere else to go. The wider boundary of what VaultMe is and is not for is set out in "What is VaultMe".

A checklist for finalizing the inventory

Run through this before treating the migration inventory as settled.

1. The list is complete. You reconstructed it with the people who actually know which accounts exist, and went back a second time for the ones nobody remembered on the first pass.
2. Every account can be connected. For each user account there is a named person who can authorize access as its account holder, and you know that person is reachable.
3. Scope is agreed with the account holders. Every holder knows their account is in the migration, and the personal accounts staying out are out by decision rather than by oversight.
4. Every account is marked active or archived. Active accounts migrate with the merge method into an account someone keeps using; archived accounts migrate with the separate method into a clearly labelled area of their own.
5. The destination accounts for the active ones are confirmed. Each account marked active needs an account of its own on the destination side, and somebody has confirmed those will exist — see "Getting the destination ready".
6. Every row carries a decision. No account is left unresolved on the sheet, including the ones deliberately left out, so nothing is silently assumed either way.

With the list settled, the decisions that follow are all sized from it: which content types come across for each user account, covered in "Selecting content for migration"; how each account is connected, covered in "Choosing a connection method"; and, if there are enough accounts to warrant it, how the rollout is split into batches, covered in "Choosing a migration strategy". None of it is a commitment yet. Setup and pre-migration scanning are free and happen before payment, so nothing is locked in until a batch is paid for and started.