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 a Microsoft 365 to IMAP-compatible mail system 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. Global Administrator access to the source Microsoft 365 tenant, if available. With it, you connect the whole tenant 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.

3. IMAP credentials for every destination mailbox. Each one is connected with its server host name, login, and password, once IMAP access is enabled for it, and the credentials have to allow adding mail. "Choosing a connection method" covers the details.

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. 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. Registrar or DNS access, if the domain moves at cutover. Repointing mail at the destination means editing the domain's DNS records, and access to them routinely sits with someone outside the project. It is the most common reason a cutover date slips, so find out now who holds it. "Planning the cutover and domain switch" covers the switch itself.

6. 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.

7. 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. "Building the migration inventory" covers the call.

3. Sweep the source for anything that is not a user account but has to come along, and give each item a path.

   "Building the migration inventory" covers what to look for.

4. Confirm with the people who use the accounts that email is the only content that migrates.

   A Microsoft 365 to IMAP-compatible mail system migration carries email alone, so calendars, contacts, and files stay where they are unless someone plans for them separately. "Selecting content for migration" covers what each content type includes.

5. 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

6. 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.

7. Select Microsoft 365 on the Migrate from card and IMAP on the Migrate to card, then select Create migration project.

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

8. 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.

9. 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.

10. 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.

11. 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.

12. Have every destination mailbox created on the server, with IMAP access enabled for it.

    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.

13. 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.

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

    In a Microsoft 365 to IMAP-compatible mail system migration, VaultMe cannot read how much storage a destination mailbox has left, so compare each source's scanned size against the free space in its mailbox with whoever runs the server, and leave headroom. "Getting the destination ready" covers what to do when storage falls short.

15. For every account marked archived on your list, set Method to Separate from existing content.

    Every account starts on the merge method, so active accounts need no changes. "Choosing migration options" covers the setting.

Pay and start

16. 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.

17. 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.

18. 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.

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

20. 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

21. 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.

22. 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.

23. Cut over once the account holders confirm.

    Switch mail delivery to the destination: repoint the domain's mail (MX) records at it, or, where the domain stays with the source, forward each old address to its new one.

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

24. 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.

25. 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.

26. 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 mail server and a mailbox on it for every account, along with access to the registrar or DNS where the domain's mail will be repointed.

   None of it is VaultMe work, and whatever depends on someone outside the project is the usual reason a cutover slips. "Getting the destination ready" covers what the destination needs.

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 keep-or-drop call on each departed employee's account is management's to make, not yours, and waiting for it is what turns this week into next, so raise it first. "Building the migration inventory" covers which accounts to keep.

4. Mark every account on your spreadsheet 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. "Building the migration inventory" covers the call.

5. Sweep the source for anything that is not a user account but has to come along, and give each item a path.

   Do it with IT and management: the resources easiest to miss are the ones nobody thinks of as theirs. "Building the migration inventory" covers what to look for.

6. Confirm with the people who use the accounts that email is the only content that migrates.

   A Microsoft 365 to IMAP-compatible mail system migration carries email alone, so calendars, contacts, and files stay where they are unless someone plans for them separately. "Selecting content for migration" covers what migrates and what does not.

7. Write down everything people use that will not migrate, and give each item an owner.

   In a Microsoft 365 to IMAP-compatible mail system migration, only email migrates, so everything else is out of scope by definition, and this list is real project work rather than a formality. "Selecting content for migration" covers what stays behind.

8. Decide how the source connects: once for the whole Microsoft 365 tenant, with Global Administrator access, or account by account, through connection links.

   Aim for the single connection wherever that access can be secured for whoever runs the migration. Where it cannot, every account waits on its holder opening a link, and that legwork sets the pace of the rollout. "Choosing a connection method" covers both routes.

9. Collect IMAP credentials for every destination mailbox, with IMAP access enabled for it and permission to add mail.

   Account holders could connect their own mailboxes through a connection link, but collecting the credentials centrally and connecting the mailboxes yourself is usually the easier route. "Choosing a connection method" runs through what both sides need.

10. 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.

11. 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.

12. 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.

13. 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 Microsoft 365 on the Migrate from card and IMAP 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. Prepare every shared mailbox and SharePoint library in scope along the path you assigned it: give each shared mailbox a license and credentials, so it connects as a regular user account, and make sure each SharePoint document library, including the files behind Teams and Microsoft 365 Groups, has the connected account with access that you assigned to carry it.

   Connecting the tenant does not bring any of these along by itself. "Getting the source ready" covers the preparation.

6. 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.

7. Have every destination mailbox created on the server, with IMAP access enabled for it.

   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.

8. Select Add accounts again and switch to the Advanced tab. Connect your destination mailboxes 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. In a Microsoft 365 to IMAP-compatible mail system migration, VaultMe cannot read how much storage a destination mailbox has left, so compare each source's scanned size against the free space in its mailbox with whoever runs the server, and leave headroom. "Getting the destination ready" covers what the checks confirm, and "Connecting and adding user accounts" walks through pairing in full.

9. Freeze password, multi-factor authentication, and admin configuration changes on every connected account from here until the final sync-up is done.

   Each of them can silently drop a connection, and VaultMe pauses the migration until it is restored. "Getting the source ready" covers the rest of the housekeeping.

10. 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.

11. 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. "Preparing stakeholders and end users" covers what to tell whom.

12. 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. For every account marked archived on your spreadsheet, set Method to Separate from existing content.

   Every account starts on the merge method, so active accounts need no changes. "Choosing migration options" covers the setting.

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 Microsoft 365 on the Migrate from card and IMAP 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.

   Switch mail delivery to the destination: repoint the domain's mail (MX) records at it, or, where the domain stays with the source, forward each old address to its 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, then withdraw its licenses, 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.
• 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.