Story

A team was preparing to migrate content from an on-premise system to a cloud-based platform. The expectation was straightforward: the transition would be managed, disruption would be minimal, and the organization would be informed ahead of time. From a planning perspective, nothing about the migration seemed unusual. It was treated as a standard technical change with a defined timeline and a responsible lead.

On the day the first subsite was migrated, the team lead explained that the process would take about a week. During that time, files would be unavailable. They also mentioned that an email would be sent to notify users. From their perspective, the plan was clear. The work had started, the timeline was communicated internally, and the next step—sending the communication—was assumed to follow.

Then the calls started.

Users began reporting that files were suddenly inaccessible. There had been no prior warning. No context. No explanation of what was happening or why access had changed. From the users’ perspective, something had broken. From leadership’s perspective, it was unclear what had been done and why the organization had not been informed.

What was expected to be a controlled transition became an immediate disruption.

Breakdown

What actually broke

This was not a failure of effort or intent. The outcome was clear, and the team was actively working toward it. The breakdown occurred in how expectations were communicated.

Expression makes expectations explicit.

The impact of the migration—loss of access, timing, and user communication—was not made explicit before execution. Instead, it was implied. The team lead understood what would happen, but the organization did not. That gap created a coordination failure the moment execution began.

What we did

The response focused on restoring access and stabilizing the situation. File availability was re-established, communication was sent to users, and navigation was created to help people find content in the new environment. Permissions were manually adjusted, and the team was guided on how to implement these changes going forward.

These actions reduced immediate disruption, but they did not address the original breakdown point. The issue was not the migration itself—it was that the impact had not been clearly defined and communicated before it happened.

What should be done

The correction belongs at the point where expectations are set, not after execution begins.

Before any change that affects access, the impact must be explicitly defined:

“Here’s exactly what this includes…”

  • What will change

  • When it will change

  • What users will experience

  • What they need to do (if anything)

Without that level of clarity, people fill in the gaps themselves. And when they do, coordination breaks.

Expansion

Where this shows up

This pattern is not limited to system migrations. It appears anywhere execution begins before expectations are fully specified.

It shows up in cross-team projects where one group assumes others understand the plan. It appears in leadership communication where direction is given without defining impact. It happens in operational changes where the people affected are not included in the communication loop.

In each case, the work itself may be correct. The breakdown comes from how that work is translated into shared understanding.

Why it keeps happening

The underlying issue is assumption.

Assumed meaning breaks alignment.

When people believe something is “obvious,” they stop making it explicit. They assume others see the same impact, understand the same risks, and anticipate the same outcomes. But interpretation is not shared automatically. It must be constructed.

The system makes this clear:

  • You can’t confirm what isn’t clear

  • You can’t execute what isn’t agreed

If expectations are not explicitly defined, every downstream step is built on unstable ground.

Proof

What happened next

After access was restored and communication was sent, users were able to resume their work. Navigation improvements made the new environment usable, and the team adjusted how they approached subsequent migrations. The situation stabilized, but only after disruption had already occurred.

What we’re seeing

This is a repeated pattern across cases: work that is technically correct creates problems because its impact was not explicitly communicated before execution. The issue is rarely the task itself. It is the assumption that others already understand what that task means for them.

This was not a failure of the migration.

It was a failure to make the impact visible before it happened.

Clarity must be constructed, not assumed.

Keep Reading