What VaultMe does not do with customer data

Each question below has a short, direct answer about a limit on what VaultMe does with connected accounts and the content inside them. Where a boundary has more behind it than the answer shows, the article that covers it in full is linked.

Does VaultMe copy or move data during migration?

VaultMe copies. For every item in scope, it reads the item from the source account and writes a new copy into the destination account; nothing is removed from the source along the way. The word migration describes the run as a whole, not a removal from one side paired with a placement on the other.

Source content therefore stays in place and stays usable. Messages, files, calendar events, and contacts remain where they were, in the folders and labels they were already in, available to the account holder while the migration runs and after it finishes. Once the migration is done, the two sides are independent: later changes on one side do not reach the other unless a sync-up migration (delta migration) is run.

Because the source survives the migration intact, results can be checked by comparing the two sides item for item, and retiring the source stays a decision you make on your own schedule, once sync-up migrations are no longer needed. How content is copied during a migration run is described in "How VaultMe works".

Does VaultMe change or delete data in the source or destination account?

On the source side, the answer is a plain no. VaultMe reads source content and writes nothing back to it: no edits, no renaming, no refiling, no changes to folder or label structure, and no deletions. This holds for the whole life of the migration, including every sync-up migration (delta migration) that follows.

On the destination side, VaultMe only adds. It writes the copies it creates and leaves whatever was already in the destination account alone — existing content is not deleted, emptied, or reorganized to make space for migrated items. VaultMe does not even inspect what is already there: content placed in the destination by an earlier migration or by another tool is neither reused nor cleaned up, which is why re-running a migration into the same destination produces a second copy rather than a merge. There is also no VaultMe feature that lets you or anyone else delete content in a source or destination account through the app; deletions on either side remain actions your own team performs with the provider directly.

One qualification belongs here, and it operates at the level of individual items. When a source item that was already copied changes later, sync-up migration applies that change to the destination copy VaultMe created for it. If the account holder edited that same destination copy in the meantime, the sync-up overwrites the edit. Where the destination keeps version history for that kind of item, the overwritten version can sometimes be recovered from it; otherwise the change is lost.

The effect is confined to the items involved — nothing else in the destination account is rewritten — but it is the reason end users are asked not to edit already-migrated content in the destination until sync-up is finished. The guidance to pass on to them while their account is migrating is in "Preparing stakeholders and end users", and what a later pass copies or overwrites is in "How sync-up migration works".

Does VaultMe read or migrate user accounts that are not part of the migration scope?

No. VaultMe reads and writes only the user accounts selected for migration. Accounts that were not selected are not read, not indexed, and not migrated, even when the underlying authorization would technically allow it.

How much access the underlying authorization grants in the first place does depend on how each side was connected:

• Admin authorization. An environment — a Google Workspace organization or a Microsoft 365 tenant — is connected once, and the grant is environment-wide by design, because the point of the method is that accounts do not have to be connected one by one. Breadth of authorization is not breadth of use: VaultMe still reads and writes only the accounts selected for migration, and this boundary is enforced by VaultMe's application logic together with the scope you configured.
• Resource-level authorization. Each account is connected individually, and the permissions VaultMe requests cover that one account in its migration role. No other account is connected at all, so there is nothing else within reach.

The same line holds inside a selected account. Only the content types you put in scope are read: if calendars are not part of the migration, calendar items are not opened or indexed either. The one step that precedes that line is the pre-migration scan, which measures every content type when the account is added to a project — structure and counts, not item contents — and then leaves out-of-scope types alone. Shared drives, shared mailboxes, and other kinds of resources are treated no differently — they come into a migration only where you included them in it.

What an environment-level grant does and does not reach is covered in "What data VaultMe processes during migration", and the treatment of content outside the selected scope is covered in "What data VaultMe processes during migration".

Does VaultMe process migration data on end-user devices?

No. A migration runs entirely between clouds. VaultMe reads from the source through the source provider's API, processes content inside its own cloud environment, and writes to the destination through the destination provider's API. No part of that path runs on a laptop, phone, or server belonging to your organization.

Nothing has to be installed for it either: no agent, no browser extension, no local script, no on-premises connector. Devices come into it only as browsers — the one you use to configure and monitor the migration, and the one an account holder uses to open a connection link — and neither browser session carries migration content.

This has a practical consequence worth knowing about. Content that exists only on a device is invisible to VaultMe: mail that a desktop client downloaded and removed from the server, contacts kept only in a phone's local address book, files in a folder that was never synced to the connected account. None of it is discoverable, so none of it migrates. Where migration data is processed and stored is set out in "Where migration data is stored and how long it is kept".

Does VaultMe require or store passwords for connected accounts?

No password for an account connected through OAuth is ever entered into VaultMe or held by it. Connecting such an account is a sign-in on the provider's own page, typically a "Sign in with Google" or "Sign in with Microsoft" prompt, and the password and any multi-factor challenge are handled there by the provider. What comes back to VaultMe is a provider-issued authorization token, not a credential anyone typed into VaultMe.

That token is stored encrypted at rest, is limited to the permissions granted for that account's migration role, and expires on the provider's own schedule. This is the main reason VaultMe prefers OAuth to password-based access: permissions can be set precisely for the role the account is connected in, and the account holder or an authorized admin can revoke that access at any time from the provider side.

One kind of provider sits outside this. A mail system reached over IMAP has no OAuth equivalent to use, so connecting it may require the credentials that protocol expects; those are stored encrypted at rest under the same key management that protects everything else VaultMe holds. This is the exception rather than the rule.

How accounts are connected, and what each connection method grants, is covered in "How VaultMe protects migration data".

Does VaultMe send email or act on behalf of users outside what migration requires?

No. Inside a connected account, VaultMe does two things and no more: it reads the content in scope from the source, and it writes migrated copies into the destination. It does not send email, reply to messages, post to groups, accept or alter calendar invitations, or interact with content that is not part of the migration.

The permissions VaultMe requests are shaped to that division of work. An account connected as a source generally needs read permissions only, while an account connected as a destination needs both read and write. The exact set also depends on which providers are on each side, but it is always the minimum the migration needs rather than a blanket grant. Where accounts are connected individually, the source and the destination even use different connection links, so that each side is asked only for what its role requires.

Writing into the destination is the one action VaultMe performs inside an account on someone's behalf, and it is the action you configured when you set the migration up.

Does VaultMe continue accessing accounts after the customer revokes connection?

No. VaultMe can reach an account only because that account, or the environment holding it, was connected to VaultMe. Once the connection is revoked, VaultMe can no longer read from the account or write to it, and it has no other way in.

Access can be withdrawn from the provider's own account and admin controls, which for an environment-level connection usually means revoking VaultMe's access for the whole environment at once. VaultMe cannot restore access on its own; only a fresh connection, granted again by whoever is authorized to grant it, brings it back.

Revoking access stops the work that depends on that account: a migration in progress pauses until the connection is restored, and sync-up migration (delta migration) cannot start.

What revocation does not do is undo the migration. Copies already written into the destination stay there, the migration report stays available for its retention period, and the high-level record of the run remains. Revocation ends VaultMe's future access to the account; it is not a deletion request. Requesting earlier deletion of migration-related data is a separate route, described in "Where migration data is stored and how long it is kept", and the mechanics of revocation itself in "How VaultMe protects migration data".

Does VaultMe keep user content after the migration retention period ends?

No. When a retention window ends, the data in that category is deleted, using AWS secure-delete mechanisms aligned with NIST SP 800-88 media-sanitization guidance. Nothing outlives the window it falls under.

Content is the shortest-lived category of all. An item staged in temporary storage while it waits to be written into the destination is deleted as soon as the destination provider confirms the write — not at the end of the migration, and not at the end of any longer window.

What VaultMe keeps for the long term holds no content at all. Once temporary storage, the migration index, and the migration reports have been deleted, what remains is a high-level record of the migration: identifiers, start and completion times, item counts and volumes, and the payment reference. It contains no message bodies and no file contents, and none of the metadata derived from them either — no file names, message subjects, or folder and label names. The window for each category, and what expiry actually does to the data in it, are set out in "Where migration data is stored and how long it is kept".

Does VaultMe sell customer data?

No. VaultMe does not sell customer data — not migration content, not the metadata around it, not account or contact details. There is no arrangement under which any of it reaches data brokers, advertisers, or marketing partners, for payment or otherwise.

The commitment is contractual rather than only descriptive: customer ownership of migrated content, and the restrictions on how VaultMe may use it, are stated in the Terms of Service and the Privacy Policy. Where to find both, and how they relate to migration data handling, is covered in "Privacy and legal review".

Does VaultMe use customer content for advertising or AI training?

No. Customer content is used for two purposes: performing the migration you configured, and producing the migration report for it. It is not used for advertising, third-party analytics, AI or model training, profiling, or any other secondary purpose.

There is one place where analytics does appear, and it is worth keeping distinct from the answer above. The VaultMe app and website use a limited set of tools — Google Analytics and Mixpanel among them — that record aggregated signals about how people interact with the VaultMe interface. These tools see the interface, not what lies behind it: they have no access to migration content, to migration metadata, or to anything inside a connected account. Their use is governed by the Privacy Policy rather than by the rules that govern migration data. How VaultMe uses customer content, and the uses it rules out, is covered further in "What data VaultMe processes during migration".

Does VaultMe share customer content with third parties except as needed to run the service?

No. The set of third parties involved in a migration is small and deliberate, and only two of them come anywhere near customer content:

• The source and destination providers. Content is read out of one and written into the other through those providers' own APIs, so it necessarily passes through them. That path runs from your source mail system to Google Workspace and includes no other provider.
• Amazon Web Services. VaultMe's application, databases, storage, monitoring, and key management all run on AWS, so AWS supplies the infrastructure that holds and processes content between the two providers. Nothing is copied out to any other hosting environment.
• Braintree, the payment processor. Braintree handles card payments for paid migrations and returns a transaction reference that VaultMe records against the migration. It has no access to migration content or migration metadata.
• Website and app analytics tools. They record how the VaultMe interface is used and have no access to migration content, migration metadata, or items inside connected accounts.

Nothing goes beyond that list. Migration content is not shared with any third party other than the providers required to perform the migration, and migration metadata — item names, message subjects, file paths, folder and label names — is not shared with advertisers, data brokers, marketing partners, or AI-training services.

Legally binding requests are handled separately from all of this. VaultMe does not volunteer customer data to law enforcement; binding requests are evaluated case by case, and any disclosure is limited to what the law requires. Which third-party services VaultMe relies on and what each one does is covered in "How VaultMe protects migration data".