Preparing stakeholders and end users

Getting ready for a migration also means getting the people around it ready. This article covers that side of the preparation: what the people a migration affects are told, what is asked of them, and when.

What does preparing stakeholders and end users involve?

By the time this work comes up, most of the preparation is behind you. Scope is settled, both sides are technically ready, and VaultMe's pre-migration scan can confirm a good deal of it. What no scan can see is people. It will tell you that a destination account has no license, or that a service was never activated; it will never tell you that an end user has no idea their mail is being migrated this weekend, or that the one person who has to connect an account is away during the cutover week. Nobody checks that half of readiness for you — the distinction between what the scan can gate and what it cannot is drawn in "Getting ready for a migration".

Two things go wrong when it is skipped, and both are cheap to prevent. The first is people who were not told. They find out at the switch itself, when the account they open is not the one they were working in yesterday — and with no warning, every difference reads as a fault rather than a plan. Support gets every question on the same morning, and for weeks afterward anything anybody cannot find is blamed on the migration whether or not the migration touched it. The second is people the plan depends on who are not there when it needs them: an account holder who never opened their connection link, a manager whose sign-off was assumed, an administrator on holiday during the cutover window. Neither problem is technical, and neither is expensive to avoid — but neither can be fixed on the day.

How much of an exercise this is depends almost entirely on the size of the project. Migrating a handful of accounts is mostly common sense: one conversation, one email, and everyone involved already knows what is happening. A large migration needs a real communication plan, and a phased one needs it repeated for every batch — see "Choosing a migration strategy" for how that rollout shape is decided. Read the rest of this article at the scale you are actually working at.

It also helps to be precise about who "people" means here, because the groups need very different things from you:

• Account holders whose own accounts are migrated. The largest group by far, and the audience for most of what follows. They keep working in the source while the run happens, some of them have to connect their own account, and all of them end up in the destination at cutover.
• Whoever knows what is in each shared drive. A shared drive is nobody's daily workspace, which is exactly why it is the easiest thing in the inventory to forget. It still needs a person attached to it, because only they can tell you afterward whether it came across intact.
• Internal IT and support. Whoever fields questions inside the organization. They do not run the migration, but they absorb its aftermath, and they can only do that if they were briefed before it started.
• Business stakeholders who approved the scope. Management, department owners, whoever signed off on the cost. They need to see progress and hear about slipped dates, and nothing else.

Everything below happens before the run rather than during it, and that ordering is the whole point. An expectation set in advance comes back as a question nobody needed to ask afterward, and the size of the follow-up list in "What do end users do at cutover and after it?" is set by how much of this was done early.

Done properly, the outcome is modest and specific: everyone affected knows what is coming, the few people who have to act know what and by when, and every loose end left after the switch has a name against it.

Who does the project depend on?

Most of the people a migration touches only need to be told about it. A few of them have to do something, and until they do, the project cannot go ahead. That distinction is worth drawing early, because the second group is a schedule dependency in exactly the same way that securing a domain or buying licenses is, and it is the one most often left out of the plan — "Planning the migration timeline" shows where it sits in the calendar.

• Account holders who have to connect their own account. In a Google Workspace to IMAP-compatible mail system migration, at least one side is connected one account at a time, so this is legwork you will certainly be coordinating: the account holder opens a connection link, signs in with the provider, and approves the access VaultMe asks for. None of that is difficult, and the mechanics are covered in "Choosing a connection method". What makes it a scheduling problem is that it depends on somebody reading an email. Chasing unopened connection links is routinely the slowest single step in a migration project, and it is what decides who is ready first and who holds up a batch.

  Treat it as a task with a deadline rather than a favor: say which account, which side, and by when, expect to re-send, and know who you can escalate to when someone simply does not answer. Where you connect accounts yourself instead of handing out links, the same coordination applies to multi-factor authentication — whoever completes a connection has to pass that account's multi-factor challenge, so arrange it with the account holder in advance rather than discovering it halfway through.

• Whoever looks after each shared drive. A shared drive is migrated inside the file migration of a connected user account that has access to it, so there is usually nothing to arrange before the run — the drive comes along with that account. What does not go away is the part afterward: only somebody who knows what the drive held can say whether it arrived intact. All this stage needs is a reachable name per drive, recorded while the inventory is being built rather than after the source has been retired. See "Building the migration inventory".

• End users who confirm before their own account is switched. A short check by the person who will live in the destination, before the source stops being the place they work. This is the one ask that repays the effort most, and it is described in "What do end users do at cutover and after it?".

• Internal IT and support. They need to be reachable around the cutover window, and briefed well enough to answer the first day's questions themselves rather than forwarding all of them to you. A half-hour walkthrough before the run is usually the difference.

• Business stakeholders who signed off on scope and cost. What they need is visibility, not instructions: a note when a batch completes, and the first word when a date moves.

The whole defense against this category of delay is one habit: line people up early. Ask for names and confirm they are reachable while you are still building the inventory, check vacations, public holidays, and time zones before you fix the cutover window rather than after, and name one person that end users can actually reach with a question. Everything else in this chapter is a variation on those three.

What should people be told before the migration?

Lead with the reassuring part, because most of the anxiety a migration announcement creates is misplaced. VaultMe copies content rather than moving it: nothing in the source is deleted, altered, or reorganized, and the source stays exactly where it is and fully usable throughout. Migrations are designed to run without downtime, so nobody has to stop working, clear their inbox, or wait for a window to close. For most people the honest summary is that they will notice nothing at all until they are asked to start working in the destination.

The message itself should be short. A long email about a migration does not get read, and the things people genuinely need are few:

• What is being migrated. Name the content types that are in scope and whose accounts are being migrated, in the words people already use for them. "Everything is moving over" invites the wrong questions.
• Roughly when their turn is. Not the project plan — the week their own account is migrated.
• What they will be asked to do, and when. Connecting their own account, checking the destination before it is switched, setting up their mail program again. Listing these in advance is what stops each one arriving as a surprise interruption.
• What will look different afterward. Where their content will be, and what changes about how they reach it.
• Who to ask. One name, and one place to send questions.

The person you have named for a shared drive gets the same message with one line added: the drive is in scope as well, and they will be asked to check it once it has been migrated.

The second half of the message is less comfortable and worth more. Some things do not come across, and hearing about them now is much easier than discovering them alone the morning after. Links embedded in migrated mail and documents still point at the source, so some of them stop working once the source is retired. Mail programs keep their old settings and have to be pointed at the new account by hand. And some items land in a TODO area — a clearly marked container VaultMe creates in the destination for anything it could not place automatically — where a person has to look at them. None of this is a failure, and all of it is ordinary; the detail is in "What do end users do at cutover and after it?".

How the message is written matters as much as what it says. Plain language, and none of the vocabulary you use with VaultMe or with support — the words that make this legible to you make it opaque to everyone else. One named sender rather than a system address. And something written that people can go back to, such as an intranet page or a pinned message, because a single announcement three weeks out has been forgotten by the time the run starts.

On a phased rollout the message repeats per batch, and it works better the more personal it gets. "The migration starts next month" is background noise. "Your account is migrated the week of the 12th, and you will get one email asking you to check it" is something people act on.

What should end users do while the migration is running?

While a migration is running, end users have almost nothing to do and a short list of things not to do. Give each rule its reason when you send it — a rule with a reason is followed, and a rule without one is negotiated.

• Do keep working in the source exactly as usual. This is the default and it is genuinely fine. VaultMe only reads from the source, and anything created or changed while the run is in progress is picked up afterward by the sync-up migration (delta migration) that automatically follows every run. Mail keeps arriving, documents keep being edited, and nobody needs to sit on their hands.

• Do not launch a big cleanup or reorganization in the source. Tidying up before a migration is a good idea and tidying up after it is harmless, but doing it in the middle is not. A sweep of moves, renames, and deletions gives the sync-up pass a large amount of work to redo, and heavy activity on an account competes with the migration for the provider's capacity, which slows the run down for everyone in the batch.

• Do not start working in the destination before that account has finished. This is the one rule worth repeating in every message you send. VaultMe is still writing into that account, and when it meets content or structure it did not expect, it re-synchronizes and rebuilds to get back to the expected state. That costs throughput, extends the run, and makes an incomplete result more likely.

• Do not edit or rearrange content that has already been migrated. The narrower version of the same rule, and the one people break by accident. When a later sync-up pass applies a source-side change to an item, it overwrites whatever was done to the destination copy in the meantime. Where the destination provider keeps revision history, some of that can sometimes be recovered; otherwise it is simply lost. The rules that govern that pass are in "How sync-up migration works".

• Do not change the account's sign-in settings while it is connected. A password reset, a change to multi-factor settings, or revoking the access that was granted can all disconnect the account from VaultMe, and a migration whose connection is broken pauses until it is restored. Restoring it is not something an end user can do — it comes back to you, with VaultMe support sometimes involved — so an unplanned security change during a migration costs real time.

  Installing or authorizing new applications against a connected account is worth postponing for the same reason, and because third-party automation running against the account competes with the migration for the provider's capacity.

Give the list an expiry when you send it, because rules with no end date are either ignored or resented. They apply to one account for as long as that account's own migration is running, not for the length of the project: on a phased rollout, somebody in the first batch is released weeks before somebody in the last. The one that often runs longest is leaving already-migrated content in the destination alone, because sync-up passes keep bridging the gap until the switch is made — that caution holds until the final pass at cutover, which is planned in "Planning the cutover and domain switch".

What do end users do at cutover and after it?

The most useful thing you can ask of an end user is a confirmation before their account is switched over: they open the destination, look for the things they would miss, and say that it looks right. It costs each person a few minutes and does two separate jobs. It catches anything missing while the source is still live and intact — because VaultMe copies rather than moves, the source is still there to compare against, and this is the only comfortable moment to find a gap. And it converts a change being done to somebody into one they agreed to, which changes the tone of every conversation that follows.

Scale the mechanism to the project; the answer is never to drop it. On a small migration it is a message to each person and a reply. On a large or phased one it is a confirmation window per batch: a stated day or two between the batch finishing and its cutover, a reminder partway through, and a rule for what happens when somebody does not answer.

The same check matters most where nobody lives, and that is where it is most often skipped. Nobody opens a shared drive every morning, so nothing about it looks wrong until the person who knows what it held is asked outright — and if that question is only asked after the source has been retired, there is nothing left to compare against. Name a check for every shared drive in scope, exactly as you would for an account.

What is left for end users afterward is a short tail of manual work, and it is genuinely manual — VaultMe cannot do any of it, because in each case only a person knows what matters:

• The account settings in every mail program. Desktop and mobile mail programs keep the settings they already have, so each one has to be set up against the destination server again, including its incoming mail host. It is a small job, but it is one per device per person, and it generates more "it stopped working" messages than anything else on this list.
• Items in the TODO area. VaultMe puts anything it could not place automatically into a clearly marked container in the destination, one per content type that needs it. Somebody has to work through it and file what is worth filing; left alone, it stays a pile.
• Links that pointed at the source. Links embedded in migrated content are preserved exactly as they were rather than rewritten to point at the destination copies, so some of them stop resolving once the source is retired. That is expected behavior rather than a fault, but the important ones have to be found and updated by hand.

For each of these, decide whether end users are told how and left to it or somebody works through it for them. Either answer is fine; an assumption is not. The same list seen from the project's side, with the source retirement and the switch itself alongside it, is in "Planning the cutover and domain switch".

Expect questions in the first days, and expect some of them to be unfair. A migration is the most recent thing that happened, so anything anybody cannot immediately find gets attributed to it, whether or not it was ever in scope. That is normal and it passes quickly, but while it lasts it is real work, so give it a named owner and a window that tapers instead of letting it land on whoever happens to be closest. "Planning the migration timeline" covers how much time to set aside for it.

How long that tail is, and how loud the first week is, are decided almost entirely by how well the earlier part of this article was done. That is the trade this whole subject comes down to: effort spent setting expectations before the run comes back as questions nobody needed to ask afterward.

A checklist for preparing people

The people side of a batch is ready when all of these are true.

1. The announcement has gone out. What is being migrated, roughly when, what stays exactly as it is, and who to ask — in plain language, from a named sender, somewhere people can find it again.
2. The during-the-run rules have been communicated, with an expiry date. Keep working in the source, stay out of the destination until that account finishes, leave already-migrated content and sign-in settings alone — and a stated point at which each of those stops applying.
3. Somebody is named to answer questions before, during, and after. One person that end users can actually reach, not a shared address nobody owns.
4. Everyone whose account is connected individually is lined up. Reachable, given a deadline rather than a request, chased and re-sent when a connection link goes unopened, and able to clear multi-factor authentication — or with their multi-factor handling arranged in advance where you are connecting on their behalf.
5. Availability has been checked against the cutover window. Vacations, public holidays, and time zones, checked before the date was fixed rather than after.
6. Confirm-before-switching is arranged. Per account on a small project, as a confirmation window per batch on a large one. Every shared drive in scope has a named person to check it too.
7. The follow-up after cutover has been assigned. Mail programs to set up again, items VaultMe left in the TODO area, links that pointed at the source, each one either instructions to end users or work somebody does for them.
8. On a phased rollout, the whole cycle is planned to repeat per batch. Announcement, during-run rules, confirmation window, and follow-up, once for every batch, growing more specific each time.

That is the end of the "Planning and preparation" section. The decisions have been made, both sides are ready, and now the people are too — which leaves running it, and then making the switch that finishes it. The switch itself is planned in "Planning the cutover and domain switch".