Creating a migration project

This article covers the opening moves in the VaultMe app: getting from the landing screen to an empty migration project that is ready for accounts, and the few choices made on the way that are worth getting right the first time.

What does creating a migration project involve?

Creating a migration project is a few minutes of clicking, and it commits you to nothing: no content is touched, no account is connected, and nothing is charged.

Two terms run through the rest of this section:

• Project. What you assemble before paying: a provider pair, a list of user accounts, and the options that apply to them. It stays editable throughout, and abandoning it costs nothing.
• Batch. What the project becomes the moment it is paid for — a group of user accounts migrated together in one run. A migration of any size is carried out as one or more batches.

Payment is the line between the two names, and crossing it ends the configuring: the setup screens are replaced by the interface for the batch.

Two decisions made during creation outlive the clicking:

• The sign-in identity. You sign in once, and that account becomes the identity your VaultMe workspace and everything accumulated in it are tied to; switching later is not a rename — see "Which account should I sign in with?".
• The provider pair. It changes freely while the project is empty, but once the project has accounts, changing the pair means discarding them — see "What can be changed after the project is created?".

What you end up with is an empty project bound to a provider pair, Microsoft 365 on one side and your destination mail system on the other. The only route forward is adding accounts, which is also where the source and destination get connected — see "Connecting and adding user accounts".

One thing worth knowing before you start: VaultMe keeps no list of your projects. There is no dashboard, no recent-projects panel, and nothing anywhere that names the project you are about to create. Projects are reopened by selecting the same provider pair instead, which is the subject of "Where is my project when I come back?".

How is a project created?

1. Open the VaultMe app and select Multi-account migration.

   The welcome screen asks which kind of migration you are here for before it asks you to sign in. "Multi-account migration" is the one badged for admins: it is the administrator app, where many user accounts are migrated together in one project. The other choice, "Single account migration", opens VaultMe Personal, which copies one person's content from one account to another.

2. Sign in with a Google or Microsoft account.

   Those are the only two identity providers on offer. There is no VaultMe password and no other way in. Which account you use deserves a moment's thought before you click, because it becomes the identity your VaultMe workspace is tied to — see "Which account should I sign in with?".

   Signing in for the first time automatically creates your VaultMe workspace — your working area in the app, holding every account you connect and every batch you run.

3. Select Microsoft 365 on the Migrate from card, and IMAP on the Migrate to card.

   The list of providers is longer than the number of migration paths VaultMe actually has, because several entries are shortcuts onto the same IMAP path. If the mail system you are migrating from or to has an entry of its own — Yahoo Mail, iCloud Mail, and Exchange among them — take it; if none names it, take the entry for any other mail system with IMAP enabled. Either route sets that side up as an IMAP-compatible mail system for the rest of the project.

   Once both sides are set, the screen offers a guide written for your Microsoft 365 to IMAP-compatible mail system migration: VaultMe AI Expert with suggested questions to start from, a link to this Knowledge Center, and the same guide as a downloadable PDF.

4. Select Create migration project.

   The project is created and its screen opens empty: no accounts yet, and no price or duration until the pre-migration scan runs — see "Running the pre-migration scan".

   The field to read is Status, which names whatever stands between the project and a migration. On a new project it reads Waiting for user accounts, and Ready to migrate once nothing is outstanding; in between it reports what is left to resolve, such as a count of pending actions.

5. Optionally, rename the project by clicking its title on the project screen.

   VaultMe suggests a name based on the providers and accounts in the project, and keeps it current until you replace it with one of your own. The name carries into the batch and identifies the migration in your workspace afterwards, which matters as soon as the workspace holds more than one batch — whether they belong to a phased rollout or to different customers. Nothing is closed off here: the name can be changed later, on the batch as readily as on the project.

The next step is adding accounts, which begins with connecting the source and destination. This flow is covered in "Connecting and adding user accounts".

Which account should I sign in with?

Any Google or Microsoft account you own will do. The account you sign in with identifies you in VaultMe: it grants no access to either side of the migration, it is not checked against the source or the destination, and it does not have to belong to either of them. Access to the accounts being migrated is granted separately, later, when the source and destination are connected inside the project — see "Connecting and adding user accounts".

What the identity does buy you is the VaultMe workspace, created automatically the first time you sign in. The workspace is where everything durable accumulates: every account you connect, and every batch you have paid for, in whatever state it ended up. Signing in is the only route back to any of it — to a migration's status while it runs, to its report afterwards, and to any sync-up migration (delta migration) you run later to catch changes the first pass missed.

That gives a single criterion worth applying: durability. The identity has to stay stable and accessible for the whole project, and preferably well past cutover, because it is the only door to the record of what you migrated.

The trap is signing in with an identity that will not outlive the source. If the source is decommissioned after cutover and that identity goes with it, you lose access to your own migration records, reports included. This one is easy to walk into: if you already hold an administrator account in the source, it might be the obvious one to sign in with. Use any Google or Microsoft account of your own instead, ideally one that is not tied to either side of the migration.

Switching identity later is not a rename. Signing in with a different account gives you a different workspace, with its own connected accounts and its own migration history; work done under the first identity is not visible from the second, and there is no self-service way to merge them or move anything across. If you have started under the wrong identity and it matters, that is a conversation to have with support at support@vaultme.com rather than something to fix in the app.

If you run migrations repeatedly — as a consultant, or a partner working across customers — the recommendation is a work identity of your own, belonging to neither the source nor the destination of any particular job and reused from one customer to the next. Every migration you have run then stays reachable from one place, and none of it retires when a customer's source does.

Where is my project when I come back?

It is still there. Opening VaultMe lands you on the welcome screen, which shows no project list and nothing that names what you were working on. To reopen the project, select Multi-account migration and sign in with the account you used to create it. Then select the same provider pair — Microsoft 365 on Migrate from, IMAP on Migrate to — and it returns exactly as you left it, with its name, its accounts, and its options intact. Selecting a provider pair is how a project is both created and reopened.

An unpaid project is not stored in your workspace. While it is being configured it is a draft, and the draft is held in your browser. Four things follow from that:

• A different machine shows nothing. Configure a project on your desktop, open VaultMe on a laptop that evening, and selecting the same pair gives you a new empty project rather than the one you were working on.
• A different browser on the same machine shows nothing either. The draft belongs to the browser it was created in, so switching from one browser to another has the same effect as switching computers.
• Clearing browsing data removes it. A privacy clean-up, a managed device policy, or anything else that wipes browser data takes the draft with it.
• Signing out removes it as well. This is the one to watch, because it is the only one you do on purpose: signing out leaves your connected accounts and your paid batches untouched, so it looks harmless, but the project you were configuring does not survive it. Leave the tab be, or finish and pay, rather than signing out mid-setup.

A draft lost this way cannot be recovered, and support cannot restore it. What is lost is the configuration: the provider pair, the account rows, and the content options, all of which can be entered again. Connected accounts and paid batches are held in the workspace rather than in the draft, so they are unaffected — accounts stay connected, and every batch you have paid for stays where it was, whether it is waiting to start, running, or finished.

One part of the setup does go with the draft, but it is less of a setback than it first appears. If you connected the source or destination environment as an administrator, that connection is held in the project rather than the workspace, so it is not restored along with everything else. The user accounts it connected are, though: they stay in your workspace and remain usable, which means a lost draft can be rebuilt without connecting either environment again. Admin access only comes back into it for accounts your workspace does not already hold. How a project is rebuilt from what the workspace still has is covered in the rebuilding chapter of "Connecting and adding user accounts".

Reopening a project by selecting its provider pair works only while it is unpaid. Once payment has gone through, selecting the pair gives you a fresh empty project instead: payment converts the project into a batch and clears the draft, so there is no draft left to restore. The batch is in your workspace's migration history from the moment it is paid for, and that is where you go to start it or watch it run. What payment commits you to, and how a paid batch is started, are covered in "Paying for and starting a batch".

The insurance against a lost draft is the same thing that lets a colleague pick up your work, and it is covered next, in "Can I build several projects, or share one with a colleague?".

Can I build several projects, or share one with a colleague?

Both answers are no, and both follow from one fact: the project you are configuring is a draft in your browser. A browser holds one draft, and no other browser can see it. What makes this chapter worth reading is not the two refusals but what to do instead, which turns out to be the same answer for both.

Only one draft can exist at a time, and it occupies that slot until the project is paid for. A phased rollout is therefore built one wave at a time: configure a wave, pay for it — which converts it into a batch and releases the slot — and only then begin the next. Waves cannot be staged in advance, and there is no way to keep a half-finished second project parked while you work on the first. Each new project after the first begins from My workspace, through Start New Migration. How a rollout is split into waves in the first place is a planning decision, made before any of this and covered in "Choosing a migration strategy".

A colleague cannot open your draft either, and being a member of the same workspace does not change that: membership shares what is in the workspace, and a draft is not in it. Membership is also not self-service — additional admins are added to a workspace by VaultMe support on request, by writing to support@vaultme.com.

What membership does share is the expensive half of the work. Every member sees the same connected accounts and the same batches, and each can create projects and start batches independently of the others. Authorizations are therefore done once and reused: an account a colleague connected last month is available to you today, and no account holder is asked to authorize the same account twice.

Which leaves the practical answer to both questions: keep the account list outside the VaultMe app. Held as source-and-destination pairs in a spreadsheet, it pastes straight into VaultMe's account-list screen, which makes building a draft a few keystrokes for whoever needs one. That single habit covers all three cases — it is how two admins collaborate on a migration, how a lost draft comes back, and how each wave of a phased rollout gets built. It is also not extra work: the list is the migration inventory that planning produces anyway, and keeping it is discussed as part of that work in "Getting ready for a migration".

That is a real answer rather than a consolation, because rebuilding a draft is pasting, not deciding. Who is in scope and where each account's content lands were settled during planning, and the VaultMe app takes the rows as they stand. The mechanics of getting them back in — pasting the two columns and having the project return with every account paired — are covered in the rebuilding chapter of "Connecting and adding user accounts".

What can be changed after the project is created?

Only two things are project-level settings: the name and the provider pair. The rest of what you configure sits inside its own screens rather than in the project's settings — the accounts in the batch are covered in "Connecting and adding user accounts", and the content types and organization method in "Choosing migration options".

The name changes in place: click the project title and type a new one. VaultMe keeps the suggested name current until you do, and leaves yours alone afterwards. This is the one setting never closed off — the name carries through into the batch and can still be changed there, just as easily.

To change the pair, select Settings on the project screen, then Change on the Migrate from or Migrate to card, and apply with Update settings. On an empty project the new pair takes effect immediately, with no confirmation asked — there is nothing in the project for it to affect.

On a project that already has accounts, it is a different act entirely. The pair cannot be changed while the accounts stay: VaultMe interrupts with a warning that a migration project already exists, reports the non-empty project it found, and makes you choose between two options:

• Keep existing project. Reverts the change and leaves the project as it was.
• Discard existing project. Applies the new pair and removes all of the project's content.

Nothing added so far carries over to the new pair, so changing the pair on a non-empty project and discarding the project are the same act.

Discarding a project is not as costly as it sounds. If the account list is kept in a spreadsheet, its rows paste straight into the rebuilt project, so what has to be redone is the pasting rather than the deciding — see "Can I build several projects, or share one with a colleague?". Any connection you made to the source or destination environment is discarded too, on the side whose provider you did not change as well as the one you did — but the user accounts those connections brought in stay in your workspace, so the rebuilt project draws on them rather than needing either environment connected again.

None of this applies to the provider pair once the project has been paid for. It is reachable only while the project is a draft; after payment the project screen is replaced by the batch interface, and the pair is fixed as it stood. The name is the exception, and can still be changed on the batch. Changing course at that point is no longer a configuration question but a commercial one, and what payment covers, along with how refunds and re-runs work, is set out in "Pricing and payment".