You can't email your way through a migration

You can't email your way through a migration. I learned that the slow way.

I have moved a lot of people off a lot of systems. Old CMSs, old frameworks, home-grown tools that had quietly become critical. The technology changes every time. The way people respond to being asked to move does not.

The trap

You assume people will move once they know. So you do the sensible thing. You write a clear announcement. You explain why the old system is going away and why the new one is better. You link the guide, the FAQ and a channel for questions. Then you wait.

Silence. Not pushback. Not questions. Nothing.

So you send a follow-up, a bit firmer this time. You get the same result. Even the teams who agreed to go first, the friendly ones, the early adopters, go quiet.

Why the silence happens

It is tempting to read that as laziness, or resistance. It is almost never either.

Every team already has a full roadmap. Features they promised. Bugs their users are shouting about. Deadlines with someone else's name attached. Your migration is not on that list. Nobody put it there, so nobody owns it.

And from where they sit, the old system works. It might be slow, or ugly, or unsupported, but it does the job today. Moving off it is effort now for a benefit later. It also comes with a risk they can't size: what breaks, how long it takes, who gets the blame if it goes wrong.

Put those together and the rational choice is to do nothing until forced. Until the migration shows up in their day, it doesn't exist.

Once I saw it that way, the job changed. I wasn't informing people any more. I was trying to get a piece of work onto other people's plans.

What actually worked

Here is what moved the needle, in the order I learned it. In hindsight I would do most of it from day one.

A real deadline

'Please move when you can' means never. There is always something more urgent than a move with no date.

A date turns 'someday' into a decision. Teams can plan around it, argue about it, or ask for help, and all three are better than silence. The date has to be real, though. If it slips once with no consequence, nobody believes the next one.

On its own, a deadline doesn't move everyone. What it does is start the conversation. The first replies tend to arrive only after there is a date to reply to.

Going through team leads

Priorities flow downhill. An email from someone outside the team is noise. The same ask from your own lead is work.

So I started CC'ing the team leads and managers. That is when the escalations started happening, and the work started moving.

This also surfaces the real blockers early. A lead will tell you, honestly, that their team can't move until a missing feature lands. That is far more useful than six months of polite silence.

Regular online workshops

A lot of the silence was nerves. People didn't know how long the move would take, what would break, or where to start.

Documentation alone doesn't fix that. So I ran regular online workshops: open calls that anyone could join to ask questions. A place to bring whatever was stopping them and get an answer.

They fed themselves, too. The questions got better each time. The guide improved because I could hear exactly where people got stuck. Each workshop made the next one easier to fill.

An in-product notice

Nobody lives in their inbox. They live in the tool.

A notice on the old system itself, one people have to acknowledge, puts the message where they already are, every time they use it. It can't be filtered into a folder or skimmed past on a busy morning. It also reaches the people no email list knows about: the occasional users, the teams that inherited something, the person who set it up years ago and has since changed roles.

Keep it short, factual and useful. What is changing, by when, and one link to get help. If it nags or threatens, people learn to click through it without reading.

It doesn't do the work on its own. What it does is back up everything else. By the time a lead raises the migration with their team, everyone has already seen the notice.

Putting it together

None of these is clever. Each one alone helped a little. Together, they turned silence into steady movement, and the movement started to compound as more teams went across and talked about it.

The pattern underneath is simple. Make it real with a date. Make it someone's job through their lead. Make it feel safe with open workshops. And keep it visible where people actually work.

If I could go back to my first migration, I'd flip the order. Put a date in the very first message. CC the leads from day one. Have the workshops booked before anyone asks. The announcement still goes out, but it is the least important part.

A migration is a change-management problem dressed up as a technical one. The code is usually the easy part.