Salesforce connected apps end-of-support: plan the move to external client apps

Salesforce has confirmed that connected apps will reach end-of-support in Summer ’27. Existing connected apps will keep working, but Salesforce says it will no longer fix bugs or provide support for the integrations and authorisation flows that use them. The company’s strategic replacement is the external client app framework.

That distinction matters. End-of-support is not a stated switch-off date, and it does not mean every established integration will fail when Summer ’27 arrives. It does mean that leaving an important connection on the legacy framework becomes a more deliberate operational risk. Platform owners now have enough notice to identify what they run, decide what genuinely needs migration and avoid turning a manageable portfolio into a last-minute programme.

What Salesforce has confirmed

Salesforce’s Winter ’27 release notes say the release update is available from Winter ’27 and is enforced for production instances in Summer ’27. At enforcement, connected apps continue to operate, but the framework is no longer supported. Salesforce recommends migrating connected apps to external client apps.

This follows an earlier change. From Spring ’26, creation of new connected apps was disabled by default, including creation through APIs such as Metadata API. Salesforce directs new integration designs towards external client apps, although existing connected apps and packaged apps can continue to operate.

These are confirmed platform directions. The order in which an organisation migrates its own applications, the change windows it chooses and the risk it accepts are governance decisions. Salesforce has not described Summer ’27 end-of-support as a universal outage deadline.

Why end-of-support still deserves attention

A stable integration can run quietly for years. That can make continued operation look like evidence that no action is needed. After end-of-support, however, a new platform defect, authorisation-flow issue or compatibility problem may have fewer practical routes to resolution. The risk is greatest where the connection supports revenue, service delivery, finance, identity or regulatory reporting and nobody can explain its design.

There is also a change-cost issue. A hurried migration often combines framework change, credential change, permission redesign and supplier coordination in one window. Starting with discovery allows teams to move a connection when its application is already being upgraded, its contract is being renewed or its authentication is being modernised.

The Ostrelis interpretation is therefore proportionate: do not manufacture urgency, but do not treat continued execution as a support strategy.

Build an inventory that supports decisions

Begin with Setup records for connected apps, connected app OAuth usage and installed packages. Reconcile them with login and event evidence, integration-user lists, middleware schedules, secrets registers, vendor catalogues and source repositories. A short log sample is not enough: quarterly jobs, recovery scripts and year-end processes may be absent from recent activity.

For each app, record:

• business purpose, service owner and technical owner;
• production and non-production orgs;
• whether the app is local, packaged, distributed internally or supplier-controlled;
• OAuth or other authorisation flows, callback locations and relevant scopes;
• integration users, permission model and data accessible;
• last confirmed use, execution frequency and business criticality;
• supplier position, target framework and proposed migration window;
• test evidence, rollback route and support documentation.

Keep unknown ownership or unknown usage visible. Do not delete an app simply because nobody immediately recognises its name. Equally, do not plan a migration for a demonstrably obsolete connection when controlled removal is the safer outcome.

Separate three kinds of work

Locally owned apps are usually the clearest place to start. The organisation can inspect the configuration and code, create the external client app, test the authorisation flow and coordinate token handling. These migrations can establish reusable standards for naming, ownership, scopes, credential rotation and monitoring.

Packaged or supplier-controlled apps need a vendor-led answer. Ask for the supported product version, migration method, customer actions, reauthorisation requirements and timetable. Salesforce’s Winter ’27 notes describe tooling for migrating eligible packaged and distributed connected apps. They also state that customer OAuth flows, tokens and active sessions remain valid through a package upgrade. That can reduce disruption, but it is not a substitute for the supplier’s tested instructions.

Unowned or obsolete apps need investigation and controlled retirement. Capture evidence, contact likely owners, test the consequence in a safe environment where possible, and block or remove access through an approved change. Reducing unused connections may provide more immediate security value than mechanically recreating every legacy app.

Use migration to improve the control model

Rebuilding the same broad access on a new framework is a missed opportunity. Review whether the app still needs its OAuth scopes and whether its run-as user still needs every object and field permission. Confirm how client secrets or certificates are stored, rotated and monitored. Separate public and confidential clients where the architecture calls for it, and avoid mixing unrelated callback patterns.

Salesforce’s AppExchange guidance emphasises PKCE, refresh-token rotation, least-privilege scopes and avoiding older flows such as device, implicit and username-password patterns. Some requirements are specifically directed at partner solutions, so they should not be presented as identical mandates for every private app. They are nevertheless useful design evidence when setting an internal standard.

Do not conflate the framework migration with Salesforce’s separate flow retirements. An app may need both a move to an external client app and a change away from a retiring OAuth flow. Record these as distinct requirements so that testing proves each one.

Test continuity, not just authentication

A successful token response shows only that authentication worked once. Test the complete business transaction, scheduled repeats, token refresh, revocation, credential rotation, permission failures and recovery. Verify monitoring on both sides of the connection and make sure logs are useful without exposing tokens or secrets.

Where Salesforce’s migration tooling preserves sessions and tokens, confirm that behaviour in the relevant packaging and deployment path. Check consumer keys, policies, scopes and administrative ownership after migration rather than assuming every setting transferred as intended.

For a critical integration, define measurable acceptance criteria: expected records processed, acceptable latency, reconciliation totals, alert delivery and the period of stable operation before the old configuration can be retired.

A practical plan towards Summer ’27

1. Now: name an accountable platform owner, export the connected-app inventory and classify obvious local, packaged and obsolete candidates.
2. Next: reconcile usage evidence, expose unknown owners and obtain written migration positions from important suppliers.
3. Before committing dates: choose representative low-risk and high-risk apps, prove the migration path in non-production and document a repeatable runbook.
4. Through the release cycle: prioritise business-critical, poorly supported and already-changing applications; track exceptions and accepted risks explicitly.
5. After each migration: verify permissions, monitoring, credential lifecycle and documentation, then retire legacy configuration when evidence supports it.

This sequencing is Ostrelis operational guidance rather than a Salesforce-mandated timetable. Organisations with many packaged applications, limited test environments or unclear integration ownership should allow more discovery time.

The Ostrelis view

The most valuable outcome is not a count of external client apps. It is a governed portfolio in which every connection has a purpose, an accountable owner, proportionate access, a supported authentication design and a known recovery route.

Summer ’27 end-of-support provides a useful planning boundary without requiring indiscriminate haste. Teams that start with evidence can remove dead connections, coordinate suppliers early and migrate critical integrations in controlled windows.

Ostrelis can help organisations inventory Salesforce integrations, assess connected-app risk, coordinate suppliers and manage tested migration work. See our Salesforce data and integration services, managed Salesforce support and approach and experience.