What data VaultMe processes during migration

This article accounts for each category of data VaultMe handles while preparing and running a migration, and for the data it leaves alone. It is written to be precise enough to answer a security or privacy review.

What types of migration content can VaultMe process?

Migration content is the content copied from the source into the destination — the actual messages, files, events, and contact entries. It is the most sensitive category of data VaultMe handles, and it comes in four content types:

• Email. Messages with their attachments, and the folders or labels that organize them.
• Files and documents. Files held in cloud storage, together with the folder structure around them.
• Calendars. Calendar events, and the calendars that hold them.
• Contacts. Contact entries, and the contact groups that hold them.

Which of these VaultMe actually copies is decided by the migration scope — the content types the admin includes in the migration. A content type left out of scope is not indexed, not copied, and never opened item by item. It is still measured beforehand: the pre-migration scan sizes every content type in an account before the admin narrows the scope, which is covered in "How does the selected migration scope affect what VaultMe processes?". Deciding which types to include is a planning step of its own, covered in "Selecting content for migration".

Within each in-scope content type, VaultMe processes the items the connected source exposes in the cloud, and only those. Mail that a desktop client downloaded and removed from the server is no longer on the provider's mail service, so VaultMe cannot see it. Neither can it see calendar entries or contacts kept only on a handset, or files sitting in a different cloud from the one connected. Content of that kind is not read, not indexed, and not counted — it is invisible to VaultMe rather than excluded by a rule.

Most migrations are migrations of user accounts, and the four types above describe what a user account holds. Shared drives, shared mailboxes, and other types of resources can be part of a migration as well; the same rule decides what VaultMe reads in them.

What user identifiers and metadata does VaultMe process?

Alongside the content itself, VaultMe processes item-level metadata: the identifying and structural information needed to recognize each item, place its copy correctly in the destination, and confirm that it arrived. This is metadata about the content being migrated, and it should not be confused with the information VaultMe keeps about a customer in order to run its service, which is a separate category described further down.

For each in-scope item, that metadata typically includes:

• Names and subjects. Item names such as file names and document titles, message subject lines, event titles, and contact names.
• Location. The item's original location in the source — its folder, label, or path — and the destination location VaultMe selected for the copy.
• Timestamps. When an item was created or last modified, along with the other date fields the content type carries.
• Item properties. The item's content type, its size, and comparable provider-exposed attributes.
• Account addresses. The source and destination user account email addresses a migration runs between.

Metadata is drawn from the content, which makes it nearly as revealing as the content itself: a subject line or a file name routinely names people, projects, and customers. VaultMe treats it that way. Item metadata is processed and protected under the same encryption and retention rules as migration content, not as incidental operational data.

Item metadata is also what VaultMe builds the migration index from — the record pairing each migrated source item with the destination copy created for it, which is what lets a later sync-up migration (delta migration) tell what has changed since the last run. How long that index lives is covered in "Where migration data is stored and how long it is kept".

Metadata at this level is captured during migration, not before it. The pre-migration scan that precedes a run counts items and measures volumes without recording anything item by item; see "How does the selected migration scope affect what VaultMe processes?".

Where a provider exposes an immutable internal identifier for a resource, VaultMe prefers it over a display name, an email address, or a login. Google and Microsoft both expose such identifiers for user accounts, and other resource types can have them too — a shared drive can be referenced by its internal ID even after its display name changes. Where no stable identifier exists, VaultMe falls back to the best one the provider offers, usually an email address or a login.

Does VaultMe process connection credentials or authorization tokens?

Yes. VaultMe cannot read from a source or write to a destination without something that authorizes the access, so for every connected resource it holds one credential for as long as the connection exists. What that credential is depends on whether the provider supports OAuth.

Where a provider does support it — Google and Microsoft both do — connections are made with OAuth 2.0, usually through the provider's own "Sign in with Google" or "Sign in with Microsoft" flow. The person connecting authenticates on the provider's own page, and what VaultMe receives back is a provider-issued token rather than a password. That token has four properties worth stating explicitly:

• It is scoped to a migration role. VaultMe requests the minimum permissions the migration needs, which differ by role: a source connection generally needs read permissions, a destination connection both read and write. In some scenarios the exact set also depends on the combination of source and destination providers.
• It is time-limited by the provider. Provider-issued tokens have provider-defined lifetimes, after which access is denied until the resource is reconnected. Where a provider issues a refresh token alongside the access token, VaultMe stores that too.
• It can be revoked at any time. Revocation happens from the provider's own account, resource, or admin controls, and it ends VaultMe's ability to read from or write to that resource.
• It is encrypted at rest. Tokens are held in an encrypted database that is not reachable from the public Internet, under the same key management as everything else VaultMe stores. See "How VaultMe protects migration data" for the encryption and key-management detail.

Where a provider does not support OAuth — an IMAP-compatible mail system being the case VaultMe meets in practice — the credentials that protocol requires are supplied when the mailbox is connected and stored encrypted at rest under the same controls. This is the exception rather than the default.

How each connection method establishes those credentials in the first place is described in "How VaultMe protects migration data".

Does VaultMe store account passwords?

For user accounts connected through OAuth, no. VaultMe does not request, receive, or store their passwords. The password is entered on the identity provider's own sign-in page — Google's or Microsoft's — and never passes through VaultMe; what VaultMe receives afterward is the token the provider issues.

That distinction matters beyond the storage question. A token carries only the permissions granted for one connection's migration role, and it can be withdrawn from the provider side at any time without changing the account's password or disturbing anything else the account holder uses it for. A shared password, on the contrary, would grant everything the account could do, for as long as that password remained unchanged.

Sign-in to the VaultMe app works the same way. Authentication runs through Google or Microsoft, so VaultMe holds no password for a VaultMe account either; password complexity, multifactor authentication, and password resets all stay with the identity provider.

The exception is a provider with no OAuth support. There, the credentials the protocol requires — a password among them — have to be supplied when the mailbox is connected, and VaultMe stores them encrypted at rest under the same key management as everything else it holds.

The same boundary is stated among VaultMe's other data-handling limits in "What VaultMe does not do with customer data".

How does the selected migration scope affect what VaultMe processes?

The migration scope is what decides how much of a connected environment VaultMe migrates. VaultMe indexes and copies only what the configured scope requires; anything outside it is not indexed and not migrated, even where the underlying authorization would technically permit it.

One step runs before the scope exists, and separating it out is what makes the rest of this answer exact. When a user account is added to a migration project, VaultMe scans it automatically. That pre-migration scan confirms the account is reachable and measures what is in it, which is what the price and timeline estimate is calculated from. Because it has to happen before the admin narrows anything, it covers every content type rather than only the ones that end up in scope.

The scan is a far shallower pass than migration. It uses read access only. It traverses the structure of the account — folders, labels, calendars, and the like — and counts what is there. It does not read message bodies or file contents, it builds no index, and it keeps no item-level record. What remains once it finishes is aggregate figures: item counts and data volumes per content type.

Two admin decisions draw the boundary for everything after that. The first is which resources are in the migration — the inventory of user accounts and other resources the admin assembles and maps to their destinations, described in "Building the migration inventory". The second is which content types are included for them. Resources left out of the inventory are never touched at all: not scanned, not indexed, not copied. Content types left out are measured by the scan and then left alone.

The point reviewers most often need spelled out is that connecting a resource is not the same as processing everything in it. A connection makes a resource reachable; the scope decides what VaultMe reads once it is reachable. If email is the only content type in scope for a user account, VaultMe indexes and copies nothing from that account's files, calendar, or contacts beyond the counts the scan already took, even though the connection would allow it to. That boundary is enforced by VaultMe's own application logic acting on the scope the admin configured, not by the permissions the provider granted.

What the scope governs is migration content and its metadata. It does not govern the records VaultMe keeps in order to operate as a service — a VaultMe account, a billing record for a paid migration, a log of authentication events. Those exist independently of what was migrated, and they are covered in "What account or billing information does VaultMe hold separately from migration content?".

Does VaultMe process data that is not included in the migration scope?

No, with one qualification that belongs up front because it precedes the scope: the pre-migration scan measures every content type in an account when that account is added to a project, at the level of structure and counts described above. Past that point, data stays outside VaultMe's reach in three distinct ways, and it is worth separating them because only the first two are a matter of policy:

• Content types left out of scope are not indexed or migrated, and their items are never opened. The content is reachable through the connection, and beyond the scan's count VaultMe does not go near it.
• Resources left out of the inventory are not read either, including resources an environment-level authorization could technically reach.
• Content not exposed in the cloud is not visible to VaultMe in the first place. Anything held only on a device, or in a different cloud or resource from the one connected, cannot be processed because it cannot be seen.

Reading is not the only thing VaultMe declines to do. It also does not act inside connected resources beyond what performing the migration requires: it does not send email, post to groups, modify calendar invitations, or otherwise interact with content it is not migrating.

The destination is the one place where the answer needs a qualification rather than a flat no. A destination connection grants read access as well as write access, because migrated content has to be placed correctly alongside what is already there. When migrated content is merged into existing destination structures, VaultMe matches source folders and labels to their destination counterparts. That reading is confined to structure. VaultMe does not inspect the items already sitting in the destination — it does not, for instance, check whether an item it is about to copy is already present from an earlier migration.

These boundaries are restated as direct answers in "What VaultMe does not do with customer data".

Does VaultMe access every account in a connected environment?

No, and this is the question where the breadth of an authorization is most often mistaken for the breadth of processing. They are two different things.

When an admin connects an environment — a Google Workspace organization or a Microsoft 365 tenant — the grant is environment-wide and all-or-nothing. The admin approves the full permission set VaultMe requests, with no per-permission picking at connection time, and that permission set technically covers every supported resource in the environment. That breadth is how the providers' admin grants work, not a statement about what VaultMe does with them. The mechanics of the grant, and what securing one asks of the admin who provides it, are covered in "Choosing a connection method".

What VaultMe does with an environment connection happens in three steps:

1. Discovery lists the user accounts in the connected environment, so the admin can see what is there and choose which accounts to migrate. Discovery surfaces the account list; it does not read content inside those accounts.
2. The pre-migration scan runs on each account the admin adds to a migration project, and on no other account in the environment. It sizes that account for the estimate without reading item contents or keeping an item-level record.
3. Migration reads and writes only the user accounts the admin selected, and within them only the content types in scope. Every other resource and everything else in the environment is not read, indexed, or migrated.

Discovery currently surfaces user accounts specifically. Shared drives, shared mailboxes, and other types of resources are not discovered in their own right; they are reached through a connected user account that has access to them.

Resource-level authorization leaves nothing to reason about here at all. Each resource is connected on its own, with authorization scoped to that one resource, so there is no environment-wide grant in the picture.

What appears in migration reports and operational logs?

Two records outlive the migration run that produced them. Both contain identifiers taken from the content; neither contains the content:

• The migration report is a downloadable Excel workbook VaultMe builds when the initial migration run finishes and rebuilds after each sync-up migration (delta migration). It is split into one sheet per content type — email, files, contacts, calendar — and each sheet is divided into skipped items, items migrated with limitations or transformation, and successfully migrated items.

  For every discovered item, the report carries identifying and location fields so the data can be searched, sorted, and filtered: the item name, the message subject for email, file paths, folder and label names, timestamp fields, the destination location VaultMe used, and the source and destination user account email addresses. Items migrated with limitations or skipped come with details about the outcome and why. What the report does not carry is message bodies, file contents, or any other content body.

  Because its fields are drawn from the content, a report still names people, projects, and customers even though it holds none of their contents. That is worth bearing in mind when deciding who inside an organization receives a copy.

• Operational logs are backend records of authentication events, OAuth token uses, migration-run events such as start and completion, the item-level activity needed for monitoring and troubleshooting, and security-relevant events. They may include the migration ID, the source and destination user account email addresses, and timestamps. Like reports, they contain no message bodies and no file contents.

  Logs are not directly accessible to customers. They can be exported on request, subject to security review.

How long each of these is kept is covered in "Where migration data is stored and how long it is kept".

What account or billing information does VaultMe hold separately from migration content?

Some of what VaultMe holds has nothing to do with what was migrated: an account to sign in to, an invoice to reconcile, a record that a migration was run and paid for. Keeping this separate in your own analysis matters, because a billing record that outlives a migration is easy to misread as evidence that content is being kept alongside it.

There are three categories:

• VaultMe account information. The contact details needed to create and operate a VaultMe account — typically the connected user's email address, and for admin users a workspace contact.
• Billing records. For paid migrations, the migration ID, the amount paid, and the payment processor's transaction reference. Payment card details are entered into the payment processor's own hosted fields and are never stored by VaultMe; the services VaultMe relies on and each one's role are listed in "How VaultMe protects migration data".
• High-level migration records. One record per migration, holding the VaultMe-assigned migration ID, the start and completion times, the source and destination user account email addresses, item counts and data volumes per content type — both what was requested and what was successfully migrated — the amount paid, and the payment-processor transaction reference.

High-level migration records are deliberately content-free. They record that a migration happened, between which accounts, and how much content it copied. They hold no message bodies or file contents, and no content-derived metadata either: no file names, no message subjects, no folder or label names, no item identifiers. That is precisely what makes it safe for them to outlive the migration data itself, and the reason retention answers for these records differ from the answers for everything above. See "Where migration data is stored and how long it is kept" for the retention side.

Does VaultMe use customer content for advertising, analytics, or AI training?

No. VaultMe processes customer content for exactly two purposes: performing the migration the customer configured, and producing the migration report that documents it. There is no secondary use — no advertising, no third-party analytics, no AI or machine-learning training, no profiling. Item metadata is held to the same limit and is not shared with advertisers, data brokers, marketing partners, or AI-training providers.

The one exception to "no analytics" is the VaultMe app and website themselves, not migration content. They use a limited set of analytics tools that collect aggregated signals about use of VaultMe's own interface. Those tools see interactions with it and nothing else. They have no access to migration content, to item metadata, or to any item inside a connected resource, and their use is governed by the Privacy Policy rather than by the migration data-handling rules described in the "Security and privacy" section. The Privacy Policy itself is linked from "Privacy and legal review".

The same commitment appears among VaultMe's direct data-handling limits in "What VaultMe does not do with customer data".

Does VaultMe sell customer data?

No. VaultMe does not sell customer data — not migration content, not item metadata, not account or billing information.

Sharing is narrow for the same reason. Migration content passes through only the parties required to run the migration: the source and destination providers' own interfaces, through which content is read and written, and the infrastructure provider that hosts VaultMe. Those are listed with their roles in "How VaultMe protects migration data". Beyond them, migration content is not shared with any third party, and item metadata — names, subjects, paths, folder and label names — is not shared with advertisers, data brokers, marketing partners, or AI-training providers.

Lawful requests are handled on the same principle. VaultMe does not volunteer customer data to law enforcement. Legally binding requests are evaluated case by case, and any disclosure is limited to what is legally required.

This answer is also stated on its own in "What VaultMe does not do with customer data", alongside the rest of what VaultMe will not do with customer data.