Knowledge Center
VaultMe homeStart your migration
Outlook to Google Workspace Migration Knowledge CenterSetup and executionSetting up and running a migration

Setting up and running a migration

An overview of how a migration project runs in the VaultMe app, from the point where planning ends to the point where the project is closed out. Every stage named here has its own article in this section.

What does setting up and running a migration involve?

Everything in this section assumes the planning is already done: which user accounts are migrating, where each one is going, what content comes along, whether each account arrives as a live account or as an archive, how each side gets connected, and roughly when the run happens. The VaultMe app asks for none of it. It takes the plan you arrive with and carries it out, and "What has to be decided before opening the app?" maps each of those decisions onto the screen here that consumes it. If that groundwork is not in place yet, start with the "Planning and preparation" section instead, which "Getting ready for a migration" opens.

With a plan in hand, the work left inside the app is short. Putting a project together is mostly selecting and pasting rather than deciding, and on a handful of accounts it is comfortably one sitting. What stretches a migration across weeks is almost never the app — it is waiting on other people and on the run itself. "Which parts of this need an admin at the keyboard?" sets out where that time actually goes.

The work falls into three phases. First you assemble a migration project and let VaultMe validate it. Then you pay for that project and start the batch it becomes. Finally you check what arrived and close the project out.

Three terms carry the whole section, and they are worth separating before anything else:

  • The VaultMe workspace is your durable working area, created for you the first time you sign in. It holds the accounts you have connected and every batch you have ever run, and signing in to it is the only route back to your migration records.
  • The migration project is what you assemble: the accounts, their pairings, and the content settings that go with them. It is editable throughout, and it costs nothing.
  • The batch is what payment turns the project into — the set of migrations that run together, from one project, as one commitment.

"Creating a migration project" sets those terms out properly. Payment is the hinge between the second and the third: everything before it is editable and free, and everything after it is reported to you rather than configured by you. It is also the one step in the sequence that cannot be reversed from inside the app; "What has to be true before a batch can start?" covers what it commits you to.

VaultMe's own part of your Outlook to Google Workspace migration ends with content copied into the destination and reported on. The switch that makes the destination the side people actually work in, the tidying inside the destination accounts, and retiring the source afterwards are all yours, on a plan made in "Planning the cutover and domain switch". Done properly, all of this ends with content in the destination accounts, confirmed by the people who use them, and a project closed out with its records kept somewhere you can still reach them.

What has to be decided before opening the app?

All of it. The VaultMe app is built to carry out a plan, not to help you arrive at one: no screen in this section asks what you are trying to achieve, weighs one option against another, or tells you that a choice looks wrong for your project. A project built on guesses is assembled, priced, and run exactly like a project built on a plan, and the difference between the two only becomes visible afterwards. "Getting ready for a migration" is where that plan comes from.

Each planning decision turns into something concrete on a screen in this section:

One artifact carries the plan into the app, and it is worth keeping current: the account list, held outside VaultMe as a two-column spreadsheet, with source addresses in one column and the destination each is paired with in the other. That is the shape the app takes directly, so the list is pasted rather than retyped — which is what makes rebuilding a project quick, standing up the next wave of a phased rollout quick, and handing the work to a colleague possible at all. "Getting ready for a migration" covers what belongs in it, and "Connecting and adding user accounts" covers what it buys you.

One decision is not handed over from planning, and it is the one people make without noticing: which Google or Microsoft identity you sign in to VaultMe with. It is worth a moment's thought, because that identity owns your workspace and is the only way back to your own migration records long after the run is over. "Creating a migration project" explains what to weigh.

How is a migration project put together?

Four pieces of work go into a project:

  1. The project itself. You sign in and select the source and destination providers, and an empty project exists from that point on. A few minutes' work, covered in "Creating a migration project".
  2. The user accounts. The accounts on both sides have to be connected to VaultMe, the source accounts added to the project, and a destination account paired with each one. This is the long pole of the stage by a wide margin, and "Connecting and adding user accounts" covers every route through it.
  3. The pre-migration scan. It begins on its own as accounts arrive and reports back two things: the measured price and duration of the migration, and a list of to-dos naming whatever still stands between the project and a run. "Running the pre-migration scan" covers what it checks and how findings are cleared.
  4. The migration options. Which content types each account migrates, and how migrated content is organized in each destination account. The defaults already match what most projects want, so this is usually a confirmation rather than a task. "Choosing migration options" covers both settings.

Those are four pieces of work rather than four steps of a wizard, and only the first two are genuinely sequential. Once the accounts are in the project, the scan, the to-dos it raises, and the options all live on the same screen and are worked in whatever order suits you, as many times over as you like. Adding another account starts another round of the scan, so a list assembled gradually is being validated continuously as it grows.

How long the accounts take depends almost entirely on how they get connected. Where you hold administrative access to an environment, one authorization covers that whole side and accounts are then connected from their email addresses alone, in bulk, without involving the people who hold them. Whatever that authorization cannot reach falls to connection links instead, which means waiting on those people one at a time.

All of which points at one piece of advice: assemble the project early, well before you intend to run anything. The scan starts reporting as soon as there is something to report, and a good share of what it reports is not yours to clear — an account holder has to connect an account, a service has to be switched on in a provider's own console, storage has to be bought. Surfacing that a week early costs nothing and saves the schedule. "Running the pre-migration scan" covers who owns which kind of finding.

Two properties of this whole stage are worth keeping in mind. Nothing is charged and nothing is committed: pre-migration scans are free, the price is shown long before there is any obligation to pay it, and the project can be emptied, rebuilt, or abandoned without consequence. And the project under configuration lives in the browser you built it in rather than in your workspace, which is why you cannot stage several projects in advance, cannot hand an unfinished one to a colleague, and should not sign out in the middle of building one. "Creating a migration project" and "Creating a migration project" cover what follows from that.

The stage ends with the project reporting itself ready to migrate, at a price measured from the content actually in the accounts rather than estimated from their number.

What has to be true before a batch can start?

Two conditions, and only two. The project has to have nothing outstanding against it, and the batch has to be paid for.

The first condition is project-wide rather than per account. Paying converts the whole project into a batch, and a batch cannot be built out of part of a project, so one unresolved to-do against one content type on one user account holds up everything. Migrating the accounts that are ready and dealing with the rest later is not something you can do inside a single project; what that situation actually calls for is a smaller project, as "Running the pre-migration scan" explains.

The second condition splits in a way most admins do not expect. Paying does not start anything — it creates the batch and leaves it waiting. Starting it is a separate, explicit act, and the gap between the two can be minutes or weeks, because a paid batch can wait indefinitely. "Paying for and starting a batch" covers both.

That gap is also the whole of the timing control the VaultMe app gives you. Nothing runs on a schedule and nothing can be set to begin at a future hour, so a run starts when somebody is there to start it. A cutover planned around a particular window therefore needs somebody available at that window, which is one of the practical constraints behind "Planning the migration timeline".

The two acts commit you to different things:

  • Paying fixes the configuration. The accounts, the pairings, the content scope, and the organization method are all settled from that moment. The batch reports on itself from then on; it does not take changes.
  • Starting decides refund eligibility. A batch cancelled before it starts is treated differently from one cancelled after processing has begun. Stopping a run that is already under way is also a request to support@vaultme.com rather than an action in the app. "Pricing and payment" sets out the rules.

Which makes one thing worth confirming before the start rather than after: that end users know what to avoid while their own account is migrating. "Preparing stakeholders and end users" covers what to ask of them.

What happens once a batch is running?

Nothing, from you. Starting the batch was the last action required of you, and a running migration has no operator — there is nothing to feed it, nothing to approve, and no stage that stops and waits for a decision.

VaultMe monitors its own runs and gets in touch where something genuinely needs you, so you are not relied on to catch trouble by watching a screen. Checking in is a matter of interest rather than duty, and "Monitoring a migration" is written for the times you do.

It helps to know what a healthy run looks like, because it looks less tidy than people expect. Every migration in the batch starts at the same moment and then proceeds at its own rate, so accounts sit at different stages, some go quiet for long stretches, and completions land spread out over hours or days. For most of its life a batch is partly finished. None of that is a symptom of anything.

The finishing time is a projection rather than a commitment, and it moves as VaultMe observes how the accounts in front of it actually behave. Estimates shifting during a run is expected, not a warning sign; "What determines migration duration" explains what drives the figure. A schedule with headroom in it absorbs the movement without drama, which is what "Planning the migration timeline" is for.

There is exactly one signal that anything needs attention: a migration that has paused, and that states why it paused. The reason is one of two kinds. Either it is VaultMe's to clear — a provider limit, a provider-side fault, something operational already being worked on — in which case nothing is asked of you. Or it is a condition inside the connected accounts that only you can put right, most often a connection that has dropped, but also a destination account out of storage or a service switched off. "Monitoring a migration" covers how each is resolved.

Everything else on the screen is simply a run in progress, including the things admins most often read as trouble: slowness, silence, accounts finishing far apart, and a skipped-item count that climbs. If VaultMe does not say something is wrong, nothing is. Reading the screen itself — what it reports, and where — belongs to "Monitoring a migration".

What is left once the migration completes?

A completed batch is a full account of VaultMe's own work, and it is meant to be read as one. Completion means VaultMe indexed the content in scope for each user account, processed every item it found, and recorded an outcome for each one, naming the items it could not copy and the reason for each. Whether that result is what the business needed is a separate question, and answering it takes knowledge VaultMe does not hold: which content actually matters, and what each account holder expects to find in their own account. So VaultMe reports what it did, in full and item by item, and the people who used the accounts are the only ones who can confirm the result — a division "Reviewing migration results" takes as its starting point.

Four pieces of work close a project out, and their order matters more than any one of them, because each gives up a fallback that the ones after it cannot recover:

  1. Check the result. Read the migration reports for what is only visible across a whole account, then get each account holder to look at their own destination account for the content they actually rely on. "Reviewing migration results" covers both halves.
  2. Cut over. Make the destination the side people work in, on the plan already made in "Planning the cutover and domain switch". This is your work, not VaultMe's.
  3. Run the last sync-up migration (delta migration). After the switch rather than before it, so nothing created at the source in the meantime is left behind. "Running sync-up migrations" covers the timing.
  4. Close the project out. Assign the remaining manual follow-up, save the reports somewhere of your own, revoke VaultMe's access, and retire the source on your own schedule. "Wrapping up the project" covers the order and what each step forecloses.

One constraint runs across all four: keep the source accounts live and readable until the review has closed. VaultMe copies content rather than moving it, so the source is both the only thing there is to check the destination against and the only place anything genuinely absent can still be recovered from. Retiring it early does not lose the migration, but it does end your ability to verify or repair it, which is the reasoning behind the triage in "Reviewing migration results".

Two clocks start when the run finishes, and both are easy to forget because nothing about them is urgent on the day. Another sync-up pass stays possible only while VaultMe still holds the index that pairs source items with their destination copies, so the option expires quietly if nothing runs for long enough — see "Running sync-up migrations". And the migration reports outlive the project by a long way but not indefinitely, so a copy kept outside VaultMe is the durable record of what became of each item. "Wrapping up the project" covers what to download and when.

One thing to settle now rather than later: running a migration again is not a repair. VaultMe never inspects what is already in a destination account, so migrating the same accounts a second time writes a second copy of everything rather than filling in gaps, and a sync-up revisits what changed at the source rather than what VaultMe could not do the first time. Skipped items, misplaced items, and genuinely missing content each have their own route, none of which is a re-run. "Wrapping up the project" covers the rare case where a redo really is the answer.

On a phased rollout, these closing steps belong to the project rather than to each wave. A finished batch hands its connected accounts, its history, and its real durations forward to the next wave, which is the subject of "Wrapping up the project".

Which parts of this need an admin at the keyboard?

Three short bursts. You put the project together, you pay for it and start it, and you read the results. Everything between those bursts is waiting, and the waiting is what actually sets the length of the project.

The calendar goes on four things, none of which you can work through faster by staying at your desk:

  • To-dos that are not yours to clear. An account holder has to connect a user account, a license or a service has to be sorted out in a provider's own console, storage has to be provisioned. These are the long pole of setup, which is why they are worth surfacing early. "Running the pre-migration scan" splits them by who can act.
  • The run. It proceeds at whatever rate the providers on both sides allow, and nothing in the app makes it go faster.
  • Account holders confirming their own destination accounts. This is the gate the cutover waits on, and it cannot be done from your desk, because only the person who used an account knows what should be in it. "Reviewing migration results" covers how to ask so the answers are usable.
  • The follow-up that stays with account holders afterwards. Filing what arrived unplaced, re-sharing content, reconfiguring their own clients. "Wrapping up the project" is the register of what is outstanding and who owns it.

Who the project depends on, and what to ask of each of them and when, is the subject of "Preparing stakeholders and end users".

What can be handed to a colleague is limited but genuinely useful. A workspace can hold more than one admin — VaultMe support adds them on request, at support@vaultme.com — and every member sees the same connected accounts and the same batches, so the expensive half of the work is done once and reused by everyone. What cannot be handed over is a project still being configured, since it lives in one browser. A colleague builds the same project from the shared account list instead, which takes a paste. "Creating a migration project" covers the division.

Nothing in this section runs unattended. No batch starts on a schedule, no sync-up migration (delta migration) runs unless somebody starts it, and nothing announces that another person has finished their part — an account that got connected shows up in your workspace, but only when you go and look.

On a handful of user accounts all of this is a modest commitment: a sitting to put the project together, a moment to pay and start, and a short read afterwards. On a large project the work inside the VaultMe app barely grows, because the same screens handle fifty accounts about as easily as five — what grows is the chasing, and it grows with every account holder the project depends on. The app work itself begins in "Creating a migration project".

Ready to start your migration with VaultMe?

Start your migration