What to tell staff during a hosted migration cutover

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Staff communications during a planned migration are not the same problem as cyber incident out-of-band messaging when email and identity are down. In a hosted cutover, email and SSO often keep working; the failure mode is confusion: two URLs, old shortcuts, “try again in an hour” without a clock, and help-desk tickets that duplicate answers.

A cutover comms plan states what changes, when, how users recognise the new path, what they must stop doing, and where status updates appear until hypercare ends.

NIST SP 800-34 includes notifying users and stakeholders as part of contingency plan activation and deactivation (NIST SP 800-34 Rev. 1). Migration is a controlled relocation, but the notification discipline is the same: tell people which system is authoritative, when behaviour changes, and when normal service is declared.

Why it matters

Users are integration points. They cache browser sessions, keep desktop shortcuts, run macros that point at old hostnames, and forward spreadsheet links. Without clear messages, they become undeclared testers of rollback paths.

Help-desk load spikes are predictable. What is unpredictable is how angry the spike gets when messages contradict each other; IT says “use the new portal”, the app owner says “old system still fine until Monday”.

How it works

Message set (minimum)

Prepare four message types before cutover:

1. Advance notice (for example, 7–14 days, adjusted to staff and contractual needs): date window, purpose, expected user-visible impact (outage vs read-only), freeze rules on data entry.
2. Freeze start: hard stop on defined actions; whom to call for exceptions.
3. Cutover in progress: status page or Teams channel; “check the status notice for the known outage; report unexpected, urgent, data-integrity or security issues through the named escalation route”; ETA updates only when reliable.
4. Go-live confirmed: new access instructions (URL, RemoteApp name, VPN change if any); what to do if login fails; hypercare contact.

Each message should answer: Which system is authoritative right now?

Channels

Choose one canonical status source and at least one accessible alternative. Check shared identity, network and provider dependencies: email and Teams may fail together. Give affected staff the alternate contact before the outage, and test that they can use it.

Do not rely on the application itself as the only notice if the application is the thing changing.

The official Communicating under pressure guidance supports clear and timely stakeholder updates. It is CISA-led with contributions from ASD’s ACSC and other partners, and explicitly describes US best practice rather than Australian legal obligations. Applying its communication principles to a planned migration is an editorial analogy.

Content staff actually need

• Start here link; one canonical URL or Remote Desktop collection name after cutover.
• What not to do; “Do not save files to the old drive letter”; “Do not approve payments in the old system after 18:00 Friday.”
• How to recognise success; e.g. “Monday login shows site name X in the title bar.”
• Screenshot policy; if new UI differs, optional one-page visual; no invented marketing.
• Escalation; hypercare number or queue, not generic “contact IT”.

Roles

• Comms owner; drafts, approves wording with sponsor.
• Cutover commander; approves timing of “in progress” and “go-live” sends.
• Help-desk lead; converts messages into KB articles and auto-replies.

What not to say

• Promises of zero downtime unless the plan truly delivers it and defines “downtime”.
• Technical jargon (replication lag, TTL) without user consequence translation.
• Blame language toward hosting provider or vendor in user-facing text.

What to choose and why

Choose one canonical status source updated by named people, not ad-hoc chats.

Choose pre-written templates with blanks for date/time only; cutover night is a poor time for fresh prose.

Agree a post-go-live update schedule through stabilisation and representative business cycles. A 72-hour schedule can be a worked example, but support communications must continue longer if unresolved issues or later batch runs require it.

Risks and limits

Announcing go-live before acceptance gates pass; comms must follow go/no-go, not lead it.

Different messages per site without labelling; use “Perth staff / Sydney staff” sections when paths differ.

Using incident out-of-band playbooks; personal phone trees for ransomware are heavy for planned migration unless email truly fails.

Keep planned-outage notices proportionate while preserving urgent incident reporting and clear system ownership.

Service link: how it works.

Sources

Developed with AI assistance. Source research only; no migration, recovery or infrastructure procedure was executed or lab validated.

Source research accessed 14 November 2026. These documents support the stated principles and tool-specific conditions; the planning templates are editorial recommendations.

• NIST SP 800-34 Rev. 1, May 2010, section 4.4.
• CISA and partners, hosted by ASD: Communicating under pressure.

Related future topics

• Business freeze windows.
• Hypercare first 72 hours.

Learning notes

• Planned migration comms differ from cyber out-of-band playbooks.
• Every message should state which system is authoritative.
• Use one status source and an accessible alternative with shared failure dependencies checked.
• Tell users what to stop doing, not only what is “improving”.
• Go-live announcements follow go/no-go, they do not precede it.

This article was originally published on 14 November 2026.