On April 27, 2026, SAP quietly published an update to its API policy. Section 2.2.2 now prohibits use of SAP APIs for "interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls" and for "scraping, harvesting, or systematic and/or large-scale data extraction or replication."
Read that clause carefully. It is not banning bad actors. It is banning the category of AI tools that would let you map your SAP data, understand your schema, and move your data somewhere else. It is banning AI-assisted migration tooling.
SAP did this because AI is making CRM and ERP migrations faster. And vendor lock-in depends on migrations staying slow.
The Old Moat
I have worked on CRM migrations. Salesforce to Dynamics 365 is the one I know best from the Dynamics side. The traditional version of that project involves weeks of discovery, custom field mapping documentation, data cleansing sprints, a staging environment, multiple test runs, UAT, cutover planning, and a team of specialists who do this for a living. The timeline is typically 6 to 18 months. The cost is significant. The risk of something going wrong at cutover is real.
That friction was not accidental. Vendors made it that way. Proprietary data formats. Weak export tools. No standards for how a sales pipeline or a contact record should transfer between systems. The technical complexity of moving customizations, workflows, and validation logic from one platform to another was a feature, not a bug, from the vendor's perspective. As long as leaving was painful enough, most customers would stay.
This is what vendor lock-in actually looked like for the last 30 years. Not contractual. Not because the product was irreplaceable. Just expensive enough to stay, painful enough to leave.
What AI Changes
The switching cost calculation is changing because AI can now do much of the hard work in migrations.
Specifically: AI agents can read a Salesforce or SAP schema, map entities and fields to their equivalents in another platform, flag data quality issues before migration begins, propose transformation rules for field type mismatches, and draft the migration logic itself. The kind of painstaking mapping work that used to require specialist consultants spending weeks in spreadsheets can now be done by an agent in hours. The result is not perfect and it still needs a human to review and validate it, but the bottleneck is gone.
Firms are already building this commercially. CongruentX, for example, has built AI-assisted Salesforce to Dynamics migration tooling that cuts project timelines significantly.
AI does not eliminate migration risk. Cutover is still delicate. Data quality is still your problem. Business logic that has accumulated for a decade still needs careful review. But the specialist-team bottleneck that made migration feel impossible for mid-sized organisations is dissolving. The switching cost is shrinking.
Vendors noticed.
The Policy Response
SAP's API policy update is the clearest signal that incumbents understand what is happening. But it is not the only one.
Salesforce changed its Slack API terms in June 2025 to block competitors from storing, indexing, or using Slack data in AI models. The practical effect: any AI tool trying to use Slack data to understand your organization's communication patterns, client history, or deal context for migration or integration purposes is now blocked. Salesforce simultaneously promotes its own AI products, built on that same Slack data, without restriction.
SAP is currently being sued by Celonis for blocking data extraction from SAP applications. SAP agreed to a temporary arrangement while the case continues.
The pattern holds across SAP, Salesforce, and Meta. Frame it publicly as security or platform stability. The practical effect is always the same: block AI that serves the customer's portability interests, permit AI that serves the vendor's retention interests.
This is the split worth naming. There are now two types of AI in enterprise software. AI that helps the vendor keep you in (Joule, Einstein, Copilot for Dynamics, whatever they call it next year) and AI that helps you understand your data, move it, and integrate it on your terms. Vendors are actively funding the first category and writing policy to kill the second.
SAP CEO Christian Klein told investors last month that "no customer, no partner needs to worry" and that SAP wants an open platform. The API policy document published the same week says otherwise. Policies govern enforcement. Press statements do not.
What This Means If You Run Dynamics 365
Microsoft is right now on the right side of this dynamic. Dynamics 365 benefits from customers leaving Salesforce and SAP. Microsoft's 2026 Release Wave 1 includes autonomous agents explicitly designed to accelerate implementation.
If you are on SAP or Salesforce and evaluating Dynamics 365, the migration calculation has changed. The switching cost is lower than it was two years ago, and the destination platform is better equipped to help you move.
But the pattern itself is worth watching. The moat Microsoft does not have today, it may find useful tomorrow. Every incumbent eventually faces the same incentive: when platform stickiness is your primary retention mechanism, anything that reduces stickiness is a threat. API policies are a convenient tool. They are easy to add, difficult to challenge without legal action, and easily framed as something benign.
Practical steps if you are building or procuring AI-assisted migration or integration tooling:
Check whether the source platform's API terms permit agentic access before you build on it. For SAP environments specifically, the policy is live and enforcement is event-driven: your next maintenance event or platform upgrade creates compliance exposure. There is no grandfather clause for existing integrations using undocumented APIs.
If you are running integrations built against SAP APIs that are not formally listed in SAP's documentation, you are already in a grey zone. That was always technically true, but SAP's updated policy makes enforcement more defensible on their side.
What the Policy Actually Tells You
Vendors do not write clauses banning AI-assisted migration because they are worried about security. They write them because they believe AI-assisted migration is becoming a real competitive threat to their retention.
Vendor lock-in used to be accidental. Nobody designed the friction; it emerged from complexity, proprietary formats, and accumulated customization. The new lock-in is deliberate. It is written into legal documents. It is enforced via API throttling and suspension.
That shift matters. Accidental friction is hard to address because it is everywhere and nobody owns it. Deliberate lock-in, once named, is a policy choice. Policy choices can be pushed back on, negotiated around, or factored into platform selection decisions before you are stuck.
The next time a vendor tells you their platform is open and they want you to succeed, read the API policy too.
If you are evaluating a platform move or want an architect's view on whether switching is worth it in your specific situation, get in touch.
