What switching and adopting tools really costs

Tuesday's news from the people who make productivity software is less about new features than about the cost of change. Three threads run through the day: how vendors want to charge you, how cleanly your data crosses from one platform to another, and how much proof you should demand before trusting an AI feature in daily work.

None of these is a headline about a shiny capability. They are all about the friction a business feels when it commits to a tool, changes tools, or lets software make a decision on its behalf. That is the part of a buying decision that rarely shows up in a demo, and it is the part that costs the most when it goes wrong.

How you are charged is shifting away from seats

For most of the last decade, business software has been priced per seat. You count your users, you multiply by a monthly figure, and that is your bill. The model is easy to understand and easy to forecast, which is exactly why it became the default. It also has a quiet flaw: it ties what you pay to how many people have a login, not to how much value the tool actually delivers. A team of ten that barely touches a product pays more than a team of three that depends on it every hour.

That tension is now being argued out in the open. Henry Schuck, the chief executive of ZoomInfo, published his read on where B2B pricing is heading, and the honest conclusion was that there is no settled answer yet. "His summary, after talking to the world's most expensive consultants and hundreds of his own customers: nobody knows." [1] The piece frames three emerging models competing to replace flat per-seat pricing. For a business choosing tools, the practical lesson is not which model wins. It is that the shape of your bill is becoming a variable again, and a price that looks cheap per seat today may be restructured around usage or outcomes tomorrow.

When you evaluate a contract, read the pricing page as carefully as the feature list, and ask what happens to your bill as your usage grows rather than only as your headcount does. We have written before about how pricing pages fail to make this clear, and about what a subscription plan is really selling beneath the monthly number. Both matter more now that the underlying model is in flux. A tool whose price moves with the value you get can be fairer than a flat seat fee, or it can be a way to charge more as you come to depend on it. The difference is in the detail, and the detail is what you should negotiate.

Moving files to a new platform without losing who could see them

Switching platforms is where the cost of change becomes concrete. Most teams underestimate it because they picture the files moving and stop there. The hard part is not the files. It is the permissions attached to them: who could open each document, who could edit it, who was explicitly kept out. Lose that structure in a migration and you have either locked people out of work they need or, worse, exposed documents that were meant to stay private.

Google made this the centre of its announcement of general availability for importing data from Microsoft OneDrive into Google Workspace. The reasoning it gave is the one every operations lead already knows: "For enterprise organizations, migrating files along with their permissions to a new platform can feel daunting and risk interrupting daily business operations." [2] The phrase that matters is *along with their permissions*. A migration that carries access rules across, rather than asking an administrator to rebuild them by hand, removes the single most error-prone step in moving platforms.

The general principle holds whoever your vendor is. Before you commit to any move, find out exactly what crosses with your data and what does not. Permissions, version history, shared-folder structure and external-sharing links are the pieces that quietly go missing. This is the same discipline we described in the data you should be able to export on any Tuesday: if you cannot get your data out cleanly, with its structure intact, you are more locked in than the contract suggests. It is also why your tools not talking to each other becomes so expensive at exactly the moment you try to leave.

Bringing conversation history across, not just files

Documents are only half of a working platform. The other half is the running conversation: the channels, the threads, the context that explains why a decision was made. Google announced data import for Microsoft Teams alongside the OneDrive one, and it used almost identical language: "For enterprise organizations, migrating communication history and collaboration channels to a new platform can feel daunting and risk interrupting daily business operations." [3]

This is worth separating from the file migration because the two fail differently. A lost file can often be re-uploaded. A lost thread of discussion is gone, and with it the institutional memory of how a project reached its current state. If you are weighing a change of collaboration platform, treat conversation history as a first-class item in the migration plan, not an afterthought. Ask whether channels arrive with their membership and their timeline intact, because a channel stripped of its history is a new empty room, not the one your team worked in.

Proving an AI feature works before you rely on it

The day's clearest reminder about AI came not from a product launch but from an engineering account of how to test one. GitHub published its lessons from evaluating large language models before putting them into production, framed around a specific job: "These are the lessons we learned evaluating LLMs for real-world secret scanning." [4] The detail that it was real-world secret scanning, and not a generic benchmark, is the point. The model was measured against a concrete task with a clear definition of right and wrong.

That is the standard a business should carry into its own AI decisions. An AI feature that writes a summary, drafts a reply or flags a record is making a judgement, and a judgement can be wrong in ways that are expensive and quiet. Before you let one run unattended, decide how you would know it is working: what it is allowed to do, what a mistake would look like, and how you would catch one. We set out where that line should sit in what AI should and should not do in your business and in decisions automation should never make. The common thread is evaluation before trust. A vendor that can show you how its AI was tested is giving you something more useful than a confident claim that it works.

Deciding who can see who is in the room

The quietest item of the day is a control, not a capability. Google Chat now lets space owners and managers restrict who can view the full member list of a space. In Google's own words: "Space owners and managers can now control who can view the full list of members in a Google Chat space, providing enhanced privacy and administrative control for sensitive, large-scale, or external collaboration spaces." [5]

The reason this belongs in a briefing about choosing tools is that the membership of a room is itself information. In a space that includes external partners, clients or candidates, the list of who else is present can reveal a deal, a hire or a relationship you had no intention of disclosing. A tool that treats the member list as something to be governed, rather than something everyone can read by default, is giving administrators a lever they will need the first time a space grows beyond the people who started it. When you assess a collaboration product, ask who can see the membership of a shared space, because the answer is a privacy decision whether or not anyone made it deliberately.

Read together, the five items describe the same quiet truth. The expensive moments in software are not the launches. They are the bill you did not model, the permission that did not migrate, the thread that did not come across, the AI judgement you did not test, and the room whose membership you did not think to protect. A business choosing tools this week would do well to ask about each of them before the demo ends.