Your technology changes even when your IT team hasn't started a project. Vendors update their products on their own schedule. A familiar screen gets redesigned, a new feature switches itself on, or a version you depend on stops being supported.
Most of these changes are announced ahead of time. What's often missing is someone whose job is to read those announcements and work out what they mean for you. Without that person, your employees find out first, usually in the middle of their work.
Forwarding the email isn't enough
Microsoft posts upcoming changes to the Message center in the Microsoft 365 admin center. Google, Zoom and others publish release notes and admin notices of their own. These tell you what's changing, but they don't always explain what it will mean for you.
That part is a decision someone inside your company has to make. A new sharing option might need a settings review, updated instructions and a heads-up to your help desk. A change to an integration might need testing with whoever owns that business application. Forwarding the vendor's email to everyone leaves all of that undecided.
When a notice leaves you guessing, look for a few sources you trust. Consultants and advisors often write about big changes before they arrive, and a good one can explain the impact in plain terms.
Three kinds of change deserve a closer look.
Your vendor redesigns a tool your employees know
I lived through this with the new Outlook. Many people hated the first version, and plenty of the third-party add-ins they relied on didn't work in it. We ended up removing it and forcing everyone back to classic Outlook. That fixed the problem, but it wasn't a good look for the IT department.
Pulling a change back after people have it is harder than holding it until you're ready. Before a visible change reaches everyone, try it with a few real users and check the add-ins and integrations they depend on. When the vendor lets you control the timing, use that control.
Your vendor turns on a feature you didn't ask for
In early 2025, Google bundled Gemini into its Workspace business plans and turned the AI features on by default. Many enterprise customers were surprised to find an AI assistant already sitting in their email and documents. Some admins had to contact Google support just to get the option to turn it off.
When a feature turns itself on, the vendor has made a decision for you. For a company that hasn't settled how AI should be used with its data, that's a big call to hand over.
Changed defaults are the roadmap items to watch most closely. Find out early whether you can delay a change, limit it to a pilot group or turn it off. Some changes can't be held back at all, so check before you count on it.
Your vendor ends support for a version you use
Some notices come with a deadline. After a certain date, a version is no longer supported, and you have to upgrade before then.
These are the easiest changes to plan for, because the vendor gives you the date. They're also easy to miss when the date feels far away and nobody puts it on a calendar.
Treat an end-of-support notice like a project with a due date. Give it an owner and work backward, leaving time to find what depends on that version and to test the upgrade. If the system is validated, the upgrade needs documentation too, so start earlier.
Match the response to the change
Employees don't need to hear about every release note. They need to hear about the changes that affect their work, early enough to be ready.
| Change | How to prepare |
|---|---|
| A small visual change | Brief your help desk and update any screenshots in your how-to guides. |
| A new optional feature | Decide whether you want it, then tell the people who would use it. |
| A changed default or workflow | Test it, decide how to set it up, and give people notice before it lands. |
| A retired feature or version | Name an owner and plan the move, with training if people's work changes. |
For the biggest changes, an email won't do it. People need to understand why the change is happening and how their work will be different, and their managers should hear about it first.
Who should be watching
One person can't review every vendor's roadmap or understand the impact of all of them. Each platform needs its own reviewer who knows it well, whether that's Microsoft 365, Zoom, Webex, SAP or Workday. In a smaller company, that may be the admin for each system or your MSP.
Those reviewers need a partner who looks at every change from the employee's side. Back-end engineers tend to look at a change, decide it's fine and assume users don't need to be told.
In some companies, digital experience staff already fill this role. They often come from communications with a "minor" in technology, so they understand the tech while looking out for the people who use it. In a smaller company, an IT or digital workplace ambassador can do the same job: someone lightly technical who cares about the employee experience.
In a company that size, I'd have the ambassador own one shared list. In a larger company, the list belongs with your adoption, change and experience (ACE) team. You may not have a team by that name, and you don't need one. The job can be a role within an existing group.
Every change a reviewer flags goes on the list, with who it affects, when it lands, what you decided and who's following up. "No action needed" counts as a decision, so write it down. Having one owner, whether it's a person or a team, also means employees hear about changes in one consistent voice instead of a pile of forwarded vendor emails.
Review the list on a rhythm that fits your vendors. Microsoft changes something almost every week, so a quick weekly look makes sense. Applications like SAP and Workday usually ship major releases on a published schedule, so plan around those dates.
Check the rollout before you close it out
Roadmap dates move. Microsoft's own roadmap says all of its information is subject to change. A change can also reach different people or devices at different times, so check what's actually showing up in your environment before you send detailed instructions.
After the change lands, make sure it works the way you expected and your how-to guides match what people see. Keep an eye on help desk questions for the first week or two. Then close it out on the list.
Make it part of running IT
Vendors aren't going to slow down, especially with AI features arriving as fast as they are. I call this work vendor change readiness: watching for what's coming and getting your people ready for it. It belongs in the day-to-day of running IT.
If it only happens after something goes wrong, your employees have already paid for it. A fractional advisor can help you set up the process, and your team can run it from there.
Your employees shouldn't be the first people to discover a vendor change that IT could have prepared them for.