- Is it really worth relying on a single AI tool for your team?
- What really happened between Microsoft and Claude Code?
- The Uber case: what happens when Claude Code costs explode?
- What is AI vendor lock-in and why is it sneakier than in traditional software?
- How widespread is the fear of AI lock-in among companies?
- How do Copilot and Claude Code compare in the real market?
- Three concrete scenarios: what risks does an Italian company face if it doesn't manage AI lock-in?
- Which tools and architectures really reduce the risk of lock-in?
- How do you practically get started to reduce AI lock-in in your company?
- What are the most common mistakes made by those who adopt AI tools without thinking about lock-in?
- How to tell if your AI strategy is flexible enough?
- So, is AI vendor lock-in worth worrying about for your business?
- How we see it at SHM
- Frequently Asked Questions
- Microsoft removed Claude Code internally because it eroded the adoption of Copilot, its own proprietary product: quality isn't enough to guarantee the continuity of an enterprise tool.
- Vendor lock-in in AI isn't just contractual: it's built through habits, integrations, and established prompts — and the average cost of an enterprise migration exceeds $300,000.
- 81% of enterprise decision-makers are worried about dependence on a single AI provider, but only 6% believe they could switch without operational disruptions.
- For Italian SMEs, the priority is to map existing dependencies and choose tools with standard APIs, before lock-in becomes a costly problem to solve.
Updated October 10, 2026
In May 2026, Microsoft revoked Claude Code licenses for thousands of employees — not because the tool didn’t work, but because it worked too well. For Italian SMEs choosing their AI tools, this story is worth more than any benchmark.
Is it really worth relying on a single AI tool for your team?
No, and the Microsoft case demonstrates this concretely: a tool can be removed overnight, regardless of its effectiveness. The right question isn't which tool to choose, but how to avoid depending on just one.
In May 2026, Microsoft began systematically revoking Claude Code licenses — the AI-assisted programming tool developed by Anthropic — for thousands of its employees. Most users were redirected to Copilot CLI, Microsoft’s internal product.
The news, reported by The Verge , caught many by surprise. Claude Code was popular. It worked. Yet it was removed.
For any company trying to figure out which AI tools to pick, this whole story is a case study worth reading closely.
| Your situation | Is it worth relying on a single AI provider? | why |
|---|---|---|
| You use a single AI tool for all core processes | No, for now | A license or vendor strategy change halts the entire operation |
| You integrated AI into secondary or experimental processes | Low risk, but keep an eye on it | The impact of a migration is limited, but grows over time |
| You use standard APIs with multiple vendors | Yes | You can switch models without rebuilding workflows |
| You are evaluating your first corporate AI tool | Yes | The right time to choose with portability criteria right from the start |
What really happened between Microsoft and Claude Code?
Microsoft opened Claude Code to its employees in December 2025 as an internal experiment. Six months later, it removed it because Anthropic's product was cannibalizing the adoption of Copilot, its proprietary asset.
In December 2025, Microsoft opened Claude Code to thousands of employees. The goal was twofold: to bring non-technical roles like project managers and designers closer to code, and to measure how much an external AI tool could accelerate internal productivity.
The results were surprising: Claude Code became very popular. Too popular, from a strategic standpoint. An Anthropic product was eroding the adoption space of Copilot, the asset on which Microsoft has built a significant part of its enterprise offering.
The answer arrived in May 2026: systematic license revocation, forced migration to Copilot CLI. Fast, predictable, costly for those who had already integrated the tool into their workflows.
The context is relevant: in April 2025, CEO Satya Nadella told CNBC that 20-30% of the code in Microsoft's internal repositories is already written by generative AI. In this scenario, which tool generates that code is a strategic, not operational, decision.
| Actor | What was gained | What was lost |
|---|---|---|
| Microsoft | Control over the internal AI ecosystem, reinforced Copilot adoption | Credibility as an environment open to external innovation |
| Anthropic (Claude) | Enterprise visibility, product quality validation | A significant internal distribution channel |
| Developers and hybrid teams | No immediate gains | Consolidated workflows, prompts, and automations to be rebuilt |
| External SMEs (observers) | A real-world lesson before making the same mistake | No direct loss |
The Uber case: what happens when Claude Code costs explode?
Uber burned through its entire 2026 AI budget in just four months due to the massive adoption of Claude Code among its engineers. It's the other side of the same coin: a tool that works well can become a financial problem before it even becomes a strategic one.
The Microsoft case is not isolated. According to Forbes , Uber has exhausted its entire 2026 AI budget by April, just four months into the year. The cause: the massive adoption of Claude Code among its engineers.
Uber's CTO confirmed he's "back to square one" on the budget. Monthly API costs per engineer ranged from $500 to $2,000 — a huge range, making planning difficult.
Internal adoption grew rapidly: between February and March 2026, the percentage of Uber engineers using Claude Code jumped from 32% to 84% in just one month.
95% of Uber engineers use AI tools monthly, and 70% of committed code is AI-generated. Impressive numbers — but they also show how quickly a dependency on a single tool can become structurally and financially uncontrollable.
For an Italian SME, the lesson is clear: before adopting an AI tool on a large scale, you need a realistic cost model that considers usage growth, not just the initial cost per license.
What is AI vendor lock-in and why is it sneakier than in traditional software?
In traditional software, lock-in is made of contracts and proprietary formats. In AI, the bond is built through habits, consolidated prompts, and invisible integrations — and dismantling it costs much more than you might think.
Vendor lock-in (dependency on a single supplier, in Italian) in enterprise AI is different from that of classic software. It's not just about contracts or proprietary file formats.
When a team adopts an AI tool for months, they develop established prompts, optimized workflows, and a specific learning curve. Changing tools doesn't just mean changing licenses: it means starting over on multiple levels simultaneously.
The issue of lock-in in AI systems is also explored in the analysis on AI coding agents and vendor lock-in , which explores how SMEs can structure themselves to avoid excessive dependencies.
| Dependency type | How it forms | Exit cost |
|---|---|---|
| contractual | Multi-year licenses, exit penalties | Medium — manageable with negotiation |
| Technical (proprietary APIs) | Integrations built on vendor-specific endpoints | High — requires code refactoring |
| Operational (habits and prompts) | Team working with the same tool for months | High — retraining and productivity loss |
| Cognitive (specific skills) | In-house training on a single tool | Very high — non-transferable skills |
According to CIO Dive (cited by Kong) , the average cost of migrating a project from one enterprise platform to another is $315,000, including data migration, application refactoring, team retraining, and operational downtime.
For an Italian SME, even a fraction of this cost can be unsustainable. That's why evaluating portability must happen before of adoption, not after.
How widespread is the fear of AI lock-in among companies?
A lot: 81% of enterprise decision-makers are concerned about dependence on a single AI provider, but only 6% believe they can switch without operational disruptions. The problem is known, but almost no one has a ready solution.
Worrying about AI vendor lock-in is common, but it usually stops at awareness without turning into real action. A 2026 Zapier survey of 500 US enterprise executives captures the situation well.
The gap between those who are worried (81%) and those who have a viable way out (6%) is enormous. It means that most organizations know they have a problem, but haven't yet created the conditions to solve it.
The topic is closely related to AI tool governance — that is, internal rules on which tools can be adopted, with what criteria, and with what limits. On this front, the analysis on enterprise workspace management with AI offers a useful starting point to structure internal policies.
How do Copilot and Claude Code compare in the real market?
GitHub Copilot has more subscribers, but Claude Code is rapidly gaining ground among active developers. Market data shows an open competition, not a foregone conclusion for Microsoft's product.
GitHub Copilot reached 4.7 million paying subscribers in January 2026, with 75% year-on-year growth, and is adopted by 90% of Fortune 100 companies (the 100 largest US companies by revenue). Data reported by Windows Central .
On the performance front, according to GitHub and Microsoft , Copilot generates on average 46% of the code written by active users — with peaks of 61% for Java developers — and developers who use it complete coding tasks 55% faster.
But adoption numbers tell a different story. According to a JetBrains survey of over 15,000 developers, reported in the analysis on GitHub Copilot and token-based billing , workplace adoption of Copilot dropped from 29% to 21% between January and July 2026, while Claude Code rose from 18% to 39% over the same period.
This data explains why Microsoft acted quickly. Claude Code was growing faster than Copilot among active developers — and Microsoft knew it internally, having seen the same dynamic among its own employees.
For anyone choosing a tool today, the point isn't which one is "the best": it's which one offers the most flexibility if things change.
Three concrete scenarios: what risks does an Italian company face if it doesn't manage AI lock-in?
The risk varies greatly depending on how integrated AI is into core processes. Here are three illustrative scenarios to understand the real impact on typical Italian companies.
Illustrative examples: numbers are meant to show the reasoning, they are not real customer data.
| Company type | How AI is used today | Lock-in risk | Estimated migration cost |
|---|---|---|---|
| E-commerce (20 people) | Product copywriting and automated customer care on a single tool | High — core processes dependent | Weeks of work + refactoring of automations |
| Professional firm (5 people) | Drafting documents and meeting summaries with a single AI tool | Medium — impact on productivity, not on systems | A few days of team retraining |
| Manufacturing company (80 people) | Production data analysis and integrated reporting in ERP via proprietary APIs | Very high — deep integration into management systems | Months of technical work + operational downtime |
The pattern is clear: the more AI is integrated into processes that cannot stop, the higher the cost of a forced migration. A manufacturing company that has built its production analysis on proprietary APIs from a single vendor is the most exposed — and the one with the least time to react if the vendor changes strategy.
Which tools and architectures really reduce the risk of lock-in?
The choice isn't between specific tools, but between open and closed architectures. An open architecture — based on interchangeable APIs and multi-vendor solutions — offers flexibility without sacrificing performance.
The big platforms — Microsoft, Google, Amazon — have every incentive to build closed ecosystems. Every proprietary tool adopted strengthens dependence on the reference cloud provider.
However, concrete alternatives exist. An open AI architecture — based on interchangeable APIs (standard programming interfaces, i.e., connectors that allow different systems to communicate), open-source models, or multi-vendor solutions — offers greater flexibility and allows you to choose the best model for each use case.
The topic is also covered in depth in the analysis on Claude Opus 5 and enterprise AI benchmarks , showing how model selection must be driven by the use case, not by vendor loyalty.
| Approach | Flexibility | Initial cost | Lock-in risk | Suitable for |
|---|---|---|---|---|
| Closed ecosystem (e.g., Microsoft 365 + Copilot) | Low | Medium | High | Those who want immediate integration and already use Azure |
| Multi-vendor with standard APIs | High | Medium-high | Low | Those who want control and portability over time |
| Open-source (e.g., Continue.dev, Ollama) | Very high | High (setup) | Very low | Those with internal technical skills |
| Hybrid (main vendor + open fallback) | High | Medium | Low | SMEs that want to balance practicality and flexibility |
How do you practically get started to reduce AI lock-in in your company?
Start with a mapping of existing dependencies, not an immediate replacement of tools. The goal is to build flexibility over time, not change everything at once.
- 1 · IT or digital manager Map existing dependencies Identify which AI tools are integrated into core processes and evaluate the real cost of a potential migration.
- 2 · Purchasing / procurement department Add portability to your selection criteria Before adopting a new AI tool, check that it exposes standard APIs compatible with multiple providers. Ease of exit is a criterion as important as functionality.
- 3 · Operating team Diversify your AI portfolio Don't put all your eggs in one vendor's basket. Spread your critical processes across at least two different players.
- 4 · Management Monitor vendor roadmaps The strategic decisions of major players — like Microsoft's — often anticipate broader market changes. Stay up to date on AI and process automation industry developments.
- 5 · HR / Training Train the team on portability Build in-house skills around cross-functional methods, not just a single tool. A team that knows how to use multiple tools is much less vulnerable.
- 6 · IT or digital manager Define a contingency plan For every critical AI tool, identify a viable alternative ahead of time. Don't wait for the vendor to change their strategy before you start looking.
What are the most common mistakes made by those who adopt AI tools without thinking about lock-in?
The most common is choosing the most popular tool of the moment without evaluating portability. The second is building deep integrations before testing the vendor's stability over time.
Let's consider a company that has integrated an AI copywriting tool into its entire content production workflow: brief, writing, revision, publication. When the vendor changes prices or terms of use, the company has no ready alternatives and must accept the new conditions or stop production. Potential case: the numbers are used to show the reasoning, they are not real data.
| Error | Why it is risky | How to avoid it |
|---|---|---|
| Choosing the most popular tool without assessing portability | Popularity doesn't guarantee continuity (see Claude Code in Microsoft) | Adding portability and standard APIs to selection criteria |
| Building deep integrations before testing the vendor | The exit cost grows with every added integration | Start with lightweight integrations, dive deeper only after 6-12 months |
| Do not estimate the cost of growing usage | API costs can explode (see Uber: $500-2,000/month per engineer) | Set a maximum budget and a cost-per-user model before adoption |
| Training the team on a single tool | Skills become non-transferable | Prioritizing training on methodologies, not specific tools |
| Not having a contingency plan | When the vendor changes, you start from scratch under pressure | Identify a viable alternative for each critical tool |
How to tell if your AI strategy is flexible enough?
There are concrete indicators to monitor: from dependency concentration to the estimated time for a migration. If you can't answer these questions, you already have a problem.
| Indicator | Positive signal | Risk signal |
|---|---|---|
| Number of AI vendors used for core processes | 2 or more, with defined fallback | Just 1 vendor with no alternatives |
| Type of APIs used | Standards (OpenAI-compatible, open REST) | Proprietary vendor APIs with no equivalents |
| Estimated time to migrate a core tool | Less than 2 weeks | More than 1 month or unestimable |
| Team skills | Methodological, applicable across multiple tools | Tied to a single tool or interface |
| Monthly cost per AI user | Stable and predictable | Variable or rapidly growing without control |
| Contingency plan | Documented and tested | Absent or never verified |
So, is AI vendor lock-in worth worrying about for your business?
It is worth it if you're integrating AI into core processes that cannot stop, or you're about to choose the first company-wide AI tool: now is the right time to do it with portability criteria.
A middle ground you're using AI in secondary or experimental processes: the risk is low today, but it grows with every added integration. Start mapping dependencies before they become structural.
Not yet if you use AI only for isolated and non-critical tasks, without integrations into business systems: lock-in isn't an urgent problem yet, but keep it on your radar when evaluating new tools.
How we see it at SHM
For us, AI should be integrated to free companies from routine — not to create new dependencies that are hard to dismantle. The Microsoft-Claude Code case confirms this: technology is the means, not the end. And a means that traps you is not a competitive advantage.
When we work with Italian SMEs on AI adoption, the first step isn't choosing the tool: it's understanding which processes you want to improve and with what flexibility constraints. Only then do we evaluate vendors.
This approach applies to Strategic AI integration in business processes, for training on process automation and for the AI-based business intelligence . In any case, portability is a design criterion, not an option.
The lock-in issue also concerns the choice of AI models: the analysis on Microsoft Frontier Company and enterprise AI engineers shows how even large companies are rethinking their tech dependencies. For SMEs, doing it earlier is always cheaper than doing it later.
You can explore all these topics in the cluster hub AI and process automation , where we gather the most useful analyses for decision-makers — not just for those who want to stay up to date.
Frequently Asked Questions
Yes, in May 2026, Microsoft began the systematic revocation of Claude Code licenses for most employees, redirecting them to Copilot CLI. The news was reported by The Verge. The reason is not technical: Claude Code was popular, but it eroded the adoption of Copilot, Microsoft's proprietary product.
Vendor lock-in in AI is built through habits, established prompts, and workflow integrations — not just through contracts or proprietary formats. Switching tools means starting over on multiple levels: technical, operational, and training. The average cost of an enterprise migration is estimated at over $300,000.
Try answering this question: if your main AI provider changed its terms tomorrow, how long would it take you to get back to normal operations? If the answer is ‘more than a month’ or ‘I don’t know,’ you already have a lock-in problem. Mapping existing dependencies is the first concrete step.
Yes. Microsoft's decision concerns internal use: Anthropic's Claude Code is still available as a commercial product for external companies and developers. The story is about Microsoft's internal strategy, not the product's market availability.
Costs vary greatly depending on usage. The Uber case shows a range between $500 and $2,000 per month per engineer — variability that is difficult to plan for. Before adopting a tool on a large scale, it is essential to define a realistic cost model that considers the growth of usage over time.
Three things in order: first, define which processes you want to improve and with what flexibility constraints. Second, evaluate vendors with explicit portability criteria — standard APIs, ease of migration, contractual transparency. Third, start with light integrations and go deeper only after verifying the vendor's stability over time.
A tool that works too well can be removed tomorrow: the real question is not which AI to choose, but how quickly you could do without it.
Related articles
Discover more articles exploring similar topics, selected to offer you a more complete and stimulating perspective. Each piece of content is carefully chosen to enrich your experience.
