Paying for and starting a batch

This article covers the last two actions of migration setup in the VaultMe app — paying for a finished migration project, and starting the batch that payment produces.

What does paying for and starting a batch involve?

Less than any other stage of setup: two controls, a payment between them, and a few minutes of work. There is nothing to configure and nothing left to decide, because every decision was made in the stages before — which accounts are in the project, which content types they bring, and how that content is organized at the destination. This stage only commits them.

What it does have is a deliberate separation into two acts:

• Paying creates the batch. The project becomes a batch, the setup screens are gone, and the migration is ready to run. Nothing is running yet, and nothing will be until it is started.
• Starting runs it. This is a separate, explicit action on the batch, available from the moment the batch exists, and it is the only thing that sets a migration running.

The gap between the two is open-ended. Pay when a budget or an approval allows it, and start at the window agreed with the business, whether that is minutes or days later. That gap is also the only control the app gives over when a migration runs: there is no scheduler, nothing can be set to run at a future time, and no batch ever starts by itself.

Payment is available only on a project with nothing outstanding, and the requirement is project-wide rather than per account. Paying converts the whole project into a batch, and a batch cannot be built from a subset of its accounts, so one unresolved to-do on one account holds up payment for all of them. Why that is, and what the ways out are, is covered in "Running the pre-migration scan".

The price is already known by the time you get here. Checkout reports the figure the project has been showing since its accounts were scanned, split into the fees behind it, rather than a new number arrived at only once you are asked to pay — see the estimates chapter of "Running the pre-migration scan".

Payment is also the point at which the project stops being editable. Until it goes through, the list of accounts and their assigned destinations can still change, as "Connecting and adding user accounts" describes, and so can content scope and the content organization method, which "Choosing migration options" covers. Afterwards none of it can: the batch screen that replaces the project screen reports rather than configures, and the one thing still editable on it is the name.

The free exit, though, does not close at payment. It closes at the start: a paid batch that has not been started yet can still be cancelled for a full refund, and only starting it changes that, as explained in "Pricing and payment".

What the stage produces is a running batch — the Google Workspace to Outlook migration under way for every account in it — watched on the same screen the payment opened, which is where "Monitoring a migration" picks up.

How is a batch paid for and started?

Start from a project whose status reads Ready to migrate, with a price on its summary strip. Everything below is the whole of the app work for this stage.

1. Select Schedule migration on the project screen.

   Despite the name, nothing is scheduled here. The dialog that opens asks for no date and no time, and nothing starts when it closes: this is the payment step.

2. Check the order summary in the dialog — the migration fee, the data fee behind it, and the total.

   This is the figure the project has been showing, itemized. Nothing in the dialog changes it, and how the two fees are calculated is covered in "Pricing and payment".

3. Choose a payment method and complete the payment.

   What you are asked for after choosing a method belongs to the payment provider rather than to VaultMe, so the fields vary by method and by payer. The methods VaultMe accepts are listed in "Pricing and payment".

   A completed payment is what creates the batch. The batch screen takes the place of the project screen, the project draft is cleared out of your browser, and an invoice arrives by email as an attached PDF identifying the batch by its name and its ID. The same invoice can be downloaded from the batch itself at any time afterwards — see "Pricing and payment".

   Stopping at this point is legitimate and open-ended, since nothing is running until the next step. The batch waits in your workspace: "Where is my batch when I come back?".

4. Select Start Migration on the batch screen and confirm.

   The confirmation asks for nothing else — no date, no subset of accounts. Starting takes the whole batch, and the individual migrations in it cannot be started one at a time.

The screen does not change when the batch starts. Progress appears in the rows that are already in front of you, and reading them is the subject of "Monitoring a migration".

What happens after I start the batch?

Nothing takes you anywhere else. The batch screen is the same screen before, during, and after the run, so the progress of the batch and of every migration in it is watched exactly where you already are, with no separate surface to find.

A batch goes as one batch and then stops behaving like one. Every account in it starts together, but each migration runs at its own pace and finishes when it finishes, so accounts completing hours or even days apart is the normal outcome rather than a sign that something went wrong. What sets each account's pace, and what that means for when the batch as a whole is done, is covered in "What determines migration duration".

Nothing further is asked of you. Starting is the last required action: the run needs no browser tab left open, nobody at the keyboard, and no further confirmation at any point. You can close the app and come back to results, and the batch will be where you left it — "Where is my batch when I come back?".

What starting does cost is the cheap exit. Until it is started, a batch can be cancelled for a full refund; once processing has begun, only a partial refund may apply, because migration processing and access costs have already been incurred. Stopping a running batch is also a support request rather than an action in the app — write to support@vaultme.com — and a started batch cannot be edited. The state-by-state rules are in "Pricing and payment".

That is why one thing is worth settling before you press it rather than after: what end users should avoid doing in their accounts while those accounts migrate. The rules themselves, and how long each of them applies, are in "Preparing stakeholders and end users".

From here on the work is reading the run rather than acting on it, which is where "Monitoring a migration" takes over.

In what order should several batches be paid for and started?

This chapter is for a rollout already committed to waves — several batches run in sequence rather than one batch for everybody. Nothing here re-opens that shape or the split behind it: which accounts belong to which wave, and where that list is kept, were settled in planning, and "Choosing a migration strategy" is the article that covers them.

Half of the ordering question is settled by the app rather than by you. Only one migration project can exist at a time, and paying for it is what frees the slot: the conversion into a batch clears the draft, and the next project is begun from your workspace. Building every wave in advance and paying for them together is not available, as "Creating a migration project" explains.

What that leaves is the real question, because paying frees the slot but starting does not. A paid batch can sit at Ready indefinitely while the next wave is being built, so two sequences are possible:

1. Build a wave, pay for it, start it, and then build the next one.
2. Build and pay for each wave without starting any of them, then start the finished set one by one.

The first is the one to use. A paid batch cannot be edited, so paying for a later wave commits to a configuration that the earlier waves may yet change — and changing something in response to how the first wave went is much of the reason for running in waves at all. A wave that has already been paid for cannot take that change; it has to be run as configured or cancelled.

Starting is the looser end of the pair. A later batch can be started while an earlier one is still running, so keeping payment in sequence paces the payments rather than the execution: the waves can still overlap as much as the rollout calls for.

Where paying ahead genuinely earns its keep is a single wave, shortly before its own window. Pay for it a day or two in advance, and starting on the agreed date is one action with no payment left to clear and nobody's approval left to wait for.

Where is my batch when I come back?

In your VaultMe workspace, in its migration history, under the project's name. Every batch the workspace has produced is listed in that history whatever state it is in, and each entry links through to the batch itself. Nothing has to be left open for this, and a batch that has been paid for but not started can wait indefinitely — it will still be at Ready whenever you come back to start it.

That history is also the argument for giving a batch a deliberate name. VaultMe suggests one and keeps it current for as long as it is left alone, building it from what it knows about each side: the provider names while a side has no accounts, and that side's domain once it has some. Two waves of the same Google Workspace to Outlook migration therefore arrive in the list reading almost identically, and the list only grows with every batch the workspace runs. The name is the one thing carried over from the project that is still editable on the batch, so it can be put right there — click the title and rename it in place, exactly as on the project.

The invoice email is the other way back. It links straight to the batch, so it works as a bookmark for anyone who has the email but not the app open. What the attached invoice carries, and how invoices are downloaded and completed afterwards, is covered in "Pricing and payment".

What happens if a payment does not go through?

Nothing is at risk. A batch exists only once a payment has completed, so a declined payment leaves the project exactly as it was: still a draft, still priced, still ready to migrate. VaultMe reports the decline together with whatever reason came back with it, and that is the whole of the consequence.

Retry as often as you need to. Nothing is consumed by a failed attempt and nothing has to be rebuilt — try the same method again, try a different one, or close the dialog and reopen it from Schedule migration. There is no penalty for a run of failures and no state to clear up between them.

Coming back another day works too, with one condition: it has to be the same browser on the same machine, because that is where the project draft is held. The project restores itself when you return to it, and paying for it then is no different from paying for it now. What that dependency covers, and what breaks it, is explained in "Creating a migration project".

The cause usually sits outside VaultMe. Most declines come from the payer's bank or from the payment processor rather than from anything about the project, and VaultMe can report what came back but can do nothing about it — a decision that belongs to a card issuer stays with the card issuer. The common causes, and what to check on the payer's side, are listed in "Pricing and payment".

Where retrying does not clear it, write to support@vaultme.com. Support can confirm what VaultMe saw of the attempt and give what context there is, but a bank-side decline is resolved with the bank.