Every Salesforce org that has ever integrated with an external system has a Connected App. OAuth flows, JWT authentication, MuleSoft connections, data loader configurations, third-party ISV tools — all of them were built on Connected Apps. Starting with Spring '26, Salesforce disabled the creation of new Connected Apps by default across all orgs. If you need a new one, you now need to file a Support request — and Salesforce has been explicit that this option will eventually disappear entirely. The migration is not optional. It is a question of when, not whether.
This is not a soft deprecation. Connected Apps existing in your org will continue to work — for now. But the architecture they are built on is officially on the path to end of support, and the direction of travel is unambiguous. External Client Apps are the replacement, and understanding what that means technically is the only way to plan the migration correctly.
The Timeline You Need to Know
(Now Live)
If any of your integrations used session IDs in outbound messages, they stopped working on February 16, 2026. This is not a future deadline — it is a past one. Run a search in Setup under Outbound Messages and check your workflow rules and flows for any outbound message actions that were relying on session ID authentication.
What External Client Apps Actually Are — Technically
External Client Apps (ECAs) are not a renamed Connected App. They are a fundamentally different integration model built on Second Generation Packaging (2GP) rather than the legacy packaging model that Connected Apps use. That architectural difference is what drives most of the behavioral differences between the two.
The security improvement is intentional and material. Connected Apps created by external parties could be self-authorized by any API-enabled user — this is the vector that phishing and vishing attacks have exploited. ECAs require admin installation, which eliminates that attack surface entirely. The tighter defaults are not a limitation — they are the point.
The OAuth Flows — What Changed and What Did Not
The most technically impactful difference for developers is the OAuth flow support matrix. External Client Apps do not support the implicit flow or the username/password flow. Both were already considered bad practice, but orgs that still had legacy integrations using them will need to migrate those authentication patterns before migrating the Connected App itself.
Authorization Code Flow ✓ Supported (standard user-facing OAuth) JWT Bearer Flow ✓ Supported (server-to-server, recommended) Client Credentials Flow ✓ Supported (machine-to-machine) PKCE Extension ✓ Supported (public clients, mobile apps) Device Authorization Flow ✓ Supported (IoT, CLI tools) Implicit Flow ✗ Removed (deprecated, insecure by design) Username / Password Flow ✗ Removed (deprecated, credentials exposed)
Before migrating any Connected App to an ECA, audit the OAuth flow it uses. If it uses the username/password flow — commonly seen in older MuleSoft connectors and legacy ETL tools — the authentication pattern needs to be updated to JWT Bearer or Client Credentials flow before the app migration will work correctly.
The Migration — Step by Step
Audit every Connected App in your org
Go to Setup → Connected Apps OAuth Usage. Export the list. Note which apps are actively authorized (have active user sessions), which OAuth flow each uses, and whether they are managed by your team or by a third-party ISV. This inventory is the foundation — you cannot prioritize migration without knowing what you have.
Identify which apps are ISV-managed vs. org-owned
Apps created by ISVs on external orgs and installed into your org follow a different migration path. You cannot migrate an ISV's Connected App yourself — you need the ISV to publish an ECA version of their product and migrate you to it. Contact your ISV vendors now. The ones that are slow to respond are the ones whose products will break when Connected App creation becomes impossible.
Use Salesforce's built-in migration tool for org-owned apps
For Connected Apps you own and manage, Salesforce has released a native migration path: Setup → App Manager → select your Connected App → Migrate to External Client App. This creates an ECA with the same OAuth settings and client credentials. Validate in sandbox first — redirect URIs, token behavior, and permission sets all need verification before migrating production.
Update sandbox cloning procedures
Connected Apps are copied automatically when you clone a sandbox. ECAs are not — they are only copied if packaged. This behavioral difference means your sandbox refresh process needs to include an explicit step to configure ECAs in the new sandbox environment. Update your DevOps runbooks before this catches you in a production deployment.
Update your outbound message authentication to OAuth
If this was not done before February 16 — the date session IDs were removed — your outbound messages are already failing. The fix is to configure Named Credentials for outbound message authentication and update your workflow rules or flows to use OAuth-based authentication instead of session ID passthrough.
Build a certificate rotation process before the 2029 deadline
TLS and SAML certificate maximum validity is moving to 47 days by 2029. Annual certificate management — the current default in most orgs — will be non-compliant. The time to build an automated certificate rotation process is now, while 2029 still feels distant. Orgs that wait until the deadline are the ones that have production incidents on the deadline date.
External Client Apps currently do not support Canvas App exposure or push notifications — two Connected App capabilities that some orgs rely on. Salesforce is actively closing this gap with each release. If your org uses either of these features, keep those specific Connected Apps in place while monitoring ECA release notes for the capabilities to arrive before planning that specific migration.
Connected Apps will not vanish from your org overnight. But Salesforce has shut the door on creating new ones, and the direction toward end of support is clearly stated. The organizations that audit their Connected App inventory now, identify ISV dependencies, and begin phased migration to External Client Apps are the ones that absorb this change on their own timeline rather than on Salesforce's. The ones that wait will migrate in a hurry — and hurried integration migrations are where production incidents happen.