How VaultMe works

VaultMe migrations follow a fixed sequence, from the first sign-in to a finished batch with its reports. This article explains how that sequence works and what VaultMe is doing at each point in it.

Where does VaultMe run?

VaultMe is cloud-based and runs entirely online. The VaultMe app opens in a browser, and from your side that is the whole of it: you sign in, connect the accounts you are migrating, set the migration up, and follow it from the same screens. There is nothing to install and no scripts to run.

That is worth saying outright, because migration tooling often turns up in a heavier shape — an agent installed on a server, a connector that has to sit inside the network, a job scheduled on a machine that then has to stay awake until it finishes. VaultMe has none of those parts. Both sides of a migration are already cloud services reachable over the internet, so the work belongs in the cloud as well; running it there is a deliberate choice rather than a corner that was cut.

Every interaction with a provider goes through that provider's standard API — the documented interface a provider publishes so that approved software can read and write content on an account's behalf. Content therefore passes from the source provider's cloud into VaultMe's cloud and out into the destination provider's cloud, and nowhere else: no end user's device sits in that path, and neither does the laptop you set the migration up on. Where VaultMe's own cloud sits, and what it holds while a migration runs, is covered in "Privacy and security".

In practice, a browser is all you need to set up a migration and to oversee it. Nothing day to day depends on infrastructure of your own — no server to keep patched, no machine that has to stay online overnight, no local software to keep current. A migration already under way carries on when you close the tab, and a colleague can pick up oversight of it from their own browser.

What does a migration look like from start to finish?

Every project moves through the same sequence. You tell VaultMe what to migrate, VaultMe examines the accounts and reports back what it found and what it will cost, you pay, and then VaultMe does the work while you watch.

In the order the stages naturally fall:

1. You sign in to VaultMe, which creates a workspace for you — the working area where user accounts are connected and migrations are run.
2. You select the source and destination providers for the migration. That selection is what tells VaultMe which permissions to request on each side.
3. You connect the user accounts. Every source account VaultMe will read from, and every destination account it will write into, has to be connected before anything can happen with it.
4. You create a migration project: the list of source accounts paired with the destination accounts that will receive their content, along with the content types in scope and how the arriving content should be organized. A project is configuration only — nothing has run, and every part of it can still be changed.
5. VaultMe runs a pre-migration scan against the accounts in the project. The scan reports readiness problems as to-dos you can work through, and measures how much content each account holds, which is what the price and the duration estimate are calculated from.
6. You check out and pay for the batch. This is the first stage in the sequence that requires payment.
7. You start the batch, and VaultMe works through the migrations in it without further input from you.
8. VaultMe runs a sync-up migration (delta migration) after each migration's initial run, picking up whatever changed in the source account while that run was going. Further sync-ups can be run as often as needed in the stretch before the cutover.
9. You download the migration report for each migration and deal with anything that needs manual attention in the destination.
10. The customer switches over to the destination and retires the source on their own schedule, long after VaultMe's part is finished.

Two VaultMe terms carry through the rest of this. A migration project is the editable configuration described in step 4; a batch is what it becomes once it is paid for and started — the collection of migrations that run together. A single migration is one source user account being copied into one destination user account, so a batch covering forty accounts is forty migrations, each tracked, reported on, and completed individually.

Notice where payment sits in that sequence. Signing in, connecting accounts, building a project, and scanning are all free, and no payment method is required to do any of them; you can scan, fix what the scan found, and scan again as many times as you need. Up to checkout, everything is reversible at no cost — change the pairings, add or drop accounts, change the content types, disconnect an account, or abandon the project altogether. Checkout is the point where a configuration becomes a paid run, and the details of what is charged and when are covered in "Pricing and payment".

Each of these stages carries more than one line's worth of detail, and the chapters below open up the ones that matter most: connecting the accounts, what the pre-migration scan looks for, and how a batch behaves while it runs. Where this sequence sits inside the wider project — the decisions and readiness work that come before step one — is the subject of "Getting ready for a migration".

How does VaultMe access source and destination?

VaultMe can read from a source user account, or write into a destination one, only because the provider granted it permission to. That permission is given the way any other app's is: someone with the authority to grant it signs in with the provider, sees what VaultMe is asking to be allowed to do, and approves it. What differs from one project to the next is who that person is and how far a single approval reaches — an account holder authorizing their own account, or an administrator authorizing a whole environment at once.

None of it happens behind the scenes, and none of it leaves VaultMe holding the keys to an account. With Google and Microsoft accounts the password is typed on the provider's own page and never reaches VaultMe, which is issued a grant by the provider instead; where a provider offers no such flow, the credentials that protocol requires are supplied to VaultMe and stored encrypted. What VaultMe ends up with is the same whichever way the access was arranged, and it is what VaultMe uses to reach every connected account: access that exists only because someone deliberately granted it, that covers only what was approved, and that the provider can withdraw at any time. "Privacy and security" covers what that access amounts to.

What gets connected are the user accounts on each side of the migration. Every source account has to be connected before VaultMe can read anything from it, and every destination account has to be connected before VaultMe can write anything into it. The two roles are not the same: a source connection needs permission to read, a destination connection needs permission to read and write, and in both cases VaultMe asks for the narrowest set of permissions the role requires.

Shared drives, shared mailboxes, and other resource types have to be connected as well, though not all of them in their own right. What that involves varies by type, and "Getting the source ready" covers what each one needs.

There are two connection methods, and what separates them is how well they scale.

• With connection using admin authorization, an administrator connects an entire environment — a Google Workspace organization or a Microsoft 365 tenant — in a single grant, after which VaultMe can reach the user accounts inside it without anyone signing in account by account; one approval covers every in-scope account there.
• With connection using resource-level authorization, each account is authorized on its own, usually by sending a connection link to its account holder, so the work grows with the number of accounts in the project.

An admin grant is possible only for Google Workspace and Microsoft 365; Gmail, Outlook, and IMAP-compatible mail systems are always connected one account at a time. The two sides of a migration are decided independently, so plenty of projects use one method on the source and the other on the destination. "Choosing a connection method" weighs the two up and sets out what each one takes to arrange.

Whichever method is used, connections have to stay live for as long as VaultMe needs them. VaultMe works from the connected accounts themselves rather than from a copy taken earlier, so every item it migrates involves a live read and a live write. When a connection drops part way through a run — a password reset, a change to multi-factor authentication policy, an administrator revoking the grant — VaultMe pauses that migration and waits for the connection to come back instead of failing it outright. Nothing already copied is lost or undone, and the migration carries on from where it stopped once access is restored. How a connection works as a channel — what it carries, what it can reach, and what a drop does — is covered in "How VaultMe authentication works".

What does the pre-migration scan do?

Up to this point VaultMe has been working from what you told it. The pre-migration scan is where it goes and looks for itself: for every user account in the project, it checks that it can actually reach the account, that the services matching the content types in scope are available and responding, and what content is really there. It is the first stage that produces facts rather than configuration, which is why so much of the project hangs off it.

The scan produces two things.

• The first is a readiness verdict: for every user account, VaultMe either confirms that it can migrate the account or reports what has to be put right first, which you can then fix and scan again.
• The second is measurement: how many items each account holds and how much storage that content occupies. Those numbers are what the per-account price and the duration estimate are built from, which is why neither can be quoted accurately before a scan has run.

The scan looks and measures; it does not migrate. Nothing is written to the destination during a scan, and no content is copied or staged for migration — running one changes nothing on either side.

That makes the scan the natural decision point. Scans are free and need no payment method, so you can run one, work through the to-dos it raised, and run it again until the project is clean, without committing to anything. Because the figures come back per account, you can also see which accounts are large or expensive before you pay for them, and trim the project accordingly. Nothing is charged until you check out, and how the final price is assembled from scanned figures is covered in "Pricing and payment".

Two limits are worth knowing in advance. The duration estimate is a projection rather than a commitment, and it can shift once VaultMe observes how the accounts actually behave under load. And the scan can only judge what it can observe through the providers — it cannot tell you whether the domain plan is settled, whether end users have been told what is coming, or whether the cutover date is realistic. A clean scan means VaultMe can start; it does not mean the project is ready. "Before you migrate" draws that line in full.

How does VaultMe migrate content?

The first thing to know is that VaultMe copies content rather than moving it. It reads each item from the source user account and creates a copy of it in the destination account, and it does not delete, modify, or reorganize anything in the source along the way. When a migration finishes, the source holds exactly what it held before; "migration" is the name of the workflow, not a description of what happens to the content. That has a practical benefit beyond peace of mind: because both sides still exist afterward, results can be verified by comparing them.

Each migration starts by building an index of the source. Before any copying begins, VaultMe lists every item it can discover in the content types you selected, and that listing defines the work: those are the items VaultMe will attempt, and their count is the count you see it working through. Items added to the source after the index is complete are not part of that pass; catching up on them is a separate step, covered in "How are post-migration changes handled?".

VaultMe then works through the index item by item, generally starting with the most recently created or modified content, though the exact order is not guaranteed. For each item, the goal is the most faithful copy the destination is technically capable of holding — structure, formatting, and the metadata that goes with the item, preserved as far as the destination's own rules allow.

There is no export file, no archive, and no intermediate copy of the whole account sitting anywhere. Items stream one at a time from the source provider's API to the destination provider's API. Destinations generally accept writes more slowly than sources supply reads, so VaultMe may hold an individual item briefly in its own encrypted storage while the destination catches up, and releases it as soon as the destination confirms the write; "Privacy and security" covers what is held and for how long.

Three consequences follow from working this way, and they explain most of what a migration looks like from the outside:

• Both connections have to stay live for the whole run, because every item involves a live read and a live write.
• An interruption — a dropped connection, a provider limit, a problem item — pauses progress instead of corrupting it, since each item either finished or did not.
• Results accumulate: copied items appear in the destination as they complete, so a migration that is half done is a half-populated destination account, not a broken one.

Not every item arrives unchanged. Some cannot be created at the destination at all, because of a provider restriction or a permission the destination will not grant, and those are skipped. Others arrive in a slightly different form — a document converted to a format the destination supports, or a name shortened or adjusted because it broke a destination naming rule. VaultMe records what happened to every indexed item, so the outcome is something you can audit rather than guess at. What specifically changes shape depends on the content type and the two providers. The operating model behind that path — provider APIs, the index, and what happens to each item — is in "How the VaultMe platform works".

How is migrated content organized in the destination?

Where migrated content lands in the destination is set by the content organization method. There are two of them, and you choose one per user account; which one fits depends on what the destination account is for.

• The merge method puts migrated content where its equivalent already lives. VaultMe matches each folder in the source to the corresponding folder in the destination and adds the arriving items there, alongside whatever is already in it — mail from the source inbox joins the destination inbox, and the rest of the source's structure is rebuilt in its natural place. Migrated items are always added as new entries; VaultMe never overwrites something that was already in the destination.

  Merge is the method for an account holder who is switching over and will carry on working in the destination.

• The separate method keeps everything migrated in an area of its own, so what arrived and what was already there stay visibly distinct. For content types built around folders, such as email and files, VaultMe creates one dedicated folder — usually named after the source account's address — and rebuilds the source structure inside it. For content types with no folders to nest into, such as contacts and calendars, it marks the migrated items with a naming prefix or an equivalent marker instead.

  Separate is the method for archiving, where the migrated content is kept for reference rather than becoming anyone's working set — whether it lands in an account someone already works in or in one set aside to hold archived content.

The choice is made per account and then applied to every content type in scope for that account, so an account's email, files, calendars, and contacts all follow the same approach. Different accounts within one batch can be set differently, which is what makes a mixed project workable: the accounts of people who are switching to the destination are merged into their new accounts, while accounts belonging to people who have left are archived into a manager's account with the separate method. Where the method is set, and how it is set for many accounts at once, is covered in "Choosing migration options".

Beyond that, the specifics of where a given item lands depend on the destination provider and the content type — how the destination names its standard folders, what it does with structures that exist in the source but have no equivalent there, and how it handles anything it cannot place exactly.

What happens while a migration is running?

Once a batch starts, VaultMe runs it. There is nothing to keep open, nothing to keep awake, and no step that waits on you between one migration and the next — the migrations run on VaultMe's own infrastructure and continue overnight and through weekends. Your role changes from configuring to monitoring, which for most batches means checking progress occasionally rather than sitting with it.

User accounts stay usable while they are being migrated. Migrations are designed to run without downtime, so people can keep working in the source throughout, and ordinary activity does not by itself cause anything to fail. Whatever they change while the run is under way is picked up afterward by a sync-up migration (delta migration). The destination deserves more caution: end users should stay out of their destination account until their migration finishes, and above all should not reorganize content that has already arrived, because VaultMe may then have to redo work to restore the structure it expects — which costs time and makes the final result less predictable.

Work happens in parallel, at two levels. VaultMe generally migrates the accounts in a batch alongside each other rather than one after another, and within a single account it processes the content types alongside each other too, so email, files, calendars, and contacts advance together. A batch therefore does not complete in the order the accounts were listed; everything progresses at once and finishes at different times, with the largest and most complex accounts setting the moment the batch is done. The one deliberate exception is contention: when several migrations would write into the same destination account, VaultMe schedules them one after another so they are not competing for that account's capacity with the provider.

Speed is set by the providers, not by VaultMe. There is no internal throttle to lift and no faster mode to switch on — VaultMe continuously runs as fast as the connected services will accept, and the providers impose limits on how many operations they will serve per minute and over longer windows to protect their own services and keep usage fair across their customers. In practice the destination is usually the narrower channel, because accepting writes is heavier work than serving reads, so migrations often wait on the destination even when the source could supply content faster. "What determines migration duration" goes through the factors that make a particular batch fast or slow.

Because of those limits, slowdowns and short pauses are normal operating behavior rather than symptoms. When a provider tightens up, throughput drops and the migration keeps going more slowly; when a longer quota window is exhausted, a migration can pause outright until that window resets. VaultMe keeps monitoring and retrying throughout and restores full speed on its own as soon as capacity comes back. Pausing and restarting a migration by hand does not shorten any of this and often lengthens the total run.

What genuinely needs you is the exception rather than the routine. The VaultMe app shows the state of every migration in the batch on the batch progress page, and a migration that has stopped making progress appears as Paused; opening its details tells you what is holding it up — most often a connection that has dropped and needs restoring. Everything else, including individual items that need retrying, is handled without you.

What happens after migration?

When VaultMe has finished with a user account, three things are true: the destination holds copies of what was in the source, there is a report describing exactly what happened to each item, and the source is untouched. It is worth taking each in turn, because the report in particular is more useful than most admins expect.

The migration report is the primary artifact. VaultMe builds one for each migration as soon as its initial run completes, and rebuilds it after each sync-up migration (delta migration) so it always reflects the latest state. It is an Excel workbook you download from the VaultMe app, with one sheet per content type — email, files, contacts, and calendar — and each sheet is divided into three sections: items that were skipped, items that migrated with limitations or transformation, and items that migrated cleanly. For every item, the report gives the fields you need to find it again, such as its name, its original location in the source, and its timestamps, along with the destination location VaultMe chose for it. Anything skipped or transformed carries an explanation of what happened and why. Each report is kept for a year from the end of the run that produced it.

That makes the report the answer to nearly every post-migration question. When an end user reports that something is missing, the report says whether it was indexed, where it went, or why it could not be created — usually faster than searching the destination account. And because the source is still intact, anything the report leaves unclear can be settled by comparing the two accounts directly.

Some content types may also come with a TODO area in the destination. When VaultMe cannot place an item where it should have gone under the normal organization rules, it migrates the item anyway rather than dropping it and puts it somewhere obvious instead: a dedicated folder for content types that have folders, or an equivalent marker where they do not. A TODO area appears only for a content type that actually has items needing attention, and its purpose is simply to collect them in one place so the person who owns the destination account can review them and file them where they belong. Most migrations produce few or none.

Finally, the source is exactly as it was. Nothing was removed from it, moved within it, or reorganized in it, and VaultMe offers no feature to clear it out afterward. From the moment a migration completes, the two accounts are independent — changes on one side do not appear on the other unless a sync-up migration copies them across. Retiring the source, and deciding when, is entirely the customer's call, and it belongs to the cutover rather than to the migration; "Planning the cutover and domain switch" covers how that is planned.

How are post-migration changes handled?

Because VaultMe indexes the source before it starts copying, the result is effectively a snapshot of the source as it stood when that index finished. Mail that arrived an hour into the run, a document someone edited on the second day, a calendar invitation accepted while a user account was being migrated — none of it is in the destination when the run ends. On a migration measured in days, that gap is not a rounding error.

The sync-up migration (delta migration) closes it. VaultMe runs one automatically after every initial migration, and each pass copies what changed in the source since the previous run: items that are new, and updates to items already migrated. It is incremental rather than a repeat of the whole migration. VaultMe keeps an index pairing each source item with the copy it created in the destination, so unchanged items are left alone and already-migrated content is never duplicated. As cutover approaches you can run further sync-ups from the VaultMe app for accounts that are not currently processing, and sync-ups of a reasonable size are included in what you have already paid.

It helps to be clear about what a sync-up is not, because the name invites bigger assumptions:

• It is not continuous synchronization. Each pass is a discrete run in one direction, from source to destination, not a live link between the two accounts.
• It is not a backup. There are no snapshots, no version history, and nothing to restore from; what you have is a destination account that has been brought up to date.
• It is not a mirror. Deleting an item in the source does not delete its copy in the destination, and if a previously migrated item changes in the source, the sync-up overwrites the destination copy — so edits made on the destination side to migrated content can be lost.
• It is not indefinite. A sync-up has to run within 30 days of the previous one. Once that window lapses, the pairing index is deleted, and bringing the destination up to date after that means migrating the account from scratch.

What sync-up is built for is bridging: it carries the source's late changes across so the destination is current at the moment the customer switches over, which is what allows the migration itself to run comfortably ahead of the cutover date instead of racing it. That is also why it is not meant to keep two systems aligned for months. Planning the run and the cutover around that window is the subject of "Planning the migration timeline" and "Planning the cutover and domain switch". The windows, limits, and operational behavior of a pass are in "How sync-up migration works".

What does VaultMe NOT handle when running a migration?

VaultMe fills user accounts with content. It does not build the environment those accounts live in, configure the services they run on, or change how mail is routed to them. It is a content-migration tool rather than an IT automation suite, and the boundary between the two is sharper than it first looks — plenty of work that feels like part of "the migration" sits firmly on the customer's side of it.

That work includes:

• Creating and licensing destination accounts. VaultMe writes into a destination account that already exists; it does not provision accounts, assign licenses, or set passwords and identity policy.
• Turning on and configuring the services those accounts use. If mail, file storage, calendars, or contacts are in scope, the matching service has to be active on the destination account before VaultMe can write to it, and account-level settings such as forwarding, delegation, rules, and signatures are configured by whoever administers the account.
• Domains and mail routing. Proving ownership of a domain at the destination provider, and the DNS work that follows — including the MX change that actually redirects mail delivery — stays with the customer.
• Administrative structures rather than content. Groups and their memberships, distribution lists, aliases, room and equipment mailboxes, and public folders are configuration of the environment, not content held in an account, and VaultMe does not carry them over.
• End-user device setup. Reconfiguring desktop clients, phones, and tablets to point at the new account is done by the people who use them.

The list is the shape of the work rather than a complete inventory, and none of it is a gap in VaultMe. VaultMe asks for the smallest set of conditions it needs to copy content correctly, and leaves the rest of the environment to the people who own it. Much of that work is also not a prerequisite: mail can keep flowing to the source while VaultMe migrates, because migration runs through provider APIs and has nothing to do with mail delivery. "Before you migrate" goes through the conditions admins most often wait on unnecessarily.

The second boundary is physical. VaultMe reaches only what a connected account holds in the cloud, so an end user's device is outside its world entirely — it has no access to the mail client on a laptop, the address book on a phone, or a local drive. Content that exists only in one of those places is not visible to VaultMe and simply will not migrate: messages a desktop client downloaded and removed from the server, contacts that were never synced to the user account, files kept in a personal drive rather than in the connected account. Getting that content into the connected account beforehand is part of source readiness, covered in "Getting the source ready". The wider picture of what VaultMe is and is not built for is in "What is VaultMe".