Salesforce Connected App Migration: Preparing for the OAuth Changes

01Two Frameworks, Not One Rebrand

Connected Apps have been Salesforce's standard framework for OAuth-based integration for years. One metadata record holds both the app's technical definition, its OAuth scopes, callback URL, and supported flows, and its security policy, which profiles or permission sets can use it, IP restrictions, and similar controls. External Client Apps, or ECAs, are a newer, separate framework built to split those two things apart: a package definition a developer controls, and a subscriber-org security policy a local administrator controls independently. ECAs are also fully compliant with the Metadata API, which plain Connected Apps are not.

Both frameworks exist side by side today. Salesforce's own documentation states that it recommends using external client apps in all situations and migrating existing local connected apps to local external client apps, while also noting that some features are still only available through connected apps. Existing Connected Apps have not stopped working, and nothing has broken automatically for anyone as a result of this shift so far. Separately, Salesforce's release documentation for Spring '26 states that new Connected Apps can no longer be created directly in most orgs, except through package installation or a request to Salesforce Support. That restriction is about creating brand-new Connected Apps going forward; it does not affect ones already running.

02Three Separate Changes, on Three Separate Dates

The idea that "Salesforce is retiring Connected Apps" gets repeated as one single event, when it is really three distinct, separately-scoped changes, each affecting a different authentication mechanism. Treating them as one deadline is how a real, affected integration gets missed.

November 30, 2026: the OAuth Device Flow gets restricted to local apps

The Device Flow is built for clients that cannot easily show a login screen themselves: a CLI tool, a kiosk, an IoT device, or an unattended build server, where a user authorizes the app from a separate browser session. Multiple Salesforce integration specialists report that Salesforce has scheduled this change to take effect November 30, 2026, so that the Device Flow only works from a local External Client App with a localhost callback URL, meaning the same machine runs the client and completes the human authorization step. A Connected App using the Device Flow today either fits that local, single-machine shape and can become a local External Client App, or it doesn't, a remote, headless build server is the clearest example, and needs to move to a different flow entirely: typically the Client Credentials Flow for a genuinely unattended server-to-server case, or the Web Server Flow with PKCE where a real user is actually involved.

This is not the first Device Flow restriction. Salesforce already narrowed it once before, blocking the Device Flow specifically for uninstalled Connected Apps, apps a user had never explicitly authorized, starting in September 2025. The November 2026 change is broader and separate from that earlier one. Because Salesforce enforces some of these Release Updates on a schedule that can vary by org, confirm the real status for your own org under Setup > Release Updates rather than assuming the date applies uniformly everywhere.

February 20, 2027: the Username-Password Flow gets retired

The Username-Password Flow is the OAuth flow where an integration authenticates by directly posting a username, password, and security token, rather than going through a token-based handshake. It's simple to implement, which is exactly why some older integrations still use it, and it's also the reason Salesforce is retiring it: it means a live Salesforce password sits inside the integration's own configuration. Salesforce integration specialists widely report an enforcement date of February 20, 2027 for this Release Update; once it takes effect, an integration still using this flow stops receiving access tokens and fails.

The replacement depends on what the integration actually does: the Web Server Flow with PKCE for anything involving a real user, or the Client Credentials Flow for a genuine server-to-server integration. One detail worth knowing before planning this migration: External Client Apps do not support the Username-Password Flow at all. An integration built on it cannot simply be converted into an ECA; it has to be re-architected onto a supported flow first, and only then, if it makes sense, packaged as an External Client App.

Summer 2027: the legacy SOAP API login() call gets retired

Some older integrations, especially ones built before OAuth was standard, authenticate by calling the SOAP API's login() operation directly with a username, password, and security token, in SOAP API versions 31.0 through 64.0. Salesforce has confirmed that once an org upgrades to the Summer '27 release, calls to login() in those API versions stop being supported and stop working. The recommended replacement follows the same OAuth-based direction as the other two changes: the JWT Bearer Flow or Client Credentials Flow for server-to-server integrations, or the Web Server Flow for anything browser-based and user-involved, implemented through an External Client App.

03Finding Out What You're Actually Running

None of the three changes above matters until you know which of your own integrations use which flow, and most organizations cannot answer that from memory. The starting point is Setup > Connected Apps OAuth Usage, which reports which OAuth flows each Connected App has actually been using. App Manager gives you the underlying list of Connected Apps and their configuration. Login History, filtered by application name, shows real authentication events over time, which is useful for catching an integration that authenticates rarely enough that OAuth Usage alone might not surface it clearly.

The output of this step should be a plain inventory: every Connected App or scripted integration touching the org, which OAuth flow (or legacy SOAP login()) it currently uses, and which system or team owns it. For a business with a handful of integrations built by one team, this is an afternoon. For a business where integrations have accumulated across departments over years, some of them built by people no longer at the company, this step alone can turn up integrations nobody currently remembers owning.

04Mapping Each Integration to a Supported Architecture

Once you know what each integration currently does, the mapping decision comes down to three questions: does a real user need to be involved in authorizing it, does it run entirely server-to-server, and does it genuinely run on the same machine a person is using. A user-involved integration maps to the Web Server Flow with PKCE. A true server-to-server integration maps to the Client Credentials Flow or the JWT Bearer Flow, depending on what the target system supports. A local, single-machine tool that currently relies on the Device Flow maps to a local External Client App.

The one flow that needs different handling is Username-Password: because External Client Apps don't support it at all, an integration built on it has to move onto one of the other supported flows first. Only after that change is made does the question of whether to also package it as an External Client App become relevant.

05Using Salesforce's Migration Tooling

For an eligible local Connected App, App Manager includes a built-in "Migrate to External Client App" action that converts it directly, without hand-rebuilding the configuration from scratch. Selecting the action creates an equivalent External Client App based on the existing Connected App's settings, and the conversion preserves the app's existing OAuth Consumer Key and Secret, so systems that already store those credentials don't necessarily need to be reissued new ones. Salesforce also documents that the original Connected App remains available afterward as a read-only reference rather than being deleted outright, which is useful if you need to check exactly how it was configured before the migration.

That tooling only applies to a Connected App that already fits the local, eligible shape it's designed for. An integration using the Username-Password Flow, a headless remote client using the Device Flow, or a legacy SOAP login() integration doesn't fit that shape and needs the rebuild described next, not this conversion action.

06Rebuilding Integrations That Can't Simply Convert

An integration that can't use the built-in migration action needs its authentication logic changed directly: implementing the new OAuth handshake, Web Server Flow with PKCE, Client Credentials, or JWT Bearer, depending on the mapping decision above, updating how the integration stores and refreshes tokens, and removing whatever credential-handling code depended on the old flow. This is real development work, not a configuration toggle, and the amount of it scales with how many integrations are affected and how tightly the old authentication logic is woven into the rest of the codebase.

For a single custom integration built and maintained by an internal team that already understands it, this is a contained project. For an organization with several integrations built at different times by different people, possibly including some nobody currently maintains closely, rebuilding several authentication paths at once, correctly, without breaking whichever one happens to touch order or customer data, is a different kind of project.

07Testing Before Your Organization's Real Enforcement Date

Every one of the three changes above deserves the same discipline before it goes live: rebuild or reconfigure the integration in a sandbox first, using data and permissions that mirror production as closely as practical, and confirm the new authentication path actually works end to end, not just that a token gets issued. That means checking that the data the integration is supposed to move actually moves correctly, that a token refresh genuinely succeeds when it should, and that whatever the integration does when authentication fails, retry, alert, or silently drop the request, behaves the way you expect it to.

The integrations worth the most testing time are the ones tied to business-critical data flows: order processing, customer records, billing, anything where a quiet authentication failure would not be noticed immediately but would still cause real damage by the time it was.

08Validating That Production Kept Working After Cutover

Confirming a migration worked is a separate step from making the change. After cutover, Login History and the Connected Apps OAuth Usage report are the two places to check that an integration is actually authenticating through its new supported path, rather than failing quietly or falling back to a flow that happens to still work today but is also scheduled for retirement. Setting up an alert on repeated authentication failures for a given app is a reasonable ongoing safeguard, since a broken integration does not always announce itself with an obvious error a person will notice right away.

09When This Is Genuinely a Self-Service Change

For a business running one or two simple, well-understood Connected Apps, no custom Apex or Canvas integration, no middleware layer, and no legacy scripted authentication, this really is close to a self-service change. Salesforce's own migration tooling handles the common conversion case directly, the documentation is public, and a competent internal admin or developer can reasonably work through the inventory, mapping, migration, and testing sequence above without outside help. Saying otherwise would oversell a genuinely simple situation.

What makes an estate different is complexity that accumulates for ordinary reasons: multiple integrations built by different teams over time, custom Apex or Canvas apps, a middleware layer such as MuleSoft, Boomi, or something built in-house sitting between Salesforce and other systems, older scripted or point-to-point integrations that predate whoever currently works in IT, and business-critical data flows where an untested cutover risks real production impact. None of that requires hitting a specific integration count to matter; it's the actual condition of the estate, not a number, that determines whether this migration needs real discovery and coordinated implementation work rather than a few afternoons in App Manager.

An outside Salesforce implementation partner is most useful exactly at that point: doing the inventory and mapping work objectively, then implementing and testing the migration without interrupting the integrations that already work.

10Conclusion

Three real, separately-dated Salesforce changes affect three different authentication mechanisms between now and the middle of 2027: the Device Flow restriction, the Username-Password Flow retirement, and the SOAP login() retirement. None of them require guessing. The inventory, mapping, and testing sequence above works the same way regardless of which flow a given integration turns out to be using, and the honest answer to whether outside help is worth it depends on how many integrations are actually affected, how they're built, and how much production risk sits behind them, not on the deadline itself.