Getting the destination ready

This article covers the technical work that makes a destination able to receive migrated content, and how to confirm it really can.

What does getting the destination ready involve?

The work has one organizing question behind it, and it is worth keeping in mind throughout: what has to be true in the destination so that VaultMe can write everything expected, for every user account in the migration inventory, with sufficient storage to hold it? Once you can answer that for every account on the list, the destination can be set aside as ready.

The migration inventory is where this starts. It lists what leaves the source, and each entry needs somewhere on the destination side to land. What VaultMe connects to and writes into is a user account, so destination readiness is settled one account at a time: is the account there, can VaultMe write to it, and can it hold what its source counterpart will deliver? Building that list, and deciding whether each entry migrates as active or archived, is the subject of "Building the migration inventory".

Ready, in the end, means three things are true. They are worth separating because different people usually own them and they run on very different clocks:

1. The environment exists. A Microsoft 365 tenant is in place, with the domains the destination accounts will use added and verified.
2. Every in-scope account is provisioned, licensed, and has the services it needs. The account exists, carries a license covering the content types in scope, has those services actually switched on, and has sufficient storage for what its source counterpart will deliver.
3. VaultMe can connect to each of those accounts and write to it. Either the environment is connected once and the accounts inside it come along, or each account is connected on its own — and in both cases with the permissions a destination needs, which include writing.

Connecting the destination is part of readiness, but how it connects is a decision in its own right, and the mechanics belong with the decision — see the destination chapter of "Choosing a connection method". What this article covers is narrower: the destination-side conditions that connection depends on, and what keeps it alive afterward.

How much of this is real work depends entirely on what already exists, and for many migrations the answer is very little. A destination that is already in use — environment running, domains verified, seats provisioned and licensed, storage generous — needs no provisioning at all. Connect it, scan it, and you are done. The work grows when the environment does not exist yet, when domains are changing, when licenses or services still have to be assigned, or when storage is tight against what is arriving.

None of the provisioning is VaultMe's to do. VaultMe cannot create an environment, buy or verify a domain, create user accounts, or assign licenses. It fills destination accounts that already exist and that it has been given access to, and its part of the work starts once the destination exists and is connected.

That division matters most for the slowest items, which is why they are worth naming now rather than in the chapter that covers them. Standing up an environment, buying a domain, verifying it, and warming up a brand-new domain all sit outside VaultMe, usually need people beyond the admin running the migration — whoever can commit the organization to a contract, whoever controls the domain registrar — and take days or weeks rather than minutes. Start them first. Everything else waits behind them, and a long-lead item left late is the most common reason a migration date slips, which is why the scheduling chapter of "Planning the migration timeline" places these items at the earliest end of the calendar.

One last thing to know before any of the work begins: no amount of inspecting the destination will tell you it is ready. Licenses assigned and seats created get you close, but the only real proof is a migration project in VaultMe with the source and the destination both connected, followed by the free pre-migration scan described in "How VaultMe works". A destination is ready only in relation to the source it has to receive: whether a seat has sufficient storage, or the right service for the content headed to it, cannot be answered without knowing what that content is.

What the work delivers, then, is an environment provisioned, every in-scope account licensed, activated, connectable, and holding sufficient storage, and a scan against the source that proves it. The last chapter gathers all of it into one list to run through — "A checklist for destination readiness".

Provisioning the destination environment

If the destination environment already exists and its domains are settled, there is nothing to do here. Skim and move on. This chapter is for standing one up, or for changing the domains the destination will use.

Nothing can be connected until the environment itself exists — a Microsoft 365 tenant — and creating it has nothing to do with VaultMe. It gates everything else in this article, so it is the first thing to get moving.

What makes this step slow is rarely the sign-up form. It is who is allowed to complete it. Creating an environment means accepting billing, agreeing to the provider's terms, and asserting ownership of a domain, so it takes someone with the authority to commit the organization. When you are migrating on a customer's behalf, that person is usually not you, and signing up on their behalf is usually not an option. Treat it as a coordination task: find whoever holds that authority and the budget, get them to do it, and budget the calendar time it takes to reach them.

Sign-up means subscribing to a Microsoft 365 business plan. The first work account created becomes the tenant's Global Administrator, and the tenant is managed from the Microsoft 365 admin center from then on. A new tenant also comes with an onmicrosoft.com domain immediately, which is more useful than it looks: accounts can be created and staged on that domain while a custom domain is still being verified, so account provisioning does not have to wait for the domain work to finish.

Domains are the other environment-level item to settle, because they decide the addresses the destination accounts will carry. Most migrations keep the domain that already delivers mail to the source; a few take the opportunity to move to a new one, after a rebrand or a merger, and that is a normal choice rather than an exotic one.

Whichever domain it is, it has to be added to the destination environment and verified there, and verification means proving control of the domain by publishing a DNS record for it wherever the domain is registered. That is often the first point where the work leaves the migration team altogether: the person who can edit those records may be a web agency, a former IT provider, or an account nobody has signed into in years. A domain that has to be bought first adds procurement on top of that. None of it is VaultMe work, and all of it is slow enough to be worth starting before anything else on this list.

Two further environment-level items belong on the calendar even though this article does not teach them. The first is mail authentication: the SPF, DKIM, and DMARC family of records, published for the domain to tell receiving mail systems which servers may legitimately send on its behalf. They are configured once at the environment level and they are the organization's or its IT team's to plan. The second is domain warm-up. A brand-new domain that suddenly starts sending business volumes of mail risks being treated as spam by the systems receiving it, which is why larger organizations warm a domain up, raising send volume gradually over weeks or months to build a sending reputation. Neither is a VaultMe step and neither is quick; name them early so whoever owns mail deliverability can plan them with the lead time they need.

The pattern across this whole chapter is the same one: environment-level preparation is gated on authority you may not hold, coordinated with people outside the project, slow, and entirely external to VaultMe. That is exactly why it goes first.

Provisioning accounts, licenses, and services

Inside the environment, this is the destination-specific core of the work, and it is mostly administrative: every user account the migration will write to has to exist, carry a license, and have the services for the in-scope content types switched on. All of it happens in the Microsoft 365 admin center, and none of it is something VaultMe can do on your behalf.

What gets provisioned follows the active-or-archive decision already recorded in the migration inventory. An account migrating as active — somebody will keep working in it — needs its own provisioned, licensed seat. Archived content does not: it is normally consolidated into a smaller number of seats, which is the main reason the distinction was drawn in the first place, since it keeps destination licensing and spend down. The decision is per account rather than global, and a single project routinely mixes both, as the active-or-archive chapter of "Building the migration inventory" explains.

Licensing itself is usually simpler than admins expect. A license in Microsoft 365 normally bundles everything — mail, files, calendars, contacts — so there is no per-content-type licensing to work out and nothing separate to buy for each. What is worth checking is that the license actually assigned to each account covers the content types in scope, because a cheaper or custom license can leave one out, and a mail-only plan will not accept files however correct the rest of the setup is.

A license is not quite the same thing as a live service, which is the second half of this chapter: confirm that the in-scope services are actually active on each destination account. Most of the time this is automatic — the license is assigned and the services appear — so it is usually a confirmation rather than a task. It is still worth confirming per account instead of assuming, because an account whose service was never activated looks correct in every other respect and content headed for that service has nowhere to go. OneDrive is the case that catches people out: it can be included in an account's license and still not be provisioned until the account has been signed into for the first time. Where files are in scope, provision it deliberately rather than trusting that the license brought it along.

Per-content-type configuration has nuances beyond this, and they belong to the articles that own each content type. At this stage the job is narrower: confirm that what is licensed and activated on each account matches the content types in scope, and record it next to that account in the inventory so nobody has to reconstruct the check from memory later. And bear in mind what an assigned license and an activated service are not. They are necessary, but they are not evidence that content will land — that comes from the scan, in "Confirming the destination is ready".

Making sure VaultMe can connect to the destination

With the environment standing and its accounts provisioned, there is finally something to connect. How the destination connects — one environment-wide admin grant, or each account connected on its own — is chosen and explained in "Choosing a connection method". That article owns the choice and the mechanics, so this chapter covers only what is left to readiness: the destination-side conditions the connection depends on, and what keeps it working once it exists. One fact underpins both. A destination connection grants read and write access, because VaultMe has to create content in the account and read back what it has created there.

On a managed destination the recommended path is a single environment-wide grant, and it has to come from a genuine top-tier administrator of the destination environment — a Global Administrator, not a lesser admin role that merely sounds senior. Where no such grant can be had — a destination organization unwilling to give an outsider top-tier privileges, or a policy that rules it out — the alternative is to connect each in-scope account on its own, which is a normal fallback rather than a setback.

Whichever method is used, the accounts have to be active as well as provisioned, since an account that exists but is suspended cannot be written to — which is why provisioning comes before connecting rather than after. Where accounts are connected one at a time, each account holder also has to be reachable, willing to complete the connection, and able to clear whatever multi-factor authentication (MFA) challenge their account presents. That is people work rather than configuration, and it tends to set the pace of a project — the subject of "Preparing stakeholders and end users".

Once a connection exists, it is easier to break than most admins expect. A password reset, a change to MFA, or an environment-level admin configuration change affecting a connected account can invalidate the connection, and when that happens VaultMe pauses rather than fails — it waits until the connection is restored and then carries on. Restoring one is not hard, but it is not instant either, so the working rule is to avoid identity changes on connected accounts from the moment they are connected until the run is finished, and to coordinate the unavoidable ones with reconnection. There is a fuller list of this kind of housekeeping in "Pre-migration hygiene on the destination".

One reassurance is worth having ready, because it is the question that most often stalls a destination grant. An environment-wide grant is technically broad — it covers the supported accounts in the environment, not a hand-picked subset — but VaultMe only reads and writes the accounts and content inside the migration scope you configure. Nothing outside that scope is read, written, or indexed, which is stated in "What VaultMe does not do with customer data" for anyone who needs it in writing.

Making sure there's sufficient storage

Every destination account needs sufficient storage for what its source counterpart will deliver — and, where content is merging into an account somebody already uses, for what that account is already holding. Of all the readiness conditions this is the one most often discovered late, because it is the one that cannot be worked out from a spreadsheet.

The reason is that the amount arriving in a given account is the real size of the source paired with it, and that number comes from the pre-migration scan rather than from anyone's estimate. It is also not a figure to take too literally. Migrated content is not expected to occupy exactly the same storage at the destination as it did at the source: it can end up larger or smaller, because destination providers reformat and repackage most content rather than storing it byte for byte. Files kept in cloud file storage are the exception — those are accepted as they are and keep their size — while email and documents are where the difference shows up most. So allow a margin rather than sizing each account to the last gigabyte.

When storage falls short, there are three levers, and all three are the customer's rather than VaultMe's:

• Assign a larger license or plan to the account, where the storage allowance comes with the plan.
• Add storage to the account, where the provider sells extra storage separately from licensing.
• Trim the source scope so that less arrives in the first place — fewer accounts, or less content per account.

Archive consolidation deserves a deliberate thought of its own here. When several source accounts' content is landing in one seat, that seat needs sufficient storage for the combined total. Each source can look modest on its own and still add up to something the destination seat cannot hold.

Storage is also the clearest illustration of why a destination cannot be checked in isolation. Nothing about a destination account on its own tells you whether its storage is sufficient; only the pairing with a specific source does, which is what "Confirming the destination is ready" is about.

Pre-migration hygiene on the destination

Beyond provisioning, a short list of housekeeping items keeps the destination connectable and avoids surprises as content lands. None of it changes what migrates or how — it is about not letting the destination work against the migration once it is under way.

• Turn off automated rules on destination accounts. Inbox rules, filters, auto-forwarding, and auto-delete settings act on mail as it arrives, and migrated mail does arrive. A rule written for everyday use can quietly re-file, forward, or delete messages VaultMe has just written. Switch them off until the migration is finished, then put them back.
• Disconnect non-essential third-party apps and automation. Anything still working inside a destination account draws on the same provider capacity the migration needs, and changes it makes to content that has already been migrated create reconciliation work later. Trim what can safely be paused before the run, without going so far that people cannot do their jobs.
• Freeze identity changes on connected accounts. No password resets, MFA changes, or admin configuration changes on a connected account between connecting it and the end of the run. Each of those can drop the connection and pause the migration until it is restored. Where one genuinely cannot wait, plan the reconnection alongside it.
• Do not pre-fill destination accounts. It is tempting to move a few things across by hand ahead of time, or to reuse a seat that already holds content. Both invite duplication and confusion once VaultMe writes into the same account, and most of all for a seat that is holding consolidated archives, where the whole point is that each archive stays separate and easy to find. Keep destination accounts clean and let the migration fill them.

What this chapter is not is guidance for end users about their own accounts while the migration runs. That is a separate conversation with a different audience, and it is covered in the during-the-run chapter of "Preparing stakeholders and end users". Here it is admin-side destination preparation only.

Confirming the destination is ready

Planning gets the destination close, and the admin console makes it look finished. Neither is proof. The only way to know the destination is ready is to create a migration project in VaultMe with the source and the destination both connected, and run the free pre-migration scan. Assigning licenses and creating seats is necessary work, but it is not the same as knowing that content will land.

Why both sides have to be connected is the heart of this article. A destination is ready only in relation to what is coming into it. The scan pairs each source account with the destination account mapped to it, and then checks that pairing: that the destination account exists, connects with write access, has the services the in-scope content types need, and has sufficient storage for that particular source's measured size. There is no source-free version of that check. An inspection of the destination alone cannot tell you that a seat has sufficient storage, because the answer depends entirely on what is arriving.

That is the sharpest difference between the two sides of readiness, and it is worth stating plainly. The source can be scanned on its own: a source-only project is a normal, expected way to prove the source is readable long before a destination exists, as the confirming chapter of "Getting the source ready" describes. The destination cannot. It has to be scanned against the source it will receive.

On the destination side, the scan reports whether each account is reachable and writable, and raises everything it can observe as something to fix: a missing license, a service that was never activated, insufficient storage for the source the account is paired with, permissions that are wrong or incomplete. The scan also reports the real per-account size on the source, which is the number to check destination capacity against. The prerequisites it enforces are set out in "Before you migrate", and "Running the pre-migration scan" covers how each item raised is worked through and cleared.

What the scan cannot see deserves to be just as clear, and the boundary is simple: it checks what it can reach through its connections — the destination accounts and what can be written into them — and nothing beyond that. Environment-level work is beyond it, so the scan will not tell you whether mail authentication is in place or whether a new domain has been warmed up. Neither will it tell you anything about the parts of the project that run on people rather than configuration: an approval still to be given, a domain change still to be coordinated, a date still to be agreed. A clean scan means VaultMe can write the destination for this source. It does not mean the project is ready.

Run it early rather than on migration day. The scan is free, needs no payment method, and can be re-run as often as you like, so the habit worth forming is to run it as soon as both sides are connected, fix what it flags, and run it again. Nothing is committed until a batch is paid for and started, so there is no cost to finding problems early — and where the scan belongs in the schedule is part of "Planning the migration timeline".

A checklist for destination readiness

Run through this top to bottom — it follows the order the work is done in. The first item is the slowest, and the last is the only one that proves the rest.

1. Environment in place. Either it already existed, in which case there is nothing to do here, or it has been created by whoever can commit the organization — who becomes its first top-tier administrator. Wherever domains are new or changing, they have been bought and secured if they had to be, added and verified, and assigned to the accounts that will use them, with mail authentication and any domain warm-up planned well ahead with whoever owns deliverability.
2. Licenses assigned. Every in-scope account exists and carries a license that covers the content types in scope, following the active-or-archive split from the inventory — own seats for active accounts, consolidated seats for archived content.
3. Services active. The services the in-scope content types need are actually switched on for each account, not merely included in its license. Where files are in scope, check that OneDrive has been provisioned rather than only licensed.
4. Connection method settled and the destination connected with write access. Either an environment-wide grant from a Global Administrator of the destination environment, or every in-scope account connected individually.
5. Sufficient storage on every account for what its source will deliver, with a margin above that figure, and for consolidated archive seats the combined total of everything landing in them.
6. Housekeeping done. Automated rules and forwarding disabled on destination accounts, non-essential third-party apps and automation trimmed, and no credential, MFA, or admin configuration changes pending on any connected account.
7. Scanned against the source. A migration project created in VaultMe with the source and the destination both connected, the pre-migration scan run, its to-dos and pending actions cleared, and each destination account confirmed to have sufficient storage and the right services for the source it is paired with.

With that done, the destination is proven against the source and both sides of the migration are ready. What is left is the shape of the rollout and the calendar around it: "Choosing a migration strategy" decides whether every account migrates in one batch or in waves, "Planning the migration timeline" turns that shape into a schedule, and "Planning the cutover and domain switch" covers the switch onto the destination once VaultMe has finished its part. All of it stays reversible until a batch is paid for and started.