IT Tips & Tricks
Communicating Migration Risks to Non-Technical Stakeholders
Why the Most Stressful Part of Your Migration Might Be the Meeting Beforehand
Published 30 July 2026
Data migrations have a way of sounding simple until someone asks, “Wait, will all our spreadsheets still work on Monday?” Then the room goes quiet and all eyes are on you.
Let’s be honest. You can design the sleekest migration plan ever committed to an Excel spreadsheet, deploy the right tools, test everything twice and still walk into a room full of thunderous faces and crossed arms. The technical side of a migration is difficult. Explaining it to people who don’t live in IT every day? That’s an entirely different kind of difficult.
Non-technical stakeholders such as executives, department heads, compliance officers and operations managers aren’t trying to make your life difficult. They’re just working from a completely different viewpoint.
The technical side of a migration is difficult. Explaining it to people who don’t live in IT every day? That’s an entirely different kind of difficult.
Their job is to protect the business, manage budgets and keep operations running without drama. Your job is to translate a complex technical undertaking into systems that help them do exactly that. Do it well and you become a trusted advisor. Screw it up and you become the person who caused “that whole thing with the files.”
So, here’s how to get it right when you have to talk to them.
Speak in Outcomes, Not Operations
The first and most important thing to remember is this: Non-technical stakeholders don’t care how the migration works. They care what happens to the business if it goes wrong, and what you’re doing to prevent that.
The other thing they care about is how the new system is going to affect their jobs, even if everything does go right.
When you walk into that room and say, “We’ll be remapping UNC paths and handling broken links across twelve file types,” you might as well be reading them the back of a shampoo bottle in a foreign language. It’s not that you’re wrong. It just that it doesn’t mean anything to them. Zip, nada, nothing but blank expressions.
Instead, try this: “Typically, during a migration, links inside your files — the ones connecting your spreadsheets, documents and reports — break. When that happens, the data seems to vanish. You open a file and the information you expect to see isn’t there. But don’t freak out. We have some software to prevent that from happening.”
Same information. Completely different impact. One sentence in and they’re already nodding along. You’re using language they understand and it’s getting agreement.
The rule of thumb is: Lead with the business consequence, then explain the technical stuff … if you need to. Not the other way around.
By the way, when you said, “But don’t freak out. We have some software to prevent that from happening,” you weren’t blowing smoke. If you have LinkFixer Advanced™, it protects links exactly as you described.
Non-IT stakeholders aren’t trying to make life harder for you. They’re just coming at it from a completely different perspective.
Use the Financial Frame Early and Often
Nothing focuses a room faster than numbers. Money, money, money.
Migration risks can be genuinely expensive. Make that clear without sounding alarmist. The goal isn’t to scare people into approving your budget. It’s to help them understand why the right tools and preparation are worth the investment: It protects them.
Consider what a failed or incomplete migration actually costs. There’s the immediate downtime and loss of productivity, the helpdesk tickets flooding in, the staff hours spent manually trying to solve a problem that may exist on an epic scale.
There’s the possibility of rolling back and redoing the entire project. There’s compliance exposure if financial records or regulated data can’t be accessed. There’s the potential revenue hit if a major quote can’t be delivered because a key spreadsheet is missing.
Help them understand why the right tools and preparation are worth the investment: It protects them.
Start assigning rough dollar values to these types of scenarios, and suddenly the cost of doing the migration properly becomes completely reasonable. Even if your estimates are conservative, the point gets through: A migration isn’t just an IT project. It’s a business event.
Framing it this way also does something else useful: It positions you as someone who thinks about the business, not just the technology. That perception matters enormously when you’re asking non-IT stakeholders to trust your plan.
Know Your Audience
Accept that not everyone in the room has the same concerns, and as a good communicator, be prepared to adjust on the fly.
- The COO wants to know how operations will be affected. How long is the disruption window? What does productivity look like during the cutover? What’s the plan if something unexpected happens before everyone gets to work on Monday?
- The CFO wants to know what it’ll cost, what it’ll save and what the financial damage looks like if things go sideways. Offer a risk-adjusted view: best case, worst case and what your mitigation plan does to close that gap.
- The compliance or legal lead wants to know about data integrity and access continuity. Will they be able to prove that nothing was lost or altered? Will there be an audit trail? Will records be accessible during the transition?
- The department managers mainly want to know if it’ll affect their teams and whether their people will be able to do their jobs when they arrive on Monday morning.
None of these questions are unreasonable. Ultimately, they’re all versions of the same concern, just couched in different terms. But if you’ve anticipated them and have clear answers ready, you demonstrate your competence before anyone can question it.
Make Risk Visible Without Making It Terrifying
There’s a bit of a communication tightrope every IT manager has to walk: You need to be transparent about what can go wrong without sending the room into a blind panic or, worse, causing them to delay a migration they actually need.
A good way to handle this is the traffic light framework. Present each major risk category in terms of likelihood and impact, rate it red, amber or green, and then immediately follow each risk with its mitigation. You’re not hiding the risks. You’re pairing them with their solution in the same breath.
For example: “Guys, the truth is that broken file links are a high risk during any migration of this size. About 40% of migrations have some form of missing data due to broken links. In Excel files specifically, that number is closer to 50%. If you don’t prepare for it, it causes data that appears to completely disappear. But we’re using software that pre-protects all our file links before we move anything, so that regardless of where files end up, the connections between them stay intact and your data is immediately available.”
Present each major risk category in terms of likelihood and impact and then immediately follow each risk with its mitigation.
You’ve named the risk clearly, cited a real figure and explained exactly what you’re doing about it. That’s not scary. That’s reassuring.
Analogies Are Your Best Friend
You can close the gap between technical reality and non-technical understanding with a good analogy. Don’t be afraid to use them. The right one can make a complex concept click in seconds.
You can, for example, try something like this: “Imagine an airport opens a brand-new terminal. The computers and scales at the check-in desks have been tested. The gates are staffed and the first flights arrive.
“Passengers and their luggage successfully make it into the terminal, but the baggage routing system hasn’t been updated. Bags for Gate 12 are incorrectly being dumped out again at the loading dock. Bags for Toronto get routed to Tulsa. It’s chaos. The luggage hasn’t been destroyed, but nobody can find what they need when they need it either.
Use analogies. You can literally observe the recipient’s light-bulb moment when you communicate a concept clearly and the penny drops.
“That is a lot like a migration where the files move, but the links inside those files still point to old locations. The fix is not to send employees or IT staff hunting through folders after the fact. The fix is to treat file links like part of the routing system: Identify them before the move, protect them during the migration, update them when locations change and test them before users are standing at the Lost Luggage counter (which we call the helpdesk), demanding to know where their work went.”
You don’t have to come up with complex analogies. Just relatable ones, expressed in human terms. You can literally observe the recipient’s light-bulb moment when you communicate a concept clearly and the penny drops.
Don’t Bury the Good News
IT professionals sometimes communicate so carefully about risks that they forget to mention the positives. Here’s the thing: If you’ve planned well, will be using the right tools and have a solid rollback strategy, this is genuinely good news. Say so.
When it works, it works. Everyone knows it and it’s a thing of beauty.
Tell stakeholders what success looks like in concrete terms. “On Monday morning, users will be able to open their files from the new platform and everything will work exactly as it did before. No missing data. No disruption. No helpdesk avalanche.” That’s the outcome they’re paying for. Make sure they know you’re aiming for it too and that you have a credible path to get there. One more thing on this point: Also tell them what you’re doing to help ensure this outcome and that you have a contingency plan (communicated without technical jargon).
Confidence isn’t arrogance. Think of it as earned trust expressed out loud. When you’ve done the preparation, let them know. Stakeholders want to believe it’s going to be fine. Help them get there with specifics, not just blind optimism.
Create a Simple One-Pager
One of the most practical things you can do is condense your migration risk tale into a single page. Not a 47-slide deck. Not a detailed technical rundown. One page.
It should cover:
- what’s happening.
- why it’s happening.
- what the key risks are.
- what you’re doing to mitigate each one.
- what the timeline looks like.
- who to contact with questions.
That’s it. Put it in plain English. Make it skimmable. Leave a blank column for them to add notes.
This serves two purposes. First, it gives stakeholders something tangible they can reference and share. Second, it forces you to prioritize. If you can’t fit the key points on one page, you might not yet have identified what the key points actually are.
The Follow-Up Is Part of the Conversation
Communicating migration risks isn’t a one-time event. It’s a process that runs through the entire project lifecycle:
- Before the migration, you’re setting expectations and building confidence.
- During the migration, you’re providing status updates and managing surprises calmly.
- After the migration, you’re confirming outcomes and following up on any residual issues promptly.
Nothing destroys stakeholder confidence faster than silence during a migration. Even a brief, “Everything is going as planned, next update at noon,” keeps the anxiety at bay. People don’t need constant reassurance. They just need to know someone is in control and that they won’t be blindsided.
After a successful migration, take a moment to communicate that success clearly and specifically. “We moved 2.4 million files, zero data loss, zero broken links, and the helpdesk has received no tickets related to the migration.” That closing statement does more for your professional reputation than almost anything else. It completes the story you started in that boardroom.
That does more for your professional reputation than almost anything else.
The Bottom Line
Explaining migration risks to non-technical stakeholders is a skill, and like most skills, it gets better with practice. The fundamentals are straightforward: Use their language, not yours. Connect any technical risks to business consequences and then pair every risk with a mitigation or solution and stay honest without being alarming.
The IT professionals who navigate this well aren’t just better communicators. They’re better protected.
When stakeholders understand the risks and trust your plan, they’re less likely to second-guess decisions mid-migration, more likely to approve necessary tools and more willing to give you the breathing room that complex projects often require.
Speak clearly, think in outcomes and never underestimate the power of a well-placed analogy. Your stakeholders will thank you for it. Probably not in those exact words, but still. Sometimes, a smile or a handshake speaks more loudly than words.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment