Connected Apps Are Going Away. Here's What's Next

If you've built any kind of Salesforce integration in the last decade, you've almost certainly used a Connected App. They're the unsung plumbing behind OAuth flows, mobile apps, middleware connectors, and a thousand other integrations. And starting with the Spring '26 release, you can't make new ones anymore.

That's not clickbait. As of January 2026, every Salesforce org has the ability to create new Connected Apps disabled by default. If you click the button to make one, you'll get blocked unless Salesforce Support specifically turns the capability back on for your org. Existing Connected Apps still work, and managed-package Connected Apps still work, but the message is loud and clear: the platform is moving on.

The replacement is something called an External Client App, or ECA, and I've been migrating a few orgs over the past couple of months. It's not a one-click swap, and there are a few gotchas worth knowing before you start. Here's what I've learned.

What Actually Changed in Spring '26

For years, Connected Apps were the only real option for defining how an outside system talks to Salesforce. The architecture worked, but it had baggage. Connected Apps were tied to first-generation packaging, the metadata model was clunky, and security defaults were generous in a way that didn't age well. If you've ever inherited an org with thirty mystery Connected Apps in it, half of them with "Admin approved users are pre-authorized" turned on, you know what I mean.

External Client Apps are Salesforce's answer. They were introduced in earlier releases as an opt-in alternative, but Spring '26 is the moment they became the default path forward. The headline change is that creating new Connected Apps is now blocked by default, which is Salesforce's way of nudging admins, devs, and ISVs onto ECAs without ripping the rug out from under existing integrations.

A few practical things to know. First, this only blocks the creation of new Connected Apps. Anything you already have keeps running. Second, if you absolutely need to create a new Connected App for some legacy reason, you can open a case with Support and ask them to enable it. Third, packaged Connected Apps that come from the AppExchange are unaffected, so you don't need to panic about that managed package you installed in 2019.

If you're newer to the platform and these terms are blurring together, I'd point you to salesforcedictionary.com for plain-English definitions of OAuth flows, named credentials, JWT bearer tokens, and the rest of the auth vocabulary you'll bump into during a migration.

Why External Client Apps Are Better (Mostly)

I'll admit I was skeptical at first. Salesforce loves rebranding things, and I half-expected ECAs to be Connected Apps with a new coat of paint. They're not. There are real architectural differences that matter.

The big one is second-generation packaging. ECAs were built from day one to play nicely with 2GP, which means ISVs can ship them as part of unlocked or managed-2GP packages without the workarounds Connected Apps required. If you build for AppExchange, this alone is worth the migration effort.

The second difference is that ECAs separate the app definition from the runtime policies. With Connected Apps, the OAuth scopes, IP restrictions, and refresh-token behavior were all bundled together. With ECAs, the metadata is split across multiple types - the app itself, OAuth settings, OAuth policies, and global settings - so you can update one piece without redeploying the whole thing. It feels more like modern infrastructure-as-code.

Third, the defaults are tighter. New ECAs are not available to users by default. You have to explicitly grant access through profiles or permission sets, which is how it should have worked from the start. Salesforce also pushed harder on the "refresh token valid until revoked" pattern, which is what most real integrations need anyway.

The "mostly" in my section header is because there are still rough edges. The migration tool doesn't cover SAML-only Connected Apps in every scenario, and if you're using canvas apps or some of the older mobile-related features, you'll want to test thoroughly. ECAs are also not available in every edition tier yet, so check before you start planning.

How to Migrate Connected Apps to External Client Apps

Here's the part most people care about. Salesforce shipped a built-in migration tool, and it works for most local Connected Apps. By "local" I mean Connected Apps that live in your org and weren't installed through a managed package.

The basic flow looks like this:

1. Go to Setup, type "App Manager" in the Quick Find box, and open it.
2. Find the Connected App you want to migrate. There's now a row-action option called "Migrate to External Client App."
3. Click through the wizard. It'll create a new ECA with the same OAuth settings, scopes, and callback URLs.
4. Update the App Authorization policy on the new ECA. The default is "Admin approved users are pre-authorized" but for most integrations you'll want to set "Refresh token is valid until revoked" so your tokens don't expire and break things at 2 AM on a Sunday.
5. Test your integration against the new ECA's Consumer Key and Secret in a sandbox before you cut over in production.
6. Once you're confident, update your middleware, mobile app, or service to use the new credentials, then deactivate the old Connected App.

A few things I learned the hard way. The new ECA gets a different Consumer Key and Consumer Secret. You cannot reuse the old credentials, which means every system that authenticates against the old Connected App needs an update. If you have integrations scattered across MuleSoft, custom Node services, third-party connectors, and a Heroku app someone built five years ago, make a list before you start so nothing gets missed.

Also, certificate management is its own conversation. ECAs use the same digital certificates and JWT bearer flow as Connected Apps, but Salesforce has been pushing harder on shorter rotation cycles and proper key management. If you're using a self-signed cert from 2018 because "it still works," now's a reasonable time to fix that.

For ISVs distributing apps through AppExchange, the migration story is different and a bit more involved. You'll want to read the External App Management documentation specifically for packaging, because the steps for moving a managed-package Connected App to a packaged ECA aren't the same as the local migration.

What This Means for Admins and Architects

If you're an admin who doesn't write code, you might be wondering whether this affects you. It does, but probably less than you think.

The day-to-day stuff stays the same. Users still log in. Single sign-on still works. The Salesforce mobile app still works. What changes is what happens the next time someone asks you to set up a new integration. You'll be creating an External Client App instead of a Connected App, and the screens look different, and the permissions model is a little stricter.

For architects, the picture is bigger. ECAs are part of a broader push toward what Salesforce calls "inbound governance" - giving orgs better visibility into who's calling their APIs, with what scopes, and how often. There's a new External Client App Usage report that shows you token activity per app, which is genuinely useful for spotting integrations that have gone rogue or that nobody can remember setting up.

If you're planning roadmaps right now, I'd recommend three things. Inventory your Connected Apps, prioritize the ones with the most token traffic or the most security exposure, and migrate those first. Don't wait for a forced sunset announcement, because Salesforce has been clear that "End of Support" is the destination, even if the timeline is fuzzy.

For folks studying for certifications, this is also fair game on the Platform Developer II and Identity & Access Management Designer exams. The Salesforce glossary at salesforcedictionary.com has been a useful reference when I've been refreshing on OAuth terminology and security concepts for exam prep.

A Few Things I'd Watch Out For

Before I wrap up, a quick list of things that have bitten me or people I work with during ECA migrations.

The "Available for Customer Users" setting doesn't carry over the same way in every case. If you have a Connected App used for Experience Cloud or Customer Community auth, double-check the user access settings on the migrated ECA.

Named Credentials that reference a Connected App by Auth Provider need to be updated to point at the new ECA. This is easy to forget because the Named Credential UI doesn't make it obvious that the underlying Auth Provider has changed.

If you have automated tests that hit Salesforce APIs, your CI pipeline probably has the old Consumer Key in a secret somewhere. Update those secrets before you decommission the old Connected App or you'll be debugging a green build that suddenly turns red.

Lastly, monitor token activity for at least a couple of weeks after cutover. The new ECA Usage report is your friend here. If something is still authenticating against the old Connected App, you'll see it, and you can chase down the missing system before you turn the old app off.

Wrapping Up

Spring '26 isn't the end of Connected Apps, but it's the end of Connected Apps as the default. External Client Apps are the path forward, and the sooner you start migrating, the less painful it'll be when Salesforce eventually pulls the plug on the old way. The migration tool handles most of the work, but the credential rotation, named-credential updates, and downstream integration testing are still on you.

If you've already migrated some of yours, what tripped you up? Drop a comment below. And if there are specific Salesforce terms you'd like to see explained more clearly, salesforcedictionary.com keeps growing a glossary of platform vocabulary that I find myself sending to teammates regularly.

Happy migrating.