Companion to the OAuth device flow restriction, which forces this migration for one category of app on 30 November 2026, ahead of the general deadline.
TL;DR
- Salesforce is ending support for connected apps in Summer '27. External client apps are the replacement.
- The connected app migration tool now works on apps packaged in 1GP or 2GP managed packages, and on unpackaged apps distributed to external orgs or other internal orgs. Those were the cases with no clean path before.
- Existing OAuth flows, tokens and active sessions stay valid through the package upgrade. Subscribers do not reconfigure and do not reauthorize.
- Run it from App Manager in Setup: open the connected app, click Migrate to External Client App. The process is automated and produces a packaged external client app.
- If you distribute an app, this is your project on behalf of every org that installed it. If you only consume apps, it is mostly somebody else's.
What You'll Learn
- Which category of connected app you actually have, because the answer changes the work
- What the tokens-stay-valid guarantee covers and what it does not
- Why the device flow deadline arrives before the general one
- How to sequence this if you are an ISV with subscribers on different schedules
The Problem
Connected apps have been the way an external system identifies itself to Salesforce for over a decade, which means most orgs have accumulated some and most ISVs have shipped at least one.
Salesforce is retiring them. External client apps are the successor, built on a cleaner separation between the app's definition and the policy applied to it, so the two can be versioned and deployed independently. That separation is the actual motivation, and it is a real improvement for anyone who has tried to manage connected app configuration across environments.
The awkward part has never been the destination. It has been the migration path for apps that are not simple single-org configurations. A connected app inside a managed package is installed in orgs you do not control, used by customers whose integrations you cannot test, and upgraded on a schedule that is partly theirs. A connected app distributed to external orgs has the same problem without the package.
Those were the cases where "migrate to external client apps" was advice rather than an instruction. Winter '27 closes that gap.
Common questions this article answers:
- Does the migration break my subscribers' existing integrations?
- Which of my connected apps are actually in scope?
- What is the real deadline, given the device flow date is earlier?
Quick Answer
Salesforce ends support for connected apps in Summer '27, and the connected app migration tool now covers connected apps packaged in first- or second-generation managed packages as well as unpackaged connected apps distributed to external orgs or other internal orgs. You run it from App Manager in Setup by opening the connected app and clicking Migrate to External Client App, which creates a packaged external client app through an automated process. The guarantee that makes this manageable at scale is that customer OAuth flows, tokens and active sessions remain valid through the package upgrade, so subscriber orgs do not need to reconfigure anything or reauthorize their integrations. It is available across Group, Essentials, Professional, Enterprise, Performance, Unlimited and Developer editions. Note that one category of app has an earlier deadline: connected apps using the OAuth 2.0 device flow must be external client apps by 30 November 2026, well ahead of the general Summer '27 date.
Work out which case you are in
The word "migration" covers three quite different amounts of work, and the first useful step is knowing which one applies.
A connected app you created and only you use. This is the simple case. The app exists in your org, you control every integration that authenticates through it, and you can test the whole path yourself. The tool converts it and you verify your own integrations.
A connected app you distribute to other orgs, unpackaged. Harder, because the consumers are elsewhere. You still control the definition, but you cannot see whether a given consumer's integration is healthy after the change. This is one of the cases the tool now handles.
A connected app inside a managed package. The largest case, and the one where the tokens-stay-valid guarantee matters most. Your subscribers receive the change as a package upgrade, on their schedule, and you find out about problems through support rather than through testing.
Start with App Manager in Setup to see what you have. For anything that has actually been used to authenticate, Connected Apps OAuth Usage is a shorter and more useful list than the full inventory, because it tells you which apps have live consumers rather than which ones exist.
What the continuity guarantee does and does not cover
Salesforce's wording is worth taking precisely: customer OAuth flows, tokens, and active sessions remain valid through package upgrade, so there is no need to reconfigure or reauthorize for the packaged external client app.
That is a strong statement and it removes the thing that would otherwise make this migration unshippable for an ISV. Without it, every subscriber's integration would need a reauthorization at upgrade, which in practice means every subscriber schedules downtime, and a meaningful proportion of them do it late and blame you.
What it does not do is remove your testing obligation. Continuity of tokens is not the same as identity of behaviour, and an external client app is a different object with a different policy model. The scenarios worth exercising before you ship the upgrade are the ones where your app's behaviour depends on the app's own configuration rather than on the token: scope evaluation, IP relaxation policy, refresh token policy, and anything your code reads back about the app itself.
Treat the guarantee as removing the coordination problem, not the testing.
Two deadlines, and the earlier one is easy to miss
The general end of support for connected apps is Summer '27. That is the date most coverage quotes and it is correct for most apps.
There is an earlier one. Connected apps using the OAuth 2.0 device flow are restricted to local external client apps with a localhost callback from 30 November 2026, which is a fixed date rather than a release-linked one. For those apps, migration is not a Summer '27 project. Covered in full in the device flow restriction.
The practical consequence is a sequencing decision. If you have device flow apps, they set your timeline and they are also your best pilot: a small, forced, early migration is a good way to learn the tool before you run it against the apps with subscribers attached.
If you are an ISV
Three things worth planning that are specific to distributing an app.
Your subscribers upgrade on their own schedule. The migration lands when they take the package version, so your deadline is not the date you ship, it is the date the slowest subscriber upgrades. Work backwards from Summer '27 accordingly, and expect the tail to be long.
Your support load moves before your code does. The first questions arrive when you announce, not when subscribers upgrade. Have an answer ready for "do we need to reauthorize", because the answer is no and saying so early prevents a lot of tickets.
Test the upgrade path, not just the end state. An external client app created fresh in a scratch org is not the same test as a subscriber org upgrading from a package version that contains a connected app. The second one is what your customers will experience.
Frequently Asked Questions
Q: We only install apps from AppExchange. Is this our problem?
A: Mostly not. The migration is carried out by whoever publishes the app, and it reaches you as a package upgrade with your existing tokens and sessions intact. What is worth doing is staying current on package versions, because a subscriber sitting several versions behind at the Summer '27 deadline is the one scenario where this becomes your problem.
Q: What happens to a connected app we never migrate?
A: Support ends in Summer '27. Treating that as a date after which an unmigrated app should not be relied upon is the safe reading, and the OAuth flow retirements happening around the same period mean an old connected app is likely to have more than one thing wrong with it by then.
Q: Can we migrate and roll back if something breaks?
A: Plan as though you cannot. The migration is an automated forward process, and for a packaged app it reaches subscribers as a version upgrade, which is not a thing you can quietly undo across orgs you do not control. That is an argument for testing in a subscriber-like org first, not for delaying.
Q: Is there anything we should clean up before migrating?
A: Yes, and it is the cheapest part of the project. Connected Apps OAuth Usage shows which apps have actually authenticated. Anything on your list that has no usage and no owner is a candidate for deletion instead of migration, and deleting is faster than migrating. Do that pass first so you migrate a smaller set.
Q: Does this change how our integrations authenticate?
A: Not by itself. The app object changes; the OAuth flow your integration uses does not change because of this migration. It may need to change for a different reason, since the username-password and user-agent flows both retire on 20 February 2027, which is a separate piece of work that happens to land in the same window.
Key Takeaways
- Connected apps end in Summer '27, and external client apps are the replacement.
- The migration tool now covers packaged (1GP and 2GP) and distributed apps, which were the cases without a clean path.
- Tokens, OAuth flows and active sessions survive the package upgrade, so subscribers do not reauthorize. That removes the coordination problem, not the testing.
- Device flow apps have an earlier, fixed deadline of 30 November 2026, and they make a good pilot.
- Delete before you migrate. Connected Apps OAuth Usage will show you apps with no live consumer, and removing one is faster than converting it.
What's Next?
Open App Manager and Connected Apps OAuth Usage in production and produce two lists: apps in use, and apps that exist. The gap between them is work you can delete instead of doing.
If any of those apps use the device flow, they are your first migration and your deadline is 30 November 2026, not Summer '27. Start there, covered in the device flow restriction.
If you publish a packaged app, the useful next step is a subscriber-shaped test org running your current package version, so the upgrade path is exercised the way your customers will experience it.
For the rest of the OAuth work landing in the same window, see the username-password flow retirement and the user-agent flows retirement. For the release as a whole, see Salesforce Winter '27 Security Readiness.
Resources & References
- Salesforce Winter '27 Release Notes, Identity and Access Management, in Salesforce Help.
- Salesforce Help: Connected App to External Client App Migration, for the tool's own documentation.
- App Manager and Connected Apps OAuth Usage in Setup, for your inventory.
- The device flow restriction for the earlier deadline.
- Salesforce Winter '27 Security Readiness for the release as a whole.
Responses
Checking your session.
Loading responses.