Knowledge Center
Microsoft 365 to Gmail Migration Knowledge CenterIntroduction and overviewWhat is VaultMe

What is VaultMe

This article is a first orientation to VaultMe: what it is, who it is built for, and where its boundaries lie. It should be enough to tell whether VaultMe fits the migration project you have in mind.

What does VaultMe do?

VaultMe is a cloud-to-cloud migration service that copies business content from one set of user accounts into another. In a typical project, an admin lists the source user accounts, points each one at the destination user account that should receive its content, and VaultMe copies email, files, calendars, and contacts across — account by account, item by item. The full sequence, from the first connection to the final report, is walked through in "How VaultMe works".

Nothing can be read or written until the accounts are connected. Every source user account VaultMe reads from, and every destination user account it writes into, has to be connected to VaultMe first. Connecting an account means the provider that hosts it grants VaultMe permission to work with that account's content; until that permission exists, VaultMe cannot reach the account at all.

Shared mailboxes, SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups can be migrated too. They have to be connected as well, and the kinds that qualify are listed in the non-user-account resources chapter of "Building the migration inventory".

The word "migration" suggests content leaving one place and arriving somewhere else, but that is not what happens. VaultMe copies content. It reads each item from the source and creates a new copy of that item in the destination, and it never modifies, deletes, or reorganizes anything in the source. Source accounts stay intact and fully usable both while a migration runs and after it finishes.

That has two practical consequences worth knowing early. Because the source is untouched, the result can be verified by comparing the two sides afterwards. And because nothing is taken away, deciding when — or whether — to retire the source accounts stays a customer-side decision, made after the destination has been checked, rather than something the migration forces.

Once content has been copied, the two sides are independent of each other. Changes made in the source afterwards do not appear in the destination on their own; picking them up requires a sync-up migration (delta migration), a follow-up run that copies what has changed since the previous one.

VaultMe is cloud-to-cloud only. It reaches both sides through the providers' own interfaces, so content has to be held in the cloud by a connected account to be visible at all. Mail that a desktop client has downloaded and removed from the server, contacts kept only in a phone's local address book, files sitting on a laptop or an external drive — none of that is discoverable. On a device, several clouds and local storage often appear blended into one view, so content that is not in the connected account can easily look as though it is. Confirming that the expected content really is in the cloud is part of preparing the source, covered in the cloud-content chapter of "Getting the source ready".

Who is VaultMe intended for?

VaultMe is built for IT administrators running migrations on behalf of an organization, usually multiple user accounts at a time. That assumption runs through the whole VaultMe app and through the rest of this Knowledge Center: you are migrating other people's accounts, and you answer for the outcome. VaultMe is optimized for small and medium-sized projects — roughly 5 to 500 user accounts.

The work is organized as a project. A migration inventory lists the user accounts to migrate, and other resources alongside them, each with its own destination and its own treatment. Scope and options are settled in a planning stage before anything runs. Accounts are grouped into batches that start, progress, and finish as a unit. Every account in the project reports its status in one place. Payment is handled centrally by whoever runs the project rather than by each account holder; how that is calculated is covered in "Pricing and payment".

An admin can connect an organization's environment to VaultMe once, approving access at the environment level; every user account inside it is then connected automatically, with nothing asked of the people who hold those accounts. Accounts can also be connected one at a time with resource-level authorization, each connection authorized for that account alone, usually by the account holder opening a connection link.

Which method is used changes who does the setup work and how much of it there is. The trade-offs are laid out in "Choosing a connection method".

One case sits outside all of this. An individual migrating a single account they hold themselves — a personal account, or a work or school account they are leaving — uses VaultMe Personal, a separate self-service app. It covers one source user account migrating into one destination user account, run by the account holder, without the admin role, batches, or central oversight that a project needs. The migration technology underneath is the same; VaultMe Personal presents only what a single-account migration needs.

The rule of thumb: many accounts migrated on behalf of an organization means regular VaultMe, and one account migrated by the person who holds it means VaultMe Personal. The distinction is about who owns the accounts, not what kind they are — a batch of personal Gmail or Outlook accounts migrated by an admin for an organization is still a VaultMe project.

What content can VaultMe migrate?

VaultMe migrates business content: what people create, receive, and file inside their accounts. There are four content types, and a migration can include one of them, several, or all four.

  • Email — the messages in a mailbox, together with the folders or labels they are filed under and the attachments they carry.
  • Files — documents, spreadsheets, images, and other files in an account's cloud file storage, together with the folder structure they are organized into.
  • Calendars — the events in an account's calendars, together with the calendars that hold them.
  • Contacts — the contact entries in an account, together with the contact groups they are organized into.

In every case VaultMe works one item at a time and aims to recreate each item as precisely as the destination allows, keeping structure, formatting, and whatever metadata the destination accepts. Structure is a deliberate part of the job rather than a side effect: a migrated mailbox should arrive organized the way it was organized before, not as an undifferentiated pile of messages.

All four content types are available for a Microsoft 365 to Gmail migration, in any combination. Most projects take all four at once, so that end users find their complete working set waiting for them on the day they switch over.

Anything that is not one of these content types falls outside what VaultMe migrates, even when it sits in the same account. Photo libraries such as Google Photos, browser bookmarks, uploaded videos on services such as YouTube, and task or to-do lists are the examples that come up most often: they belong to the same provider ecosystem, but they are not email, files, calendars, or contacts, so VaultMe leaves them alone. Deciding which content types a project should include, and what that leaves for someone to handle by hand, is covered in the content-types chapter of "Selecting content for migration".

Which providers does VaultMe support?

VaultMe is built and tuned for two ecosystems, Google and Microsoft, and supports IMAP-compatible mail systems on top of those for email alone. That focus is deliberate: other providers are supported, but the priority is doing Google Workspace and Microsoft 365 migrations well.

  • Google Workspace — Google's offering for organizations. Accounts belong to a domain and are managed centrally by the organization's administrators.
  • Microsoft 365 — Microsoft's offering for organizations. Accounts live in a tenant and are managed centrally by the organization's administrators.
  • Gmail — Google's personal accounts, held by individuals rather than by an organization.
  • Outlook — Microsoft's personal accounts, such as Outlook.com addresses, held by individuals rather than by an organization.
  • IMAP-compatible mail systems — any mail service that can be reached over IMAP, including mail hosted by providers such as Zoho Mail and GoDaddy. Exchange is supported on the same basis. Because IMAP carries mail and nothing else, these are supported for email migrations only.

Both cross-provider and same-provider combinations are ordinary VaultMe work. A company leaving Google Workspace for Microsoft 365 is a routine project, and so is a company consolidating two Microsoft 365 tenants after an acquisition, or personal Gmail and Outlook accounts arriving in an organization's environment, or mail coming out of an IMAP-compatible system into either ecosystem.

Microsoft 365 and Gmail do not organize every content type in the same way, so a handful of things cannot be reproduced exactly as they were. Where the destination has no direct equivalent for something on the source, VaultMe writes the closest faithful representation the destination supports rather than dropping the item, and content arrives recognizable and usable even where its original shape has no counterpart. When an item can only be created with some transformation, VaultMe notes that in the migration report, so nothing changes quietly.

What is VaultMe most often used for?

Migration projects tend to fall into a handful of recurring situations. What follows is not a list of supported features — the mechanics are the same in every case — but recognizing which pattern a project fits usually answers several planning questions at once.

  • Switching service providers is the most common one. An organization decides to leave Google Workspace for Microsoft 365, or the reverse, and every user account has to arrive on the new side with its history intact before people start working there. Such a project takes every content type that is in scope and sets up each account so that migrated content merges into the destination as though it had always been there.

  • Mergers, acquisitions, and reorganizations produce a variant of the same shape, usually on a deadline set by the deal rather than by the IT calendar. Content from one organization's environment has to join another's. The hard part is rarely the copying: two organizations have different domains, different account naming, and different conventions for how things are filed, so working out which source account maps to which destination account is where most of the effort goes.

  • Onboarding and offboarding employees is the small, repeating version of the same work. Someone joins from another organization and brings their history with them, or someone leaves and their work has to stay with the team, and one account — or a few — is migrated into an existing destination. These runs are short and happen often, which is why the same project structure that handles hundreds of accounts also handles two without extra ceremony.

  • Archiving accounts that are no longer in use is the pattern where the content has to survive but the account does not: a license being released, an employee leaving, a contractor finishing. Retention or compliance policy says the content must be kept, so it is migrated into a destination account the organization controls, and usually kept clearly separate there so it does not mix with whatever else that account holds. Choosing between merging content into a live destination account and keeping it separate is one of the per-account decisions covered in "Building the migration inventory".

These patterns are illustrations rather than boundaries. Any content migration between supported cloud providers is a candidate, whatever the reason behind it, and the setup is the same either way.

What is VaultMe not designed for?

VaultMe is a content migration tool, and several adjacent jobs resemble it closely enough to be mistaken for it. Each distinction below describes a need VaultMe does not meet, and each is worth checking before a project starts.

  • VaultMe is not a backup service. A migration is a one-time copy, followed by a bounded period of sync-up migrations (delta migrations) — follow-up runs that copy what changed in the source since the previous one. There is no version history to roll back to, no snapshots, no scheduled protection of an account over time, and no copy of migrated content held by VaultMe. Where the requirement is ongoing protection against accidental deletion or corruption, that is a backup product's job. How VaultMe handles migration data is described in "Privacy and security".

  • VaultMe is not a synchronization service either. Sync-up migration exists to bridge one specific gap: the days or weeks between the initial copy and the moment the organization actually starts working in the destination. Each pass copies changes made in the source since the previous run, in one direction only, and the ability to run further passes lasts for a bounded window rather than indefinitely. It is not a mirror — deleting an item in the source does not delete the copy already made in the destination. The intended pattern is to transition and then retire the source, not to keep both sides running in parallel. The mechanics are covered in the sync-up chapter of "How VaultMe works".

  • VaultMe does not clear out the source. Because it copies rather than moves content, everything stays where it was, and emptying, closing, or decommissioning the source accounts is customer-side work that happens after the destination has been reviewed and accepted. VaultMe neither performs that step nor requires it, and offers no feature for deleting content in a connected account; the boundaries around what it will and will not do to customer content are stated directly in "What VaultMe does not do with customer data".

  • VaultMe does not reach anything that is not in the cloud. Content has to be held by a connected account with a supported provider and reachable through that provider's interface. Local mail stores, files on a workstation or an external drive, and anything on a phone that never synchronized to the account's cloud are all out of reach, and there is no agent, connector, or upload path that brings them in.

  • VaultMe is not an administration or configuration tool. It fills accounts with content; it does not build the environment those accounts live in. It does not create or license destination user accounts, carry account settings or mailbox configuration over, restructure domains, or change DNS. Administrative structures do not migrate either: groups and their memberships, distribution lists, room and equipment mailboxes, public folders, aliases and proxy addresses, and environment-level configuration all belong to the environment that holds them and have to be recreated by an admin on the destination side.

That surrounding work is real, and it stays part of the project even though it is not part of what VaultMe does. What has to be in place before a migration can run is covered in "Before you migrate", and the customer-side steps that complete the switch once VaultMe has finished are covered in "Planning the cutover and domain switch".

Ready to start your migration with VaultMe?

Start your migration