How to Communicate Infrastructure Changes in English

Infrastructure changes carry risk. A poorly communicated database migration or network change can leave users confused, on-call engineers scrambling, and support teams overwhelmed with tickets. Clear, professional communication before, during, and after an infrastructure change is as important as the technical execution. This post gives you the English phrases and structure you need to communicate infrastructure changes effectively.

Key Phrases

Planning a change:

• “We’re planning a maintenance window on Thursday, 2 March, from 02:00 to 04:00 UTC.”
• “This change is going through the CAB (Change Advisory Board) process for approval.”
• “The scope of the change is a database index rebuild on the users table.”
• “We estimate a 30-minute service degradation window.”

Describing the blast radius:

• “The blast radius is limited to the checkout service — all other services will be unaffected.”
• “In the worst case, the blast radius includes all read operations on the primary database.”
• “The impact is scoped to the EU region only.”

Communicating the rollback plan:

• “We have a tested rollback plan. If the migration fails, we can revert within 10 minutes.”
• “The rollback procedure is documented in the runbook linked below.”
• “We have a database snapshot taken 30 minutes before the change window begins.”

Setting user expectations:

• “Please expect elevated latency during the maintenance window.”
• “Some users may experience intermittent errors between 02:00 and 02:30 UTC.”
• “The service will be briefly unavailable for approximately five minutes.”

During and after the change:

• “We’ll post updates every 15 minutes in #incidents.”
• “The change is complete and all systems are healthy.”
• “We are seeing unexpected behaviour and are considering rolling back.”
• “All metrics are nominal. We’re closing the change window.”

How to Use This in Practice

Infrastructure change communication typically involves three phases: pre-change, during the change, and post-change.

Pre-change communication should include: what is changing, when, for how long, who is affected, what the blast radius is, and what the rollback plan is. If your organisation has a CAB (Change Advisory Board), you will need to submit a change request with these details in advance. The CAB reviews risky changes to ensure they are well-planned before approval.

Zero-downtime deployments have their own vocabulary. You might say: “We’re using a blue-green deployment to avoid downtime” or “We’re doing a canary release — we’ll route 5% of traffic to the new version and monitor error rates before rolling out fully.”

During the change, post structured updates in your incident or ops channel: “14:05 UTC — Change in progress, migration running. No errors observed. 14:23 UTC — Migration complete, running validation checks.” This gives on-call engineers and stakeholders a clear picture without requiring them to ask for updates.

Post-change, always send an all-clear: “The change is complete. All services are healthy. Latency is back to baseline. No rollback required.” If something went wrong, say so directly: “We encountered an issue and executed the rollback. Service is fully restored. A post-mortem will follow.”

Example Conversation

Platform Engineer (Bohdan): “I wanted to flag the upcoming database maintenance. We’re planning a maintenance window on Sunday, 6 July, from 01:00 to 03:00 UTC. We’ll be rebuilding indexes on the orders table to address the query performance degradation we’ve seen.”

On-Call Lead: “What’s the blast radius if something goes wrong?”

Bohdan: “The blast radius is limited to order read operations. Writes will continue to work. We have a tested rollback plan — we can restore from a pre-migration snapshot in under 10 minutes. We’ll be posting updates in #platform-ops every 30 minutes during the window.”

On-Call Lead: “Has this gone through the CAB?”

Bohdan: “Yes, it was approved in yesterday’s CAB meeting. The change request link is in the thread.”

Practice Tips

1. Write a mock change notification: Choose a real or fictional infrastructure change (restarting a service, migrating a database, updating a TLS certificate) and write a pre-change announcement using the phrases from this post. Include: what is changing, when, the blast radius, and the rollback plan.

2. Read a real post-mortem: Many companies publish post-mortems publicly (GitLab, Cloudflare, and Stripe are notable examples). Read one and identify how they communicate the blast radius, the rollback actions, and the timeline. Notice the language they use to be transparent without being alarmist.

3. Practise update cadence: During a change window (even a small personal project deployment), practise writing timed status updates as if you were posting them in a team Slack channel: “14:00 — Change started. 14:12 — Step 1 complete, proceeding to step 2. 14:25 — Change complete, all checks passed.” This builds the habit of structured, time-stamped communication.