The Migration That Never Happened

Years ago, I watched an entire office report that everything was broken, their files were gone, and nothing worked.

Nothing was broken. No files were gone. Everything worked. We hadn’t changed a single thing.

The Plan

We had a server migration to do. The kind that’s an entire night of work: after hours, everyone off the network, swap the old box for the new one, verify everything, go home as the sun comes up.

So we did what you’re supposed to do. We told everyone.

“Migration happening overnight. Make sure you log out before you leave. Everything will be back to normal in the morning.”

Clear communication. Advance notice. Instructions given. Textbook change management.

What could go wrong?

The Problem

Partway through the night, we hit a critical issue. Not a “push through it” issue, a “this could genuinely cause users problems” issue.

So we made the call every experienced admin knows is right but hates making: we rolled back.

Except “rolled back” is generous, because nothing had actually been applied yet. The migration was a straight swap of one server for another, and we hadn’t completed anything that touched production. The original server was still there, still running, still exactly as everyone had left it.

We packed up, left everything as it was, and went home to bed around 4am.

Total changes made to the environment: zero.

The Sky Is Falling

6am. The first staff arrive.

“NOTHING IS WORKING.”

“ALL MY FILES ARE GONE.”

The calls come in hot. Neither of us can understand it. We didn’t change anything. There is no technical reason for a single issue to exist. But the instruction is simple: get in right away and fix it.

So we drag ourselves back into the office on about two hours of sleep, bracing for… something. Anything. A clue.

The Crime Scene

We walk in and find people working away. On their computers. On the network.

Hmm.

We go to the first person who reported missing files.

“Show me. Click the server icon you always click.”

They click it. All their files are there. Every single one.

“What exactly is missing?”

“It’s all different. I couldn’t find anything.”

“What is different? Which files are missing?”

”…”

Nothing was missing. Nothing was different. The server icon was where it always was, pointing at the same files it always had.

Next user. Same story. “It’s all different” turned out to mean “it feels different.” Login worked. Files were there. Everything functioned exactly as it had the day before.

User after user after user, the same pattern. No missing files. No failed logins. No actual faults. Just a deep, unshakeable certainty that something must be wrong.

What Actually Happened

Here’s what we eventually pieced together.

We’d told staff a big change was coming overnight. So they came in the next morning primed for chaos. The expectation had been set: everything is going to be different, everything is going to be broken.

So when they sat down and something felt even slightly unfamiliar, maybe a screen loaded a beat slower, maybe they just couldn’t remember where they’d saved something on Friday, the conclusion was instant: the migration broke it.

One person says “my files are gone.” The person next to them hears it and starts looking for what’s wrong with their machine. Before long the whole office is reporting failures that don’t exist, each one confirming the others’ suspicions.

Nobody checked whether their files were actually there before reporting them missing. Why would they? They’d been told things were changing. Of course it was broken.

The announcement didn’t prevent panic. It scheduled it.

The Second Attempt

The next week, we attempted the migration again.

This time, we didn’t tell anyone.

No emails. No announcements. No “please log out” instructions beyond what we’d normally send. Just a quiet, after-hours swap, the same work we’d tried to do the week before, this time with the issue resolved and no audience waiting for disaster.

It went flawlessly.

Staff came into the office the next morning, sat down, logged in, and started working.

Not a single issue was raised. Not one. The new server was live, the old one was retired, and nobody noticed a thing because nobody was looking for anything to be wrong.

Same migration. Same staff. Same risk profile.

The only variable was whether people knew it was happening.

The Uncomfortable Lesson

Everything I’d been taught about change management said to communicate early and often. Tell users what’s coming. Set expectations. Be transparent.

And here was clear evidence that telling people had caused a morning of phantom outages, and not telling people had resulted in silence.

I’m not proud of the conclusion, but I’d be lying if I said I didn’t learn it:

The announcement of maintenance is often the cause of more reported issues than the maintenance itself.

Why This Happens

Once I started looking for it, I saw this pattern everywhere.

1. Expectation Creates Evidence

If you tell someone something will be different, they will find the difference, even if it isn’t there. The brain is a pattern-matching machine, and “something is broken” is a pattern it will happily match against completely normal behaviour.

A slightly slow login on a normal day is ignored. A slightly slow login after a migration is proof the migration failed.

2. Broken Is the Default Assumption

Users have been burned by enough bad updates, botched rollouts, and “improvements” that made their lives worse that the default assumption is: change means broken.

They don’t come in neutral. They come in pre-disappointed.

3. Panic Is Social

One person reports a problem. Now everyone is auditing their own machine for problems. It’s a fire drill where half the reported smoke is just other people yelling about smoke.

4. Feelings Report as Facts

“It’s all different” is a feeling. “My files are gone” is a fact. Users report the feeling using the language of fact, and if you take every report at face value you’ll chase ghosts all morning.

The most important diagnostic question in IT support isn’t “what happened.” It’s “show me.”

In Defense of the Users

Here’s the thing: the users weren’t stupid, and they weren’t lying.

They’d been told a major change was happening overnight. From their perspective, walking in and finding things “weird” was a completely rational interpretation. Major changes cause problems. Everyone knows this. They’ve lived it.

And when they couldn’t immediately find something, the available explanations were:

1. The thing that was announced as changing everything had changed something
2. They personally misremembered where something was

Which one would you pick under pressure, with a queue of work waiting?

The failure wasn’t their perception. The failure was that we’d handed them a narrative, “big change tonight”, and then left them to interpret every ambiguous moment through it. Given that narrative, their reports were perfectly sensible.

They were wrong, but they weren’t being unreasonable.

What I Do Differently Now

I’m not advocating for running secret maintenance on everything. Transparency matters, and some changes genuinely affect people and need communication.

But this incident changed how I think about it:

1. Communicate Impact, Not Activity

Users don’t need to know a migration is happening. They need to know what will be different for them. If the honest answer is “nothing will be different,” the announcement is pure downside.

2. “Show Me” Before “Fix It”

When someone reports total catastrophe after a change, the first step is to sit down and have them demonstrate it. Nine times out of ten, the catastrophe evaporates under demonstration, just like it did when they clicked the server icon and everything was there.

3. Verify Before Escalating

Before you mobilise a response to “everything is down,” confirm that anything is down. Our entire panicked morning would have been one phone call: “Can you click your server icon? Are your files there? …Yes? Okay, call me back if something’s actually missing.”

4. Expect the Phantom Window

For about a day after any announced change, all reports are suspect. Slow mornings, forgotten passwords, and “it’s different” complaints will all spike. Budget for it. Don’t mistake it for a failed rollout.

The Question That Stuck With Me

After that morning, after hours of checking user after user and finding nothing, we slumped into our chairs, half asleep, contemplating the next attempt.

And the question that formed, the one I’ve carried through twenty years of IT work, was:

“How many of the problems I fix were never actually broken?”

More than you’d think. Enough that “show me” became my first response to almost everything.

Conclusion

The migration that never happened caused more reported issues than any successful change I’ve ever shipped. The migration nobody knew about caused none.

The lesson isn’t that users are the problem. It’s that expectation is a force multiplier, and it multiplies in whichever direction you point it.

So these days, when I plan maintenance, I ask one question before I write the announcement email:

“What will actually be different for them?”

If the answer is nothing, I close the draft, do the work quietly, and let everyone have a normal morning.