Connecting and adding user accounts

Every migration project starts empty. Filling it means connecting user accounts to VaultMe, adding the source accounts, and assigning each one a destination — all of which happen in the same place in the app.

What does connecting and adding accounts involve?

A small project is quick work. A handful of user accounts is one panel and a single pass on the Simple tab, and none of the background in this chapter is needed to get through it, so go straight to "How are source accounts added to the project?".

Two concepts behind how VaultMe connects to accounts underpin the rest of this article.

• Connecting an account is what gives VaultMe access to it. A connection is the channel content is read through on the source side and written through on the destination side, and there is no other way in: an account that has not been connected is one VaultMe cannot see, and both sides have to stay connected for as long as the migration runs. What that channel consists of and why it is the only one is covered in "How VaultMe authentication works".
• Accounts reach VaultMe by one of two connection methods. Either an environment is connected once, after which VaultMe can connect its user accounts by email address, or each account is connected on its own, by whoever holds it opening a connection link. Which connection method each side uses is not decided here. That was settled during planning, and this article carries the decision out rather than reopening it; the trade-offs behind it are in "Choosing a connection method".

The VaultMe app is designed around one workflow: source accounts are added to the project first, and destination accounts are then assigned to them. The two can happen in a single pass or in separate ones, but a destination is always assigned to a source account that is already in the project. All of it happens in one place. Add accounts is the only action a new project offers, and the panel it opens is where the rest of this article takes place: connecting accounts to VaultMe, handing out connection links, selecting accounts into the project, and pairing each source with a destination.

Two facts about how the app handles those connections explain most of the behavior this article describes.

• Accounts are connected to your VaultMe workspace, not to a project. Your workspace keeps every user account that has ever been connected to it, and it keeps them across projects. A project never holds a connection of its own; it draws on what the workspace already has. The connecting itself is started from inside a project, which makes the distinction easy to miss, but what it produces is a workspace account — available from then on to every project you build.
• Connecting an environment is a way to connect accounts in bulk, not a standing requirement. Accounts have to stay connected for a migration to run; the environment they were connected through does not. Connecting one lets VaultMe connect accounts by email address without their holders signing in to anything, and those accounts then belong to the workspace — so the environment can be disconnected the moment it has served its purpose, and a project can be built with none connected at all.

Together those two facts are worth more than either is alone. Connecting is the half that involves credentials and other people, and it is done once, against the workspace, so its results outlive any single project. Building a project out of accounts the workspace already holds is fast by comparison, and it can be repeated as often as you need. The clearest example is building a project again from scratch, whatever the reason for it: the accounts are already connected, so it is a paste rather than a repeat of the work — see "How is a project rebuilt from scratch?".

The goal of this stage is a project with every source account paired to a destination, and the pre-migration scan already running behind it. The next step is to review what that scan reports and clear the to-dos it raises against individual accounts, which is the subject of "Running the pre-migration scan".

How are source accounts added to the project?

Everything here happens behind Add accounts, which sits on the project header and, while the project is still empty, in the body of the screen as well. The panel it opens has two tabs, Simple and Advanced. Both do the same two things in the same order — connect whatever is not connected yet, then put accounts into the project — and what differs between them is how the accounts are identified.

• Simple picks accounts from a list, one at a time. It suits a short list or a list that was never written down anywhere.
• Advanced takes email addresses as text, typed or pasted, and can cover both source and destination in one pass. It suits a list that already exists as a spreadsheet, one long enough that clicking through it is real work. The name refers to the input format, not the difficulty: on a long list it is the easier of the two by a wide margin, and there is nothing advanced about pasting a column of addresses.

Choosing one commits you to nothing. It is the same panel and the same project either way, and you can switch between the tabs as often as you like.

With the Simple tab

Simple is for working without a written list. It shows the accounts your workspace already holds, you tick the ones you want, and nothing has to be typed — which is all a small project ever needs.

It lays out three numbered methods, and they are meant to be read as a ladder: take the first that applies.

• Method 1: Select from accounts already connected to VaultMe — the ordinary case, and where you start every time.
• Method 2: Use admin authorization — connects the source environment, after which the accounts you enter by email address are connected in bulk.
• Method 3: Use a connection link — connects accounts one at a time, with the account holder's help where you cannot sign in to the account yourself.

Methods 2 and 3 exist only because an account you need is not connected yet, and the choice between them is whether you hold administrative access to the source environment. Outlook has no environment for VaultMe to connect, so method 2 has nothing to offer on this side and every source account here is connected with a link.

Work down these steps to add your source accounts to the project:

1. Select Add accounts in the project header to open the Add Source User Accounts panel, and switch to the Simple tab if you are not already there.

2. Find the accounts you need in the list under method 1, select as many of them as you like, and confirm with Add selected.

   The list holds the accounts connected to your workspace that can serve as a source here. It is narrowed by provider, not by domain, so accounts from several domains appear together and there is nothing wrong with mixing them in one project.

   Search narrows the list, which starts to matter once a workspace has collected accounts across several migrations. Refresh reloads it, so an account connected while the panel was open appears without your having to close anything.

   An account marked Insufficient permissions can be checked but not added until it is reconnected, which the panel offers to do without leaving it. The label is narrower than it sounds: it means the account holds nothing a migration could use at all, usually because the only thing it ever granted was the identity permissions that signing in to VaultMe asks for. Your own sign-in account is the everyday example, which is why the account that created the workspace often appears in the list in that state.

3. Where accounts you need are not in the list, take method 3 to connect them.

   1. Select Connect using a connection link.
   2. Copy the link the panel presents.
   3. Use the link. Open it yourself in a private browser tab and connect the account, or send it to the account holder and wait for them to confirm back. Both ways are covered in "How do connection links work?".
   4. Select Back to return to the list of methods.
   5. Select Refresh so that the newly connected accounts appear in the list, then add them as in step 2.

With the Advanced tab

Advanced reaches the same outcome for lists too long to work through by hand, and it collapses more of the work into a single action: connecting both sides, adding the source accounts, and pairing their destinations can all happen in one pass. It is laid out as two steps, connecting and then entering email addresses.

1. Select Add accounts in the project header to open the Add Source User Accounts panel, and switch to the Advanced tab.

2. Connect whichever environments you hold administrative access to. This is the route the tab is built around, and taking it first is what keeps the rest short: an account inside a connected environment needs nothing beyond its email address in the step below, and its holder is never asked for anything.

   1. Select Connect environments under Step 1: Connect environments or individual user accounts.
   2. Find the block for the side you are connecting, select Show connection steps, and complete them. The block names the administrative role that side needs, and one of the steps is signing in with an account that holds it — see "How does connecting an environment work?".
   3. Do the same in the other side's block where it is a managed environment too, then select Back.

   Each side has its own line in step 1 and reports its own state there, reading Pending connection until it is connected. An environment on one side and none on the other is a normal shape rather than a sign that something is half-finished.

   Skip this step for any side whose accounts are all connected to your workspace already. Connecting an environment is only how accounts get there in the first place, so an environment you connected for an earlier project does not have to be connected again for this one — see "How is a project rebuilt from scratch?".

3. Hand out connection links for the accounts your environments do not cover, and skip this step where they cover everything.

   1. Select Connect user accounts using a connection link. Both links are presented together here rather than a side at a time, under Source accounts and Destination accounts.
   2. Copy the link for the side you need. With both on screen together it is easy to copy the wrong one, and the two are not interchangeable — see "How do connection links work?".
   3. Use the link. Open it yourself in a private browser tab and connect the account, or send it to the account holder and wait for them to confirm back.
   4. Select Back, then View all connected user accounts in your VaultMe workspace to check off what has come in.

   That last check is on you. All of this happens before any email address is entered, so the panel has no way of telling you which accounts on your list are still missing.

   Skip this step for any side whose accounts your workspace already holds. An account connected by link stays connected afterwards, so nobody who has done this once will be asked to do it again.

4. Enter one line per account: a source email address on its own, or a source email address followed by the destination email address it pairs with.

   The two-column shape is deliberate. A spreadsheet with source addresses in one column and destination addresses in the next can have a range of cells copied and pasted straight in with no editing, which is what an account list kept outside the app buys you here — see "Building the migration inventory".

5. Submit the list. Everything on it is connected where it needs to be, added to the project, and paired in the one action.

Email addresses are resolved in a fixed order. Where an environment is connected for that side, VaultMe looks there first and connects, or reconnects, whatever it finds. Anything left over is then looked for among the accounts already connected to your workspace, however they came to be there. That is why a mixed list works: some addresses connected by link, some by an earlier round of admin authorization, and some not connected at all until this paste, all resolved in one submission.

Validation is all or nothing across both sides, so one bad address holds up the whole paste. The misses are named per side and your list is left in place, which makes this a correction loop rather than a loss — fix the offending line and submit again.

An address fails when VaultMe cannot find it anywhere it is entitled to look: a typo, an account that has never been connected in this workspace, or one connected into a different workspace of yours. Where an environment is connected, an address that does not belong to that environment fails in the same way.

One kind of rejection is not a typo and has a real answer. An address matching a different provider is called out separately, because the fix is to the project rather than to the address: while the project is still empty the provider pair can simply be changed, and once accounts are in it, those addresses need a project of their own — see "Creating a migration project".

How is a destination assigned to each source?

Every source account in the project needs a destination of its own. Until one is assigned, the account's row reads To be assigned and the project reports a pending action. Assignment is reversible for as long as the project is a draft: the account's details offer Unassign, which frees the row for a different destination.

Assignment is not exclusive. One destination account can be assigned to several source accounts, which is the normal shape of an archival migration, where multiple accounts are consolidated into a single destination. How the content arriving from each is kept apart is a separate decision — see "Choosing migration options".

Assigning happens in a panel of its own, laid out like the one accounts were added through and offering the same two tabs, chosen on the same grounds: Simple to pick a destination from a list, Advanced to work from addresses you already have written down.

With the Simple tab

Simple works here as it does when adding: it shows the destination accounts your workspace already holds and you pick from them, with nothing to type. What differs is that you pick exactly one, however many source rows you are assigning it to.

It lays out three numbered methods, and they are meant to be read as a ladder: take the first that applies.

• Method 1: Select from accounts already connected to VaultMe — the ordinary case, and where you start every time.
• Method 2: Use admin authorization — connects the destination environment, after which the accounts you enter by email address are connected in bulk.
• Method 3: Use a connection link — connects accounts one at a time, with the account holder's help where you cannot sign in to the account yourself.

Methods 2 and 3 exist only because the destination account is not connected yet, and the choice between them is whether you hold administrative access to the destination environment.

Work down these steps to give a source account its destination:

1. Select the source rows you are assigning to: a single row, or a range of destination cells in the project's grid. Every row in the selection takes the same destination.

2. Select Assign to open the Assign Destination User Accounts panel, and switch to the Simple tab if it is not the one showing.

   Working from one row, the Assign control is on its unassigned destination cell and in that row's details. Working from a range, it is in the details panel that the selection brings up.

3. Find the destination account in the list under method 1, select it, and confirm with Assign.

   Only one destination account can be chosen, however many source rows the panel was opened for, and it is assigned to all of them. This list holds the accounts connected to your workspace that can serve as a destination here, narrowed by provider rather than by domain. It works like the one source accounts are picked from, with the same Search, Refresh, and connection statuses — see "How are source accounts added to the project?".

4. Where the destination account is not in the list, take method 2, which connects accounts by email address and in bulk.

   1. Select Assign using admin authorization.
   2. Expand the connection steps the panel offers and complete them. One of them is signing in with an account that holds the administrative role Google Workspace requires — see "How does connecting an environment work?".
   3. Enter the email addresses of the destination accounts, one per line.
   4. Confirm. The panel reports which accounts were connected, and offers to connect more or to return to the list.
   5. Select Back, then assign one of the newly connected accounts under method 1, as in step 3.

   Validation on the confirming step is all or nothing: unless every email address matches the connected environment, nothing is connected at all. The panel names the addresses that missed and leaves your list in place to be corrected.

   Note where this route stops. On the source side it puts accounts into the project; here it only connects them to your workspace, and assigning stays a separate act.

5. Take method 3 for any account method 2 cannot reach.

   1. Select Connect using a connection link.
   2. Copy the link the panel presents. This panel offers the destination link only, which is the one you want here: a source link used for a destination account connects cleanly and carries the wrong permissions, with nothing to say so until the project is scanned — see "How do I know the accounts are connected properly?".
   3. Use the link. Open it yourself in a private browser tab and connect the account, or send it to the account holder and wait for them to confirm back. Both ways are covered in "How do connection links work?".
   4. Select Back to return to the list of methods.
   5. Select Refresh so that the newly connected account appears in the list, then assign it as in step 3.

With the Advanced tab

Advanced takes email addresses as text, two columns of them, and it does the one job Simple cannot: pairing destinations in bulk against source accounts that are already in the project. Every line names a source account and the destination it takes, so a list of pairs prepared outside the app can be pasted in whole.

Work down these steps to assign destinations in bulk:

1. Open a panel by whichever of the two routes suits.

   • Select a range of destination cells in the project's list and use Assign in the details panel, which opens Assign Destination User Accounts. The field is narrowed to the rows you selected: every line needs both addresses, and every source address has to be one of those rows.
   • Or select Add accounts in the project header, which opens Add Source User Accounts and takes no notice of what is selected in the grid. The field is the same two-column one the source accounts were added through, and a line whose source account is already in the project assigns a destination against it rather than adding it a second time — see "How are source accounts added to the project?".

2. Switch to the Advanced tab.

3. Connect whichever environments you hold administrative access to. Take this route before the next one: an account inside a connected environment needs nothing beyond its email address in the step below, and its holder is never asked for anything.

   1. Select Connect environments under Step 1: Connect environments or individual user accounts.
   2. In the block for the side you are connecting, select Show connection steps and complete them. One of them is signing in with an account that holds the administrative role that environment requires — see "How does connecting an environment work?".
   3. Do the same in the other side's block where it is a managed environment too, then select Back.

   Each side has its own line in step 1 and reports its own state there, reading Pending connection until it is connected. An environment on one side and none on the other is a normal shape rather than a sign that something is half-finished.

   Skip this step for any side whose accounts are all connected to your workspace already. Connecting an environment is only how accounts get there in the first place, so an environment you connected for an earlier project does not have to be connected again for this one — see "How is a project rebuilt from scratch?".

4. Hand out the destination connection link for the accounts your environment does not cover.

   1. Select Connect user accounts using a connection link. Both sides' links are presented together here, so take the one under Destination accounts — see "How do connection links work?".
   2. Use the link. Open it yourself in a private browser tab and connect the account, or send it to the account holder and wait for them to confirm back.
   3. Select Back, then View all connected user accounts in your VaultMe workspace to check off what has come in.

   That last check is on you. All of this happens before any email address is entered, so the panel has no way of telling you which destination accounts on your list are still missing.

   Skip this step where the destination accounts you need are connected already. An account connected by link stays connected afterwards, so nobody who has done this once will be asked to do it again.

5. Enter one line per pair: the source account's email address, then the destination address it takes.

   The two-column shape takes a spreadsheet range unedited, which is the whole payoff of keeping the account list outside the app — see "Building the migration inventory".

   Coming from a selection, Paste selected source accounts fills the first column from that selection and leaves the second to be typed by hand. It saves the source half of the transcription and no more, so it is a convenience for whoever has no list to paste rather than a substitute for having one.

6. Submit the list. Everything on it is connected where it needs to be, added to the project, and paired in the one action.

What happens on submit is the same as on the adding side, and it is covered in full there — see "How are source accounts added to the project?". In short:

• Each address is looked for in its side's connected environment first, then among the accounts your workspace already holds.
• Validation is all or nothing: one bad address holds up the whole paste.
• An address belonging to a different provider needs a project of its own.

How does connecting an environment work?

Connecting an environment means authorizing VaultMe once against a whole Google Workspace organization or Microsoft 365 tenant, instead of against one account at a time. It is one of the two ways an account can reach VaultMe, and how the two differ is covered in "How VaultMe authentication works"; which of them your migration uses on each side was decided during planning, in "Choosing a connection method".

What connecting an environment buys is bulk. VaultMe can then connect its user accounts from their email addresses alone, as many at a time as you can paste, and none of their holders has to sign in to anything or even know it happened.

What it costs is credentials. Connecting an environment has to be done by someone holding that provider's top administrative role, and it has to happen at their keyboard — there is no way for them to authorize it in advance and leave somebody else to carry it out. For Google Workspace, that role is Super Admin. Wherever you connect from, VaultMe names the role that side needs and presents the connection steps at the point of use, so there is nothing to prepare beyond having that account to hand.

Email addresses are typed, never browsed. Connecting an environment does not hand VaultMe an inventory of it: VaultMe does not list the user accounts an environment contains, and no screen anywhere offers them for selection. You supply the addresses, VaultMe checks each one against the connected environment, and the ones that check out are connected. If you are looking for a directory to pick from, there is not one, and the addresses have to come from the list you built during planning — see "Building the migration inventory".

The last of it is the part worth planning around. An environment connection is a means, not a standing dependency: connect it, disconnect it, and reconnect it as often as you need, and none of that touches the accounts already connected through it, because those belong to your workspace now. The relationship runs one way, which is the opposite of what is commonly assumed — connecting an environment produces connected accounts, and once it has, they no longer need it.

VaultMe is designed around one person doing all of this, and that is the arrangement to aim for: the admin who holds the credentials connects the environments, builds the project, and runs the migration, reconnecting an environment whenever something new needs connecting. Nothing requires it, though, and two departures from it are worth knowing about.

• The person who connects and the person who migrates need not be the same. One admin can connect the environment with the credentials it requires and add the accounts; any other member of the workspace can then build projects and run migrations on those accounts without holding those credentials at all — see "Creating a migration project".
• Administrative access is needed again only for accounts your workspace does not already hold. Rebuilding a lost draft, standing up the next wave of a phased rollout, or handing the work to a colleague needs none of it, because every account those projects draw on is already connected — see "How is a project rebuilt from scratch?".

How do connection links work?

A connection link opens a page that connects a single account to VaultMe. Whoever can sign in to that account follows the link, signs in, and grants VaultMe the access the migration needs. It is the other of the two ways an account can reach VaultMe, and the one that asks for no administrative access at all — how the two differ is covered in "How VaultMe authentication works", and which of them your migration uses on each side was decided during planning, in "Choosing a connection method". What follows is what the route means in the app.

A VaultMe project has exactly two connection links: one for the source side and one for the destination side. They are not issued per account — each link connects any number of accounts, never expires, and can go to as many people as you need to reach. Sending the same link to forty account holders is what it is for, not a shortcut.

Both links live in the Add accounts panel, and the shortest way to either of them is its Advanced tab, where Connect user accounts using a connection link presents them side by side under Source accounts and Destination accounts. The Simple tab offers one link at a time instead, and hands you the one that belongs to the step you are on — the source link while adding sources, the destination link while assigning destinations.

There are two ways to use a link, and the only thing that decides between them is whether you have the account's credentials. If you do, open the link yourself and connect the account. If you do not, send the link to the account holder, who opens it, connects, and tells you when they are done. Whoever opens it has to be able to pass any multi-factor challenge the account requires, which is the usual reason connecting on someone else's behalf gets stuck.

Two rules apply to whoever opens the link, and both are worth passing on with it when you hand it to somebody else:

• Open it in a private browser tab, and in a fresh private tab for each account where several are being connected. Otherwise the browser may sign in automatically as an account used earlier, and that is how the wrong account ends up connected.
• Approve every permission the link asks for. Where a provider lets them be approved selectively, declining any still produces a connection, and one that reads as valid — but not one the migration can work with, because the content those permissions covered cannot be reached. VaultMe raises that as a to-do against the account later on, by which point you are back to the same person asking again — see "How do I know the accounts are connected properly?".

Where other people are doing the connecting, VaultMe leaves the workflow around the link to you:

• Getting the link to the people who need it is your own errand. VaultMe does not send it and keeps no record of who has received it, so it travels by whatever means you normally reach them.
• VaultMe doesn't announce it when somebody connects an account. Your VaultMe workspace is the signal to watch: a connected account is listed there, and one missing from that list has not been connected yet, which is how you know who still needs chasing.

One thing to keep in mind before any link goes out: the two links a project gives you are not interchangeable. The source link connects source accounts, the destination link connects destination accounts. Swapping them is easily done, and nothing at the time of connecting says so. A destination account connected with the source link connects cleanly and looks entirely normal, but what it granted is the read access a source needs, not the write access a destination needs, so nothing can be migrated into it. The shortfall is reported once the account is in a configured project, which is late but not too late — see "How do I know the accounts are connected properly?".

A link is also tied to the provider pair and the VaultMe workspace it was generated for, which puts a stale or foreign link within reach in three situations.

• The project's providers changed. The links changed with them, so any link saved before the change now belongs to a pair this project no longer uses. Copy the link afresh from the panel each time instead of reusing one you saved earlier.
• You are running more than one project. Where their provider pairs differ, so do their links, and a link kept from another migration will not serve this one.
• You hold more than one VaultMe workspace. A link connects the account into the workspace it came from. Use the wrong one and the account is not missing, it is somewhere else, and no amount of refreshing will bring it into this list.

How do I know the accounts are connected properly?

An account can be connected to VaultMe and still not be usable for your migration. Those are two separate questions, and they are answered in two different places. Your VaultMe workspace answers the first: it lists every account connected to it and grades each connection as Valid, Invalid, or Revoked. Only a configured project answers the second. The gap between the two is where every problem in this chapter lives.

Connecting an environment rarely leaves that gap. Its grant is all or nothing, so the accounts connected through it arrive holding everything a migration needs, and what introduces the risk is signing in by hand alongside it.

One situation catches people who have done everything else right: signing out of VaultMe revokes the connection of the account you were signed in with, whichever way that account was connected. Signing back in connects it again, but grants only the minimum permissions signing in itself requires. So where the account you sign in with is also an account you are migrating, one round of signing out and back in leaves it connected, still reading as Valid in your workspace, and holding nothing a migration can use. The way to stay clear of this is to sign in to VaultMe with an account that is not migrating anywhere; where that is not possible, stay signed in for the duration, and reconnect the account if you do sign out.

Connection links carry the rest of the risk, and two things routinely go wrong with them.

• The wrong link. A destination account connected with the source link is connected and reads as valid, but it carries the read access a source needs rather than the write access a destination needs — see "How do connection links work?" for that and for the other ways a link can be the wrong one.
• A partial grant. Where the provider lets whoever is connecting choose which permissions to approve, an account can be connected with only part of the set VaultMe asked for. Google's consent screen is the common case: individual permissions can be declined and the connection still completes.

All of these clear the same way. Once the account is in a configured project, the shortfall is reported as a to-do against that account, and it has two resolutions rather than one: reconnect the account with the permissions the migration needs, or exclude the content type that requires them. The second removes the requirement instead of satisfying it, so it is only a real option where that content was negotiable in the first place — see "Running the pre-migration scan".

Which is the practical advice this chapter exists to give: do not leave any of this to migration day. Adding a source account or assigning a destination starts a round of the pre-migration scan by itself, so assembling the project early is the connection test — there is no separate check to run, and no reason to wait until the list is complete. Accounts added on Monday have their to-dos raised on Monday, while there is still time to go back to whoever has to act on them.

If you are uncertain about any of it, open your VaultMe workspace in a new tab, select Refresh and check all, then reload the project page. VaultMe checks each connection against the provider, so anything that has changed in the background shows up straight away. A project that comes through that with no to-dos against its accounts is as close to a guarantee of readiness as you can get before the migration starts.

How many accounts can one batch hold?

A VaultMe project can hold at most 100 user accounts, which is a guardrail against large-scale mistakes. Going over means splitting the work into projects that fit, which is not the same as phasing the rollout. Projects built to fit the cap can be paid for and started together, so a 250-account migration becomes three projects built one after another and three batches that all run at the same time. Hitting the cap is chunking, not phasing; whether to genuinely phase a rollout is a separate decision, made on risk rather than arithmetic — see "Choosing a migration strategy".

Where does everything that is not a user account go?

A VaultMe project takes user accounts, and only user accounts. Where the migration inventory you built during planning also lists resources that are not accounts, none of them gets a row in the project and there is no second list for them to go on — see "Building the migration inventory" for what they are and how each is migrated.

In an Outlook to Google Workspace migration this hardly arises. User accounts are the only thing VaultMe migrates from Outlook, so your list of accounts is the whole of the inventory. A shared login used by several people — support, info, accounts — is a user account as far as VaultMe is concerned, and belongs on the list like any other.

Can the list be changed later?

Yes, for as long as the VaultMe project is a draft, which is to say until you pay for it. Select the rows you want and Remove becomes available. It acts on the whole selection and asks you to confirm first, stating how many accounts it is about to remove from the project.

What removing takes away is the account's place in the project, and nothing else. The account stays connected in your VaultMe workspace, so it can be added back later with no reconnecting, and removing it revokes nothing — VaultMe's access to an account is untouched by what a project does or does not contain.

Removing a source account takes its destination assignment with it. Add it back and it comes back unpaired, so the assignment has to be made again.

How is a project rebuilt from scratch?

A project has to be rebuilt whenever the draft is no longer there to return to — you are on another machine or in another browser, the browsing data has been cleared, or you signed out — and those situations are set out in "Creating a migration project". This chapter is about the rebuilding itself, which is the cheap half of the work.

What survives is everything your workspace holds: every user account ever connected to it, still connected, and every batch you have paid for, still listed. None of that belongs to a project, so none of it leaves with one.

What does not survive is the project's own content: the account list, the destination assignments, and the migration options. The environment connections go too, because those are held in the project rather than in the workspace.

Where you keep the inventory in a two-column spreadsheet, rebuilding is a paste, and that is the reason a spreadsheet is worth keeping on any project beyond a handful of accounts.

1. Select Add accounts in the project header and switch to the Advanced tab.
2. Skip Step 1: Connect environments or individual user accounts entirely. Every address you are about to enter is connected already, so there is nothing here to do.
3. Paste both columns of the spreadsheet into the field under Step 2: Enter email addresses — each source address followed by the destination it pairs with.
4. Submit. The accounts are added and paired in that one action, and the project is back — see "How are source accounts added to the project?".

Those same steps, against that same spreadsheet, are how three other situations are handled as well.

• Each wave of a phased rollout. Only one draft exists at a time, so the waves are built in sequence, and every wave after the first is a paste — see "Choosing a migration strategy".
• Handing the work to a colleague. A member of your workspace cannot take over your draft, but they can build the same project from the spreadsheet in minutes — see "Creating a migration project".
• Changing the provider pair on a project that already has accounts. Nothing carries over to the new pair, so the project is built again from the spreadsheet — see "Creating a migration project".