External Client Apps in Salesforce: Your 2026 Migration Playbook

If you've tried to create a new Connected App in your Salesforce org recently and saw a polite "this is no longer supported by default" message, you're not alone. Spring '26 quietly flipped a switch that's been a long time coming, and a lot of admins are realizing their integration playbook needs an update.

Connected Apps aren't gone. But they're no longer the default, and Salesforce has made it pretty clear which direction the platform is moving. External Client Apps (ECAs) are now the recommended path for any inbound integration, and if you're still building on the old framework, you're putting future migration debt on your team's plate.

I've spent the last few weeks helping a handful of orgs work through this transition, and the pattern is the same every time: people aren't sure what's actually changing, what they need to migrate, and how risky the move is. So let's walk through it.

What Actually Changed in Spring '26

Here's the short version. Starting in Spring '26, Salesforce disabled the creation of new Connected Apps by default across all orgs. If you go into Setup and try to spin up a new Connected App through the UI or the Metadata API, it won't let you, unless Salesforce Support explicitly turns that capability back on for your org.

Existing Connected Apps still work. Nothing breaks immediately. But the writing's on the wall: ECAs are the go-forward integration framework, and Salesforce isn't being subtle about pushing teams toward them.

Why now? A few reasons. ECAs use second-generation managed packaging, which gives Salesforce (and you) better packaging, distribution, and lifecycle management. They're also designed around the modern OAuth 2.0 flows that the security community has converged on. Connected Apps were built years ago, and the framework has been showing its age, especially around things like Username-Password flows that nobody should be using in production anymore.

If you're new to some of this terminology, the Salesforce Dictionary has a clean reference for OAuth flows, packaging types, and other integration concepts that are useful to keep handy as you read through Salesforce's release notes.

Connected Apps vs External Client Apps: The Real Differences

I see a lot of people treat this like a rebrand. It's not. There are real architectural differences that matter when you're planning a migration.

ECAs are first-class metadata in second-generation managed packages, which means they version cleanly, can be distributed via unlocked or 2GP managed packages, and don't carry the historical baggage of the old packaging system. Connected Apps were always a bit of an awkward fit in packaging.

ECAs also enforce a stricter security posture. Some of the older OAuth flows aren't supported. Specifically, Username-Password flow and User-Agent flow are not available in ECAs. If your integration depends on either of those, you've got refactoring work to do before you migrate.

On the upside, ECAs introduce some nice quality-of-life features:

• Per-policy enable flags that let you turn specific OAuth flows on or off without touching the whole app
• Plugin-style extensibility for custom token enforcement
• Better admin visibility into which integrations are calling your org and how often

If you've been managing a sprawl of Connected Apps with vague names and unclear ownership, ECAs give you a chance to clean house.

The Migration Path for Local Apps

Most orgs have at least a few "local" Connected Apps. These are ones you created directly in your org rather than installing from a managed package. The good news: Salesforce ships an automated migration tool for these, and it's actually pretty good.

The flow is straightforward. Open Setup, go to App Manager, find the Connected App you want to convert, and click "Migrate to External Client App." The tool walks through the conversion and, importantly, preserves your existing OAuth Consumer Key and Consumer Secret.

That last part is the thing that surprises people. You don't have to update the credentials in the external system that's calling Salesforce. The new ECA inherits the existing identity, so your Postman collections, your middleware configs, your Heroku app, your custom Node service, all of it keeps working with the same client ID and secret. That alone removes about 80% of the coordination pain that integration migrations usually involve.

A few things will block the automatic migration:

• Username-Password or User-Agent flows are unsupported. The migration will fail or skip these.
• Expired push notification certificates. If you have an Apple P12 cert that's expired, or an Android Server Key configured the deprecated way, the conversion fails until you fix them.
• Special distribution state. If the Connected App came from a managed package, the local migration tool won't touch it. You wait for the ISV to ship an ECA version, or you replace it manually.

Run the migration in a sandbox first. I cannot stress this enough. Even when it works perfectly, you want to validate your tokens still issue correctly, your scopes haven't changed, and any custom permissions tied to the app still resolve.

Authentication Flows: What Works, What Doesn't

This is the part where I see teams get caught off guard. ECAs are opinionated about authentication, and that's mostly a good thing, but it means you might have to refactor.

Supported and recommended:

• OAuth 2.0 Web Server Flow with PKCE for user-facing applications. This is the standard for any UI-driven integration.
• OAuth 2.0 Client Credentials Flow for server-to-server integrations. If you're calling Salesforce from a backend service that doesn't impersonate a user, this is what you want.
• OAuth 2.0 JWT Bearer Flow for system integrations that need to act as a specific user without an interactive login.
• SAML for federation scenarios.

Not supported in ECAs:

• Username-Password Flow. Anywhere this still exists in your stack, plan to migrate to Client Credentials or JWT Bearer.
• User-Agent Flow. Replace with Web Server + PKCE.

If you're inheriting an integration that uses Username-Password (and there are a lot of these floating around in older orgs), the refactor is usually small but the coordination is the hard part. You need to coordinate with whoever owns the calling system, generate a certificate, configure JWT, and update the integration code. None of that is hard individually. It's the calendar Tetris that takes time.

A Practical Migration Strategy

Here's the playbook I'd run for any non-trivial org. None of this is glamorous, but it works.

Step 1: Inventory your Connected Apps. Pull a list from Setup or query ConnectedApplication via the Tooling API. For each one, note who owns it, what it does, what OAuth flow it uses, and whether it's actively being called. A surprising number of Connected Apps in older orgs are no longer in use, and you can just delete those.

Step 2: Categorize by complexity. Anything using Username-Password or User-Agent goes in the "needs refactor" bucket. Apps using Web Server, JWT Bearer, or Client Credentials are "easy migration." Push notification apps need cert validation first.

Step 3: Pilot in sandbox. Pick one easy app, run the automated migration, test it end-to-end, then turn off the original Connected App temporarily to confirm the new ECA is what's actually getting called.

Step 4: Run them in parallel. This is the underrated move. ECAs and Connected Apps can coexist. Deploy the ECA, point traffic at it gradually, and only retire the Connected App once you've validated everything works. There's no need to do a hard cutover.

Step 5: Document and update runbooks. This step gets skipped and it costs teams later. Update your integration documentation, your incident playbooks, and any onboarding materials so the next person doesn't have to rediscover all this. If your team uses Salesforce Dictionary as a quick reference for terminology, link your internal docs to it for definitions of OAuth scopes, ECA components, and the like, it saves your team from rewriting the same explanations.

Common Mistakes I've Seen

Three patterns come up over and over:

Migrating without testing the calling system. The credentials carry over, but if your calling system has hardcoded assumptions about token lifetimes, refresh behavior, or scope formats, you can still hit subtle issues. Test the actual integration flow, not just the OAuth handshake.

Ignoring scopes. ECAs let you scope down more aggressively than Connected Apps did. Take advantage of this. If your integration only needs api and refresh_token, don't carry over full just because it was easy.

Treating this as "an admin task." Migration touches authentication, which means it touches security. Loop in your security team early. They'll have opinions about token rotation policies, IP restrictions, and audit logging that are easier to bake in now than retrofit later.

What to Do This Week

If you take nothing else from this, do these three things:

1. Run a Connected App inventory in your production org.
2. Identify any apps using Username-Password or User-Agent flows. These are your highest-priority refactor candidates.
3. Pick one low-risk app and run the migration in a sandbox to get a feel for the tool.

Spring '26 is the start of this transition, not the end. The next few releases will keep tightening the screws on Connected Apps, and the orgs that get ahead of it will be a lot calmer than the ones who wait. ECAs aren't a panacea, but they're a meaningfully better foundation for inbound integrations, and Salesforce is clearly committing to them as the future.

If you're still parsing through new terminology around all this (ECA, 2GP, PKCE, JWT Bearer), bookmark salesforcedictionary.com as a reference. It's been a useful glossary to drop into Slack threads when teammates ask what something means without having to type out a full explanation every time.

Have you started your migration yet? What's been the trickiest part for your team? Drop a comment below, especially if you've hit a snag with managed-package Connected Apps, since those are the cases where the playbook gets fuzzy and we could all use more shared experience.