Where migration data is stored and how long it is kept

This article covers where VaultMe hosts and processes migration data, and how long each category of that data is kept before it is deleted. The same locations and retention windows apply to every migration VaultMe runs.

Where is VaultMe hosted?

VaultMe runs entirely on Amazon Web Services (AWS). The website, the VaultMe app, and every component that does the migration work are hosted there. VaultMe operates no data centers of its own, and nothing is installed in the customer's environment.

All of it runs in a single AWS region, us-west-2, whose data centers are located in Oregon, in the United States. Every category of customer data VaultMe hosts — staged migration content, the migration index, migration reports, operational logs, and business records — resides in that region. Under VaultMe's AWS configuration, customer data is not stored in AWS regions outside the United States.

VaultMe does not currently offer customer-selectable hosting regions, and there is no option for in-region storage outside the United States. If a review requires that data be held in a particular country, that is not something VaultMe can accommodate today.

Within the region, the parts of VaultMe that hold customer data are kept off the public internet. The interfaces a browser reaches sit behind load balancers, while storage, databases, and the components that run migrations live in a separate private network that is not directly reachable from the internet; only authorized VaultMe components inside that network can reach the data stores. Everything stored is encrypted at rest with AES-256, under keys managed in AWS Key Management Service. For the network isolation and the encryption controls in more detail, see the encryption chapter of "How VaultMe protects migration data".

Where is migration data processed?

Processing happens in the same environment that hosts the data. Automated VaultMe components running in AWS us-west-2 connect to the source, read the items in scope, hold each one only as long as writing it to the destination requires, and write it into the destination. No part of that work runs on employee workstations, on customer hardware, or on third-party processing systems.

Because both processing and storage sit in the US region, everything VaultMe does with migration data on its own side happens in the United States. The qualification is on the providers' side: reading from the source and writing to the destination happen through those providers' own systems, and where each provider processes or replicates content is governed by that provider's infrastructure rather than by VaultMe. That is covered in "Does migration data pass through connected providers such as Google and Microsoft?".

VaultMe serves all customers from one shared cloud environment rather than a separate deployment per customer. Separation between customers is enforced by VaultMe's own access controls and by AWS identity and access controls, so one customer's migrations, reports, and indexes are not reachable from another's. Migration runs are automated from start to finish; no person carries data from one stage to the next. Who inside VaultMe can reach customer data, and under what circumstances, is covered in "How VaultMe protects migration data".

Does migration data pass through end-user devices?

No. A VaultMe migration is cloud to cloud from end to end. VaultMe reads content from the source through the source provider's API — the programming interface each provider publishes for exactly this kind of access — and writes it into the destination through the destination provider's API. Neither path goes through a laptop, a desktop, a phone, or an on-premises server.

There is nothing to install for a migration: no agent, no browser extension, no script to run, no local connector. As a result, no device ever holds a copy of migration content on VaultMe's behalf. Admins use a browser to configure and monitor migrations in the VaultMe app, but what the browser receives is the app's own interface — project settings, progress, to-dos — not the content being copied.

The one file that deliberately reaches a device is the migration report, which you download from the app when you want it. It lists items and their outcomes rather than their contents, and once it is downloaded, that copy is yours to keep or delete on your own terms.

The same rule has a consequence worth planning around: content that exists only on a device — mail archived into a local file, documents saved to a hard drive and nowhere else — is not visible to VaultMe and is not part of a migration. The cloud-only shape of VaultMe and what follows from it are described in "How VaultMe works".

Does migration data pass through connected providers such as Google and Microsoft?

Yes, and unavoidably so. Every item VaultMe copies is read from the source through the source provider's API and written into the destination through the destination provider's API, because that is the only supported way to reach content held in a hosted account. Each migrated item is therefore handled by three parties: the source provider, VaultMe, and the destination provider.

Which interfaces are involved depends on the providers in the migration:

• Google Workspace and Gmail — VaultMe connects using Google's OAuth 2.0 and OpenID Connect implementations, then reads and writes through Google's Workspace APIs for mail, files, calendar, and contacts, along with the Directory API where an environment is connected by an admin.
• Microsoft 365 and Outlook — VaultMe connects using Microsoft's OAuth 2.0 implementation (Microsoft Entra ID, the "Sign in with Microsoft" flow), then reads and writes through Microsoft Graph and related Microsoft 365 APIs.
• IMAP-compatible mail systems and other providers — VaultMe uses each provider's official API, or a supported protocol such as IMAP where that is what the provider offers.

All of these connections are encrypted in transit with TLS. What a provider then does with the content on its own side — where it processes it, whether it replicates it elsewhere — is governed by that provider's own infrastructure and is outside VaultMe's control. This is worth stating plainly in a review: VaultMe's US-only residency covers VaultMe's side of the migration, not the providers' side.

Provider transit applies to migration content and the item metadata attached to it, and to nothing else VaultMe holds. The migration index, migration reports, operational logs, and high-level migration records are built and kept inside VaultMe's AWS environment; none of them is sent to the source or destination provider. The full list of services VaultMe relies on, and what each one does, is in "How VaultMe protects migration data".

What migration-related data does VaultMe store?

VaultMe holds several kinds of data around a migration, each with its own purpose and retention window.

• Temporary storage — copies of items in flight to the destination, plus the metadata needed to place each one. Deleted as each write is confirmed. What it is, and what it holds, is covered in "Why does VaultMe use temporary storage during migration?".
• The migration index — the record of which destination copy corresponds to which source item, plus the metadata VaultMe needs to detect later changes in the source. Retained for 30 days after the most recent completed run — the initial migration or a later sync-up migration (delta migration). The window and what ends it are covered in "What is the migration index, and how long is it retained?".
• The migration report — the Excel workbook listing every discovered item with its outcome, downloadable from the VaultMe app. One report per migration, retained for one year after the most recent completed run that updated it; each completed sync-up restarts that window.
• Operational logs — records of connection events, token use, migration-run events, and security-relevant events. Retained for approximately three months.
• Connection tokens — the provider-issued OAuth tokens that let VaultMe reach the connected resources, or, for providers that do not support OAuth, the credentials that protocol requires. They are held in an AES-256 encrypted database inside VaultMe's private network for as long as the resource remains connected; revoking a connection ends VaultMe's ability to use them.
• The high-level migration record — that a migration happened: the migration ID, the start and completion times, item counts and data volumes, and the amount paid. It holds no message bodies, file contents, or content-derived metadata. It stays after the stores above are gone. What it contains, and how identifying information is removed on request, is covered in "What types of records may VaultMe keep longer for legal, billing, or operational reasons?".

Why does VaultMe use temporary storage during migration?

During a migration, VaultMe may temporarily stage items in its own storage while they are on their way into the destination. The reason is a mismatch in pace between the two sides: reading from the source typically supplies items faster than the destination provider is willing to accept writes, and the destination is usually the slower of the two. Staging absorbs that gap. The buffer is kept to the minimum size needed to keep writes uninterrupted — just enough staged content that the destination can keep accepting items at its own pace, not a store of everything already read from the source.

The temporary store is therefore a buffer, not an archive. An item is in it because it is waiting to be written, and it stops being in it once it has been. The store is an AWS S3 bucket encrypted with AES-256, inside VaultMe's private network and not exposed to the public internet.

How long does VaultMe keep temporary migration data?

Each staged item is deleted from the temporary store as soon as the destination provider confirms that the item was written successfully. Its stay is bounded by the single write that follows it, not by the length of the migration, so the store holds a working set of items in flight rather than a copy of everything being migrated.

There is one exception. A small residual set of items that could not be migrated may remain in the temporary store after the run finishes, because those items never produced the write confirmation that would have cleared them. Each of those items is deleted 30 days after it was created in the temporary store, on its own schedule — not when the index window ends, and not refreshed by a later sync-up.

Is migration-related data backed up?

VaultMe does not run its own backups of the work-in-progress storage. There is no VaultMe-managed backup copy of staged items, so nothing lingers in a backup after an item is deleted from that store. Durability and redundancy for the bucket come from AWS S3's built-in replication and storage guarantees rather than from a VaultMe backup process.

Databases are handled differently. The databases that hold migration-related data are backed up on AWS-managed schedules and stored encrypted within AWS, under the same key-management controls as primary storage, and encrypted both in transit and at rest. AWS replicates those backups across geographically distributed facilities within the AWS infrastructure VaultMe uses, and that replication stays inside VaultMe's US AWS footprint.

Operational backups are never written to media outside AWS or shipped to physical off-site locations. There is no tape, no removable disk, and no courier anywhere in the picture, which also means the media-handling questions a review usually raises about backups are answered by AWS rather than by VaultMe.

What is the migration index, and how long is it retained?

The migration index is the record of what VaultMe copied and where it put it. For every migrated item, it stores the mapping between the source item and the destination copy VaultMe created, together with the metadata needed to tell whether that source item has changed since it was copied. How the index is built, and what it lists before any copying starts, is in the indexing chapter of "How the VaultMe platform works".

The index exists to make sync-up migration (delta migration) reliable. When a sync-up run examines the source, it consults the index to match previously migrated items to the copies already sitting in the destination, rather than relying on provider-side signals such as message IDs, file names, or change feeds, which are not dependable for this purpose. How that pairing is used on a later pass is in "How sync-up migration works".

The index is retained for 30 days after completion of the initial migration run or the most recent sync-up migration run, whichever is later. Two things follow from that:

• A completed sync-up refreshes the index. If a sync-up migration finishes within the 30-day window, the index is updated and the window restarts from the end of that run.
• An expired window ends sync-up. If no sync-up migration completes within the window, the index is deleted, and further sync-up migrations for that migration are no longer possible without starting the migration over.

This window is the practical limit on how long the destination can keep being topped up from the source, which makes it a scheduling constraint rather than a technicality: the gap between the initial run and cutover has to fit inside it. How that shapes the schedule is covered in "Planning the cutover and domain switch".

The index holds mapping and change-detection metadata only — no message bodies and no file contents — and it stays inside VaultMe's AWS environment for its entire life.

How long are migration reports and operational logs kept?

These two categories outlive the migration itself, and they have different windows and different audiences:

• The migration report is retained for one year. VaultMe builds one Excel report when the initial migration run finishes. Each later sync-up migration (delta migration) updates that same report rather than issuing a new one. The report is retained for one year from the end of the most recent run that updated it; each completed sync-up restarts that window, so the report can be retained indefinitely if sync-up continues.

  Reports are stored in an AES-256 encrypted AWS S3 bucket that is not exposed to the public internet, and you can download them from inside the VaultMe app for as long as they are retained. A report lists items — names, subjects, paths, folder and label names, addresses, and the outcome for each — but never message bodies or file contents.

• Operational logs are retained for approximately three months. These are the records VaultMe keeps of connection events, OAuth token use, migration-run events, and security-relevant events, held in AWS CloudWatch and protected by AWS-managed access controls and encryption.

  Logs are not directly accessible to customers. They can be exported on request, subject to security review; write to support@vaultme.com if a review or an investigation needs them. Like reports, logs record identifiers — the migration ID, email addresses, timestamps — and not the content of any item.

What appears in a report and in a log, in detail, is covered in "What data VaultMe processes during migration".

What happens when retention periods end?

When a window ends, the data in that category is deleted rather than hidden, archived, or marked inactive. Deletion happens inside AWS using AWS secure-delete mechanisms aligned with NIST SP 800-88 media-sanitization guidance. VaultMe does not store customer data on its own media, so it has no media-handling process of its own — decommissioned drives and similar are handled entirely by AWS.

What each expiry means in practice differs by category:

• Staged items disappear as each write is confirmed. Residual items that never produced a confirmation are deleted 30 days after they were created in the temporary store.
• The migration index is deleted 30 days after the last completed run, after which sync-up migrations (delta migrations) can no longer run for that migration.
• The migration report stops being downloadable from the VaultMe app after its one-year window, counting from the most recent run that updated it. If the report needs to survive as a project record — for an audit, a handover, or a dispute about what was migrated — download and archive a copy before then.
• Operational logs age out after approximately three months and can no longer be exported.

What remains after all of that is a high-level record of the migration, plus account and billing records. Nothing in what survives lets VaultMe reconstruct what was migrated: no message bodies, no file contents, and no content-derived details such as file names, message subjects, or folder and label names. That boundary is stated directly in "What VaultMe does not do with customer data", and the records themselves are described in "What types of records may VaultMe keep longer for legal, billing, or operational reasons?".

Can migration-related data be deleted earlier on request?

Yes. You can ask VaultMe to delete migration-related data tied to your VaultMe account before the standard windows end. Requests are evaluated against VaultMe's legal, contractual, and operational obligations and honored where feasible. Send the request to support@vaultme.com, identifying the migrations it covers.

High-level migration records and account and billing records are the exception that is not a refusal. Those records stay, because VaultMe needs them to operate and to meet tax, accounting, audit, and legal-obligation requirements. On request, VaultMe removes from them the information that identifies a person — for example email addresses and other personal identifiers — so what remains cannot be tied back to an individual. How that works, and what a record still holds afterward, is covered in "What types of records may VaultMe keep longer for legal, billing, or operational reasons?".

What types of records may VaultMe keep longer for legal, billing, or operational reasons?

Once the temporary store, the index, and the reports are gone, VaultMe keeps a high-level transaction record of each migration. These records stay, because VaultMe needs them to operate, to comply with applicable laws, to respond to lawful requests, and to enforce its Terms of Service and Privacy Policy.

A high-level record contains:

• The migration ID VaultMe assigned to the run.
• The time the migration started and the time it completed.
• Identifiers for the source and destination resources — today, the email addresses of the source and destination user accounts.
• Item counts and data volumes by content type, both what was requested and what was successfully migrated.
• The amount paid for the migration and the payment-processor transaction ID.

What these records leave out is just as definite. They contain no migration content — no message bodies and no file contents — and no content-derived metadata such as file names, message subjects, folder and label names, or file IDs. A high-level record can show that a migration copied 42,000 email messages on a given date; it cannot show what any of those messages said.

Those records can still identify a person, because they hold email addresses and similar identifiers. On request, VaultMe removes that identifying information. The record itself stays — the migration ID, the dates, the counts and volumes, the amount paid — without the identifiers that would tie it to an individual. The same request applies to account and billing records: VaultMe-account records and billing and transaction records are retained as long as needed to operate VaultMe and to satisfy tax, accounting, audit, and legal-obligation requirements, and identifying information in them is removed on the same request. What those records hold is described in "What data VaultMe processes during migration". Send the request to support@vaultme.com, identifying the migrations it covers.

Retention commitments also survive changes to VaultMe as a business. In the event of imminent bankruptcy, business closure, or VaultMe being discontinued, customers are given at least 90 days to retrieve their reports and any other data still accessible to them before VaultMe-managed retention ends. Through an acquisition or other change of control, the retention and deletion commitments described in this article continue to apply, subject to legal and contractual obligations.

Reviewers who need documentation alongside these answers — what VaultMe publishes today, what can be requested, and what does not exist — should start with "Privacy and legal review".