Migration playbook

This playbook takes you from the first planning decision to the last wrap-up task, one action at a time.

How do I use this playbook?

This playbook is an Outlook to Google Workspace migration written out end to end as actions, in the order you take them. Each step says what to do, adds a note where the step is easy to get wrong, and names the article that explains the rest. Keep it open beside the VaultMe app and work down it, or read it through once to see the shape of the whole migration before you begin.

If you would like a brief overview of VaultMe first, three short articles give it: "What is VaultMe", "How VaultMe works", and "Pricing and payment".

The playbook comes in two versions, one for small migrations and one for larger migrations, and you need only one of them. Both follow the same four stages:

1. Decide what migrates. Which accounts, where each one lands, and what content comes with them. This is the only work that genuinely comes before the app.
2. Build a project in VaultMe and let it find what is not ready. A project is the list of accounts you want to migrate, together with where each one goes. VaultMe checks every account you add with a free pre-migration scan and reports back whatever stands in the way of migrating it.
3. Pay and run. Paying turns the project into a batch, the set of migrations that run together, and starting the batch is a separate act.
4. Review, switch over, and close out. The people who use the accounts confirm the result, the destination becomes the side everyone works in, and the source is retired.

Notice where the project sits in that sequence: second, not last. The instinct is to get both sides ready first and only then open VaultMe and start the migration, and that is the wrong way round. A project costs nothing to build, and its job is to find what is not ready early, while there is enough time to fix it.

Three facts change how everything below reads:

• VaultMe copies content rather than moving it. The source stays unchanged and usable throughout the migration, and it is still there afterwards, so nothing in it is at risk while you work through this playbook. "How VaultMe works" covers the migration mechanics in more detail.
• Nothing is committed until you pay. Signing in, connecting accounts, running the pre-migration scan, and seeing the price are all free, and any of it can be changed or abandoned without cost. "Pricing and payment" covers when the charge falls.
• Mail keeps arriving at the source until someone changes where it is delivered. Migrating content and switching over to the destination are separate events, whether the switch means repointing a domain or redirecting individual addresses. So people keep working as usual while the migration runs, and it never has to race incoming mail. "Planning the cutover and domain switch" covers how the switch works in your migration.

Which version of this playbook applies to my migration?

The playbook comes in two versions:

• The small version is "Running a small migration, step by step".
• The larger version starts at "Larger migrations: planning the project" and runs through the three chapters after it.

Use the small version if all three of these hold:

• About 20 user accounts or fewer. Count every account that migrates, archived ones included.
• A destination that already exists, or is simple to set up. Getting it ready means creating the accounts, and little else.
• No hard deadline. If something unexpected comes up, you can move the date. A fixed date leaves no room for that, so it calls for the risk reduction the larger version builds in.

If any one of them does not hold, use the larger version.

Between roughly 20 and 50 accounts, the count stops deciding and judgment takes over. Lean toward the small version where you have run a similar migration before and nothing in the estate would be hard to put right.

Whatever the count, these tip the choice toward the larger version:

• It is your first migration, or your first between these two providers. The larger version runs a test batch and a pilot first, so problems surface on a few accounts before they reach everyone.
• A bad surprise would be genuinely disruptive. The same test batch and pilot keep any problem small and catch it before the rest of the accounts migrate.
• People move in phases. Groups switch over weeks apart rather than all in one evening, and the larger version plans each phase as its own batch.
• The migration is part of a wider infrastructure change. Domains, mail routing, sign-in, or other systems are being reconfigured alongside it. That work often depends on people outside the project and is the usual reason a switchover slips.

The count is only a proxy, and what it stands for is reassuring: the work in the VaultMe app does not grow. Assembling a project, paying for it, and starting it take the same handful of screens whether the project holds five accounts or a hundred. What grows is the number of decisions that interact with each other: how much has to be settled before the app is even opened, how many batches the accounts are split into, and how much of the plan has to live outside VaultMe, because no screen in it shows a rollout.

The choice is not final, and the evidence for a borderline call arrives early. The pre-migration scan, the free check VaultMe runs on every account added to a project, measures each account's real size and item count before anything is committed, so if you are unsure, pick one now and switch once those numbers are in.

What will I need along the way?

Only the first two items below have to be in hand before you begin: an identity to sign in with, and a way to connect the source. The rest can be gathered as the project goes, budget sign-off included, because the figure to be signed off comes out of the project itself.

In the order each one starts to matter:

1. A durable Google or Microsoft identity to sign in with. Signing in to VaultMe works only with a Google or Microsoft account, but it can be any account you hold, including one that belongs to neither side of the migration. Pick one that will outlive the project: signing in creates your VaultMe workspace, where every migration you run is recorded, and that identity is the only way back into it, so an account on a domain being retired takes your migration history with it. "Creating a migration project" covers the choice.

2. A way to sign in to every source account. Each one is connected through a connection link, opened by its holder or by you where you hold its password. "Choosing a connection method" covers how.

3. Super Administrator access to the destination Google Workspace organization, if available. With it, you connect the whole organization to VaultMe once and add its accounts by email address alone. Without it, each account is connected through a connection link instead. "Choosing a connection method" covers both routes.

4. A destination that exists. VaultMe fills destination accounts and never creates them, so every account that content is headed for has to be in place before it can receive anything, and an environment that is not standing yet is usually what takes longest in the whole project. None of that holds up the start, though: the source is connected, scanned, and priced long before a destination exists. "Getting the destination ready" lists what being in place involves.

5. Budget sign-off. VaultMe is priced per migrated user account and paid for per batch, a set of accounts migrated together, and the real figure comes from the pre-migration scan VaultMe runs on your accounts rather than from an estimate anyone builds by hand, as "Pricing and payment" explains. You can get that figure early: add only the source accounts to a project in the VaultMe app, and it shows the price before any destination is assigned, so approval can be in hand long before there is anywhere to migrate to. "Running the pre-migration scan" covers the scan and the figure it returns.

6. The account list, in two columns. Source addresses in the first, and the destination address each one pairs with in the second. That shape pastes straight into the VaultMe app, and the list stays your record of the whole plan, however many batches it ends up spanning. "Building the migration inventory" covers building it.

What you do not need matters just as much, because waiting on any of these is the most common self-inflicted delay:

• A cleaned-up source. No special preparation is needed: the source can be migrated as it is.
• A pause in everyday work. There is no need to wait for a weekend or a holiday. People keep using their accounts while the migration runs, and whatever changes in the meantime is copied across afterwards.
• A cleared destination. Migrated content is added alongside whatever is already in the destination accounts.
• Mail routing already switched. Routing changes at cutover, after VaultMe has finished.
• The whole estate ready at once. A batch needs only its own accounts to be ready.

"Before you migrate" explains why none of these has to come first.

Running a small migration, step by step

This version covers up to roughly 20 accounts, migrated in one batch and switched over in one window. For anything larger, start at "Larger migrations: planning the project" instead.

Decide what migrates

1. List every account that migrates, with its source address and the destination address it goes to.

   A spreadsheet works best: source addresses in the first column and destination addresses in the second paste straight into the VaultMe app later. "Building the migration inventory" covers what else is worth recording on it.

2. Mark each account on your list as active or archived.

   An active account is one someone goes on working in after the switch; an archived one is kept only so its content is preserved, and it may not need a license of its own. "Building the migration inventory" covers the call.

3. Sweep for shared logins and for content kept outside the accounts altogether, and give each item a path.

   A shared login that several people sign in to is still a user account, so it joins the list. "Building the migration inventory" covers what to look for.

4. Decide which content types each account migrates.

   Everything together is both the default and the recommendation, but it remains your call, account by account. "Selecting content for migration" covers what each content type includes.

5. Decide which file areas migrate for each account.

   The account's own files almost always come, so the real decision is the files other people shared with it: they can outweigh everything the account owns, and in a personal account they are as likely to be private as work-related. "Selecting content for migration" covers the call.

6. Tell everyone whose account migrates what is coming and what to avoid while it runs.

   At this size one email is enough, and it costs far less now than an explanation after the switch. "Preparing stakeholders and end users" covers what to put in it.

Create a VaultMe project and let it check your work

7. Open the VaultMe app, select Multi-account migration, and sign in with Google or Microsoft.

   Note that the "Single account migration" option, on the same screen, is VaultMe Personal: a separate product for copying one account, and the wrong place to build a project of several.

   The identity you sign in with owns your workspace and every batch record in it, which makes it the one choice at this stage that outlives the project. "Creating a migration project" covers what to pick.

8. Select Outlook on the Migrate from card and Google Workspace on the Migrate to card, then select Create migration project.

   "Creating a migration project" covers this step in detail.

9. Select Add accounts and follow the instructions on screen to connect your source accounts to VaultMe and add them to the project.

   You can add accounts one at a time, or paste the source addresses from your list to add them all at once. The pre-migration scan starts on its own as the accounts arrive. "Connecting and adding user accounts" walks through this step in full.

10. Read what the project now reports about the source, and clear it.

    This is the reachability check: a suspended account, a missing permission, or a service switched off turns up here, so you do not have to check every account by hand beforehand. To-dos on a fresh project are normal output, not a sign that anything went wrong. "Running the pre-migration scan" covers clearing them, and "Getting the source ready" covers what the source needs.

11. Send out anything that needs an account holder first, and expect to chase it.

    Once an account holder has done their part, select their account in the project and use Re-run checks to confirm the to-do has cleared. "Running the pre-migration scan" covers who clears what.

12. Confirm with the people who use each account that the content they expect is actually in the cloud.

    This is the one readiness question no scan answers: mail that a desktop client pulled off the server never arrives and is never reported missing. "Getting the source ready" covers the checks.

13. Make sure every destination account exists and is licensed in the Google Admin console, with the services its content needs switched on.

    VaultMe fills destination accounts and never creates them, so this part is never done for you. The source needed none of it, which is why the source went into the project first. "Getting the destination ready" covers what the destination needs.

14. Connect your destination accounts to VaultMe and pair one with each source account in the project.

    You can pair accounts one at a time, or paste the source and destination addresses from your list to pair them all at once. Pairing is what starts the checks on the destination side.

    "Connecting and adding user accounts" walks through it in full.

15. Read what the project now reports about the destination, and clear it.

    Insufficient storage is the common finding, and it shows why a destination can only be judged against its source: the figure it is measured against is the source's real size. "Getting the destination ready" covers what to do when storage falls short.

16. Review the content types included for each account, and for every account marked archived on your list, set Method to Separate from existing content.

    Every account starts with all its content types included and on the merge method, so active accounts usually need no changes. "Choosing migration options" covers both settings.

17. Switch off any file areas you decided to leave out when scoping content, on the accounts that decision covers.

    The ellipsis button next to an account's files toggle opens its file areas, each with a toggle of its own, and selecting a range of accounts switches an area off for all of them at once. "Choosing migration options" covers it.

Pay and start

18. Read the Total price and Approximate duration in the project's summary.

    Both are now measured from the content actually in the accounts, so this is the first point at which the real cost of the project is known. "Running the pre-migration scan" covers what they include.

19. Pick the cutover evening from that duration plus headroom: a low-traffic evening with buffer behind it.

    It need not follow the run closely, because the final sync-up migration (delta migration) carries across whatever arrives at the source in between. "Planning the migration timeline" covers the timing.

20. Select Schedule migration to turn the project into a batch, paying for it at checkout.

    Once paid, the batch can no longer be edited, and it waits for you to start it. "Paying for and starting a batch" covers the checkout.

21. Select Start Migration on the batch screen when the run should begin.

22. Leave the batch to run.

    VaultMe monitors its own runs and gets in touch where something needs you. "Monitoring a migration" covers what you will see.

Review, switch over, and close out

23. Once the batch completes, select Download reports on the batch screen, and skim the exceptions at the top of each sheet. "Reviewing migration results" covers what to look for.

24. Send each account holder their own report, and ask them to look for the content they actually rely on.

    Warn them before they look, because nearly every false alarm comes from something nobody mentioned; "Reviewing migration results" lists the warnings to send.

25. Cut over once the account holders confirm.

    There is no mail routing to switch: each account holder starts working in the destination account and, where the old address will go on receiving mail, forwards it to the new one.

    "Planning the cutover and domain switch" covers the switch in full.

26. Run the final sync-up with Sync Up on the batch screen, after the switch rather than before it.

    Run it soon after the switch settles and before people start reworking migrated items in the destination; it covers the whole batch and costs nothing extra. "Running sync-up migrations" covers the timing.

27. Save the reports and the invoice somewhere outside VaultMe.

    VaultMe keeps each report for a year after the run that produced it, so a copy of your own is the lasting record. "Wrapping up the project" covers what to keep.

28. Revoke VaultMe's access once no further sync-up is wanted, then retire the source on your own schedule.

    Keep that order, because each step gives up a fallback: revoking access ends any further sync-up pass, and retiring the source ends any check or recovery against it. "Wrapping up the project" covers retiring it in stages.

One thing is left once the last step is done: the follow-up VaultMe leaves to you by design, which is best given an owner now rather than discovered later. "What is still mine to do after VaultMe finishes?" lists it.

Larger migrations: planning the project

This chapter and the three after it make up the larger version of the playbook; the small version ends with the chapter above.

In a larger migration the run is rarely what takes longest. Preparation is, so the steps below are ordered by lead time, the slowest first, rather than by importance.

1. Start the long-lead items today, before any of the rest: the destination environment, its domains, access to the registrar or DNS, licenses, and whatever else the wider infrastructure change involves.

   Each of these needs someone with the authority to commit to it, none of it is VaultMe work, and together they are the usual reason a cutover slips. "Getting the destination ready" covers what each involves.

2. List every account that migrates in a spreadsheet, one row per account, with source addresses in the first column and the destination address each one goes to in the second.

   Each decision below adds a column to it, and each batch is later filtered out of it and pasted straight into the VaultMe app. "Building the migration inventory" covers what else is worth recording on it.

3. Trim the spreadsheet down to the accounts that genuinely need to migrate, then get sign-off on what is left.

   The call on accounts whose holders have left still belongs to someone, and naming that person is the point of this step, even where the organization is small enough that it feels obvious. "Building the migration inventory" covers which accounts to keep.

4. Mark every account on your spreadsheet as active or archived, and work out the destination licenses that the split calls for.

   An active account is one someone goes on working in after the switch; an archived one is kept only so its content is preserved, and it may not need a license of its own. "Building the migration inventory" covers the call.

5. Sweep for shared logins and for content kept outside the accounts altogether, and give each item a path.

   A shared login that several people sign in to is still a user account, so it joins the spreadsheet. "Building the migration inventory" covers what to look for.

6. Decide which content types each account migrates, and record them on your spreadsheet.

   Everything together is both the default and the recommendation, but it remains your call, account by account. "Selecting content for migration" covers the decision.

7. Decide which file areas migrate for each account.

   The account's own files almost always come, so the real decision is the files other people shared with it: they can outweigh everything the account owns, and in a personal account they are as likely to be private as work-related. "Selecting content for migration" covers the call.

8. Write down what will not migrate at all, and give each item an owner.

   The list is short for personal accounts, but it is worth having in writing before anyone asks. "Selecting content for migration" lists what stays behind.

9. Decide who opens the connection link for each source account: its holder, or you, signing in with credentials they give you.

   Sending the link to the holder is the recommended route, because each sign-in stays with the person it belongs to. Either way, every account waits on someone, and that legwork sets the pace of the rollout. "Choosing a connection method" covers both routes.

10. Decide how the destination connects: once for the whole destination Google Workspace organization, with Super Administrator access, or account by account, through connection links.

    Aim for the single connection wherever that access can be secured; connection links are the fallback. "Choosing a connection method" runs through the decision for both sides.

11. Choose the rollout strategy: every account in one batch, or a phased rollout across several.

    A phased rollout is the usual answer at this size: a small test batch first, to see how a run behaves on your accounts, then a pilot, then the remaining batches, with any groups that switch over at different times shaping those last ones. One batch stays a sound choice at the lower end of the range. Either way, record each account's batch on your spreadsheet. "Choosing a migration strategy" covers the choice.

12. Fix the cutover date and hour first, one for each group where people switch over at different times, then build the calendar backwards from it.

    Every other date follows from that one. The run is placed to finish well before it, because the final sync-up migration (delta migration) carries across whatever arrives at the source in between, and the readiness work lands before the run. "Planning the migration timeline" covers building the calendar.

13. Reserve run time generously rather than precisely, and write the reserve down for each batch.

    Work in whole days rather than hours: an estimate of three hours becomes a day, and where the estimate already runs to days, doubling it is a sound default. "Planning the migration timeline" covers sizing it.

14. Budget the post-migration support window, and name who handles it.

    It is the part of the calendar most often cut first and most often missed: for a while after the switch, anything people cannot find is blamed on the migration. "Planning the migration timeline" covers sizing it.

Most of what derails a schedule like this one is absorbed by an early start and generous buffer; "Planning the migration timeline" lists the risks worth guarding against.

Larger migrations: getting both sides ready

Start this stage by building a project in VaultMe, before preparing anything on either side. As accounts are added, VaultMe checks each one and lists whatever stands in the way of migrating it, and that list is what tells you which preparation work is actually needed. Building the project and running those checks costs nothing, and nothing is committed until you pay.

The project you build here is only for checking, so its shape does not matter. It can hold every account at once or just a slice of them, and you can remove accounts, add others, and rearrange it as often as you like; a project holds at most 100 accounts, so a larger estate is checked slice by slice anyway. None of it has to match the batches: when they start, each batch gets a project of exactly its own accounts, built by pasting its two columns from your spreadsheet, and that paste is what makes the spreadsheet worth keeping. "Choosing a migration strategy" covers running the rollout from it.

1. Open the VaultMe app, select Multi-account migration, and sign in with Google or Microsoft.

   Note that the "Single account migration" option, on the same screen, is VaultMe Personal: a separate product for copying one account, and the wrong place to build a project of several.

   The identity you sign in with owns your VaultMe workspace and every batch in it, which makes it the one choice at this stage that outlives the project. "Creating a migration project" covers what to pick.

2. Select Outlook on the Migrate from card and Google Workspace on the Migrate to card, then select Create migration project.

   "Creating a migration project" covers this step in detail.

3. Select Add accounts, follow the instructions on screen to connect your source accounts to VaultMe, and paste the source column from your spreadsheet: the source addresses only, for now.

   Checking the source before any destination is assigned is the expected way to do this, not a workaround, and it can start weeks before anything exists on the destination side. Where accounts connect through connection links, send the links with exact instructions and a deadline, and follow up: unopened links are routinely the slowest part of the project. "Connecting and adding user accounts" walks through this step in full.

   The pre-migration scan starts on its own as the accounts arrive, and it returns the price, so budget sign-off can close from here. "Running the pre-migration scan" covers the figure.

4. Read what the project reports about the source, and clear it, starting from the project status rather than by scrolling through the accounts.

   This is the reachability check: a suspended account, a missing permission, or a service switched off turns up here, so you do not have to check every account by hand beforehand. The project status opens a list of everything still outstanding, and to-dos on a fresh project are normal output, not a sign that anything went wrong.

   Send out anything that needs an account holder first, since those take longest, and expect to chase it. Once an account holder has done their part, select their account and use Re-run checks to confirm the to-do has cleared.

   "Running the pre-migration scan" covers working through the to-dos, and "Getting the source ready" covers what the source needs to be ready.

5. Confirm with the people who use each account that the content they expect is actually in the cloud.

   This is the one readiness question no scan answers: mail that a desktop client pulled off the server never arrives and is never reported missing. "Getting the source ready" covers the checks.

6. Finish setting up the destination environment and its domains: add and verify the domains the destination accounts will use, and plan mail authentication, along with any warm-up a new domain needs, well ahead of the cutover.

   None of this is VaultMe work, and verifying a domain depends on whoever controls its DNS records. "Getting the destination ready" covers what is involved.

7. Make sure every destination account exists and is licensed in the Google Admin console, with the services its content needs switched on.

   VaultMe fills destination accounts and never creates them, so this part is never done for you. The source needed none of it, which is why the source went into the project first. Follow the active-or-archived split on your spreadsheet when assigning licenses, and treat a license as necessary rather than as proof that content will land: the checks VaultMe runs once the accounts are paired are the proof. "Getting the destination ready" covers what the destination needs.

8. Select Add accounts again and switch to the Advanced tab. Connect your destination accounts there, paste both columns from your spreadsheet to pair one with each source account, and clear what the project then reports about the destination.

   Pairing is what starts the checks on the destination side, and insufficient storage is the common finding. That is why the destination is checked only now: the source could be checked on its own, but a destination is ready only for the source it will receive, measured against that source's real size. "Getting the destination ready" covers the difference.

   Where destination accounts connect through connection links, send the destination link, not the source one, with the same exact instructions and deadline. "Connecting and adding user accounts" walks through pairing in full.

9. Ask every account holder not to change their password or multi-factor authentication settings from here until the final sync-up is done.

   Either change silently drops the connection, and VaultMe pauses the migration until it is restored. The freeze matters more here rather than less, because restoring a connection means going back to the account holder. "Getting the source ready" covers keeping connections alive.

10. Have automatic filing, forwarding, and deletion rules turned off in the destination accounts, and pause any third-party apps working in the accounts that can wait.

    Rules act on migrated mail as it arrives, and can file it out of sight or send copies somewhere nobody expects; switch them back on once the migration is finished. "Getting the destination ready" covers the rest of the destination housekeeping.

11. Check each batch's accounts again shortly before its window opens, rather than taking readiness on trust.

    Readiness can drift in the weeks in between, when a license is removed or a connection drops. Select the batch's accounts and use Re-run checks: it costs nothing and can be repeated as often as needed. "Running the pre-migration scan" covers when checks run.

12. Send the announcement: what is coming, what to avoid while it runs, and a request that each account holder confirm their content before their switch.

    Telling people now costs far less than explaining after the switch. Where shared content is in scope, warn external collaborators as well, since they are the group most often left out. "Preparing stakeholders and end users" covers what to tell whom.

13. Check each cutover window against the availability of everyone it depends on, and move it now if it clashes.

    Vacations, public holidays, and time zones do most of the damage, and the people involved include account holders who have to connect or confirm, and whoever has to be around during the switch. "Preparing stakeholders and end users" covers lining them up.

Larger migrations: running the batches

Every batch runs through the same sequence of clicks. What makes this stage long is that the sequence repeats, with each batch filtered out of your spreadsheet. If you chose one batch for every account, run the first stage below with all of them in the project, and skip the calibration at its end.

Run the test batch

The test batch is small and representative: an ordinary account or two alongside one of the heaviest, since the heaviest accounts set how long every batch they sit in takes. "Choosing a migration strategy" covers choosing it.

1. Make the project from preparation hold exactly the test batch: select any accounts that are not in it and select Remove, then paste in any that are missing from your spreadsheet under Add accounts.

   The VaultMe app keeps only one unpaid migration project at a time, so the test batch is built in the project you already have, and each later batch in a new one once the batch before it is paid for. Removing takes an account out of the project and nothing more: it stays connected to your workspace, ready to be pasted into a later batch. "Connecting and adding user accounts" covers changing the list.

2. Clear any to-dos the project reports for the test batch.

   Once a fix is made outside VaultMe, select the account and use Re-run checks to confirm the to-do has cleared. "Running the pre-migration scan" covers clearing them.

3. Set the content types and file areas recorded on your spreadsheet for each account, and for every account marked archived, set Method to Separate from existing content.

   Every account starts with all its content included and on the merge method, so active accounts that migrate everything need no changes. The ellipsis button next to an account's files toggle opens its file areas, and selecting a range of accounts changes a setting for all of them at once. "Choosing migration options" covers these settings.

4. Read the Total price and Approximate duration in the project's summary, then select Schedule migration to turn the project into a batch, paying for it at checkout.

   Once paid, the batch can no longer be edited, and it waits for you to start it. "Paying for and starting a batch" covers the checkout.

5. Select Start Migration on the batch screen, and leave the batch to run.

   VaultMe monitors its own runs and gets in touch where something needs you. "Monitoring a migration" covers what you will see.

6. Once the batch completes, select Download reports on the batch screen, skim the exceptions each report lists first, and send each account holder their own report to confirm the content they rely on.

   Warn them before they look, because nearly every false alarm comes from something nobody mentioned. "Reviewing migration results" covers both halves of the review.

7. Compare how long the test batch actually took with its Approximate duration, and scale the time reserved for the remaining batches by the difference.

   "Planning the migration timeline" covers sizing the reserves.

8. Write what surprised you back into your spreadsheet: a batch reordered, a difficult account moved later, an option handled differently.

   "Choosing a migration strategy" covers reshaping the rest of the rollout.

Run the pilot and the remaining batches

Take the pilot first, then each remaining batch in the order your spreadsheet sets, each through the same full sequence.

9. In your VaultMe workspace, select Start New Migration, select Outlook on the Migrate from card and Google Workspace on the Migrate to card, and select Create migration project. Then select Add accounts and paste the batch's two columns from your spreadsheet.

   Nothing needs connecting again: accounts stay connected to your workspace between projects, so the paste adds and pairs them in one go. "Connecting and adding user accounts" walks through the paste.

   A project holds at most 100 accounts, so split a larger batch into projects that fit. That is chunking, not phasing: those projects can be paid for and started together. "Connecting and adding user accounts" covers the limit.

10. Clear any to-dos, working from the project status once there are more accounts than fit on a screen.

    The project status opens a list of everything still outstanding, and each entry narrows the accounts down to the ones it affects. Once a fix is made outside VaultMe, Re-run checks confirms it. "Running the pre-migration scan" covers clearing a to-do across many accounts at once.

11. Set the options the same way as for the test batch, following your spreadsheet.

    A new project starts from the defaults, so nothing set on an earlier batch carries over. "Choosing migration options" covers the settings.

12. Read the Total price and Approximate duration, select Schedule migration and pay at checkout, then select Start Migration when the batch's window opens.

    Pay for each batch only once you are ready to commit its configuration: a paid batch cannot be edited, so nothing the earlier batches teach you can reach it afterwards. "Paying for and starting a batch" covers the order.

13. Mark each batch on your spreadsheet as it moves along: not started, started, done.

    Your VaultMe workspace lists every batch as well, each with its status: created, started, or completed. "Choosing a migration strategy" covers tracking the rollout.

14. As each batch completes, select Download reports on its batch screen and collect its account holders' confirmations, rather than saving them all for the end.

    The pilot shows which warnings matter for your accounts, which sharpens the ask for every batch after it. "Reviewing migration results" covers the warnings to send.

15. While the remaining batches run, open each completed batch from your VaultMe workspace and select Sync Up about once a week.

    A sync-up migration copies across whatever has changed at the source since the last run, at no extra cost. Running one weekly keeps the batch able to sync up at all, since that ability lapses if too long passes without a run, and it keeps the final sync-up small. "Running sync-up migrations" covers when to run one.

16. Keep people out of their destination accounts until their own migration has finished.

    Working in a destination account that is still being filled causes the most avoidable trouble, while everyday work in the source disturbs nothing. "Monitoring a migration" covers the rest of what to avoid.

Larger migrations: cutting over and closing out

This stage is a short finale on a plan already made, and its steps give up fallbacks in the order they are listed. Where groups switch over at different times, repeat the steps up to and including the final sync-up for each group. "Wrapping up the project" covers closing out as a whole.

1. Switch over only once every batch has been reviewed through Download reports on its batch screen and its account holders have confirmed, not merely once VaultMe shows it as completed.

   Completion means VaultMe has finished its work and recorded an outcome for every item. Whether people can find everything they rely on is something only the account holders can confirm. "Wrapping up the project" covers the call.

2. On the day of the switch, confirm that a final sync-up is still possible: the connections on both sides are still live, and the batch has not gone too long without a run.

   "Running sync-up migrations" covers what can stop one.

3. Switch over at the hour you chose.

   There is no mail routing to switch: each account holder starts working in the destination account and, where the old address will go on receiving mail, forwards it to the new one.

   "Planning the cutover and domain switch" covers the switch in full.

4. Once the switch has settled, open each batch from your VaultMe workspace and select Sync Up for the final sync-up.

   Run it after the switch rather than before: a pass run the day before leaves behind everything that reaches the source in the hours between, while one run after the switch has nothing left to miss. Run it before people start reworking migrated items in the destination. "Running sync-up migrations" covers the timing.

5. From here on, treat the destination as the live side, and run no further sync-ups.

   A later pass could carry a source-side change over an item someone has since edited in the destination, overwriting the edit. "Wrapping up the project" covers why the final sync-up is the last.

6. Work down the follow-up VaultMe leaves to you, giving every item an owner and a closing date.

   "What is still mine to do after VaultMe finishes?" lists it.

7. Save every report and every invoice somewhere outside VaultMe.

   VaultMe keeps each report for a year after the run that produced it, and the latest report covers every run before it, so one download per batch after its final sync-up is enough. "Wrapping up the project" covers what to keep.

8. Revoke VaultMe's access once no further sync-up is wanted.

   Access is withdrawn on the provider's side rather than in the VaultMe app, and connecting the accounts again afterwards is real legwork, while leaving access in place for a few weeks costs nothing. "Wrapping up the project" covers how.

9. Retire the source last, in stages: make it read-only and only then decommission it.

   Retiring it takes away three things that stay invisible until they are gone: the only thing to check the destination against, any further sync-up, and any redo. "Wrapping up the project" covers when it is safe.

What is still mine to do after VaultMe finishes?

When VaultMe finishes, a short list of work remains that it leaves to you by design. Every item on it can be foreseen, so the risk is not the work itself but an item nobody owns: give each one a name and a date. "Wrapping up the project" covers the list in more depth.

• Items in TODO areas. Content that arrived but could not be placed where it belonged waits in a clearly marked area in the destination account. Only the account holder can file it, and nothing later moves it. "Reviewing migration results" covers what these areas hold.
• Links that point at the source. Links inside migrated content are kept exactly as they were written, so any that point at source items stop working at cutover. Review the few that matter rather than all of them.
• Skipped items that are still wanted. Each one is listed in the report with its reason. Anything still worth having is recovered by hand from the source, which is possible only while the source still exists. "Reviewing migration results" covers judging them.
• Sharing. Access does not follow migrated content, so the people who shared files share them again from the destination, with colleagues and with collaborators outside the organization alike. "Preparing stakeholders and end users" covers what end users do after the switch.
• Mail apps. Desktop and mobile mail apps keep pointing at the source account until someone sets them up for the destination; the switch itself does not move them.

Two things are worth saying plainly, because both get asked: none of these is a defect, and none of them is fixed by a sync-up or by migrating the accounts again.

Several of these items, such as TODO areas, skipped items, and links, come up during the account holders' review before their switch, which is the easiest time to deal with them, while the source is still there to recover from and check against.

What do I do if something looks wrong?

Find the line below that matches what you are seeing and follow its link; there is no need to read the whole chapter.

Most often, nothing is wrong at all. Nearly everything listed below is either how a normal migration behaves or something with a straightforward fix.

• A migration is paused. Its details screen names the reason. VaultMe clears some conditions on its own; put right the ones that are yours, and send anything you cannot place to support. "Monitoring a migration" covers both kinds.
• The run is slower than the estimate. The estimate is a projection, never a promise, and nothing inside VaultMe makes a run go faster. "Monitoring a migration" covers reading it.
• A to-do will not clear. Two resolutions always exist: satisfy the requirement, or take the content that needs it out of the migration. "Running the pre-migration scan" covers both.
• A connection stopped working. Connecting the account again fixes it, and that goes back to whoever connected it in the first place. "Connecting and adding user accounts" covers the causes.
• A payment was declined. Nothing is at risk and nothing is used up: the project stays exactly as it was, so retry with the same method or another. "Paying for and starting a batch" covers it.
• The project is gone when you come back. Select the same two providers, in the same browser, to reopen it. An unpaid project is kept in the browser it was built in, so another browser or machine, cleared browsing data, or signing out loses it for good. Connected accounts and paid batches stay in your workspace, so a lost project can be rebuilt from them. "Creating a migration project" covers it.
• A paid batch cannot be found. It is in the migration history of your VaultMe workspace, under the project's name. "Paying for and starting a batch" covers it.
• An account holder says content is missing. Work through the checks in order: most content reported missing turns out to be somewhere else in the destination account. "Reviewing migration results" lists them.
• Item counts do not match. A difference is common, and on its own it does not mean anything went wrong, for any content type. "Reviewing migration results" covers where differences come from.
• The destination uses a different amount of storage. That is expected, in either direction. "Reviewing migration results" covers why.
• Items are listed as skipped. Skips are recorded in the report by design, each with its reason. Decide which matter, and handle those by hand from the source. "Reviewing migration results" covers judging them.

Write to support@vaultme.com when something needs doing that you cannot do yourself, and include the batch or migration ID along with what needs doing. Most contact goes the other way, though: VaultMe watches its own runs and gets in touch when something needs you, so silence usually means all is well. "Monitoring a migration" covers when to write in.