Salesforce Lightning Sync Retirement: Dates, Options, and What to Move to 

Last reviewed September 2026. 

If your org still runs Lightning Sync, you have a deadline. Salesforce is retiring it in April 2027. And if you connect to Microsoft 365 over Exchange Web Services, you’ll lose sync well before that – October 1, 2026, when Microsoft starts switching EWS off. 

The tricky part isn’t the date. It’s that nothing warns you when sync stops. No error, no admin alert, and the Lightning Sync setup screens stay right where they are, looking perfectly healthy. 

Here’s what’s happening, which date applies to you, what to check in your org before you pick a replacement, and how the options actually compare.

What Is Salesforce Lightning Sync?

Salesforce Lightning Sync is a tool that allows you to keep your customer data in sync across multiple platforms. It’s designed to help sales and customer service teams work together more efficiently by giving them access to the same information, no matter where they are.

Technically speaking, Lightning Sync is a bidirectional synchronization service that connects Microsoft Exchange (including Outlook) or Google Workspace (Gmail) with Salesforce. It automatically syncs contacts and calendar events between these platforms, eliminating the need for manual data entry and ensuring data consistency.

Lightning Sync is available in Professional, Enterprise, Performance, Unlimited, and Developer editions with Sales Cloud, Service Cloud, and Lightning Platform licenses. Users can access it through both Salesforce Classic and Lightning Experience interfaces, as well as through the Salesforce mobile app.

Organizations typically implement Lightning Sync for several key use cases:

• Field Sales Support: Sales representatives can see their Salesforce contacts in Outlook or Gmail and access their scheduled meetings without switching applications
• Administrative Efficiency: Eliminate duplicate data entry for contacts and calendar events
• Data Quality Improvement: Maintain consistent contact information across systems
• Mobile Workforce Support: Keep mobile teams connected to CRM data regardless of location

Within the broader Salesforce ecosystem, Lightning Sync serves as a foundational integration layer that connects critical communication tools (email and calendar) with the CRM system of record. This integration is essential for maintaining a complete view of customer interactions and ensuring sales teams have the most current information available.

When Is Lightning Sync Retiring?

Salesforce withdrew Lightning Sync from new orgs back in Winter ’21 (October 2020) and moved development to Einstein Activity Capture. Existing configs kept running for five years, and migration stayed a suggestion rather than a requirement. 

What changed in 2026 came from Microsoft, not Salesforce. Microsoft is retiring Exchange Web Services, the interface Lightning Sync uses to reach Microsoft 365 mailboxes. Here’s the full timeline:

If You’re on Microsoft 365

Your date depends on how the connection authenticates. Go to Setup → Desktop Integration → Lightning Sync and check whether it’s using Exchange Web Services or Microsoft Graph. On EWS, sync stops around October 1, 2026. On Graph, you’ve got until April 2027. 

If you’re on EWS, there’s a Graph authentication upgrade right there in Lightning Sync setup. It’s a much smaller job than a migration, and it needs your Microsoft 365 admin to grant Graph consent at the tenant level. Salesforce recommended getting this done by August 2026, but that was guidance, not a cutoff. 

Worth doing even if you already know where you’re headed. It takes the October deadline off the table, which means you’re not picking a five-year integration in three weeks. 

If You’re on Gmail or Google Workspace

October doesn’t touch you. Exchange Web Services is a Microsoft interface, and its retirement has nothing to do with Google APIs. Your date is April 2027, when Lightning Sync retires everywhere. 

Google Workspace orgs are usually the least prepared, and it’s not their fault. Almost every article about this retirement is written around the October date without saying which platform it applies to, so Google admins read it and reasonably conclude it’s someone else’s problem. 

If You’ve Already Moved to Einstein Activity Capture

February 2027 is your date. Salesforce is moving EAC onto an architecture that stores email as standard Salesforce Activity records, and four legacy features retire with the old model: Activity 360 Reports, the Activities Dashboard, Activity Metrics, and Recommended Connections. 

Anything built on those – reports, dashboards, flows, forecasting – needs a path onto standard Activity reporting before that release. And watch out: plenty of migration guides still list Activity 360 Reporting as a reason to move to EAC. Follow that advice and you’ll rebuild your reporting twice in five months. 

How Did Salesforce Lightning Sync Work?

Salesforce Lightning Sync uses a two-way synchronization process to sync contacts and events. Any changes made on one platform will be automatically reflected on the other platforms.

Sync Directions and Configuration Options

Lightning Sync offers three primary synchronization configurations:

• One-way sync (Exchange/Gmail to Salesforce): Changes made in your email system flow into Salesforce, but not vice versa
• One-way sync (Salesforce to Exchange/Gmail): Changes made in Salesforce flow to your email system, but not vice versa
• Bidirectional sync: Changes made in either system automatically update in the other

For contacts, you can sync standard fields like Name, Email, Phone, and Title, plus custom fields through field mapping. For events, you can sync Date, Time, Subject, Description, and Location, with options to filter which events sync based on criteria you define.

Connection Methods

Lightning Sync offers two primary connection methods:

1. Service Account Method: Administrators configure a dedicated Exchange service account with impersonation rights, allowing centralized management of sync settings
2. OAuth Method: Individual users authenticate directly with their email provider through OAuth, giving Salesforce permission to access their data

Sync operations typically occur asynchronously every 5-15 minutes, though the exact timing can vary based on system load and the volume of changes. Initial synchronization of large datasets may take several hours to complete.

The basic setup process involves:

1. Enabling Lightning Sync in Salesforce Setup
2. Configuring connection settings for your email provider
3. Creating sync configurations for users or profiles
4. Defining sync directions and field mappings
5. Assigning users to the appropriate sync configurations

While Lightning Sync can handle both contacts and events, there are limitations on which objects can sync in each direction. For example, private events only sync when specifically enabled by an administrator, and recurring events created in Salesforce Classic don’t sync properly with Outlook.

Technical Limitations and Supported Data Types

Understanding what Lightning Sync can and cannot synchronize is crucial for setting appropriate expectations and planning your integration strategy. This is where most migration plans get scoped wrong, so it’s worth being precise. 

Lightning Sync was a bidirectional sync service connecting Microsoft Exchange or Google Workspace with Salesforce, available in Professional, Enterprise, Performance, Unlimited, and Developer editions. It ran server-side, calling EWS or Google APIs through an authorized service mailbox — which is why it needed Application Impersonation rights on Exchange or domain-wide delegation on Google Workspace. Users installed nothing. A lot of security teams refused the impersonation grant outright, and that was the feature’s biggest deployment headache. 

Sync ran every five to fifteen minutes, not in real time, and it covered one Salesforce org. Multiple orgs meant a separate setup for each. 

Here’s what it handled, and how the two main replacements compare:

Four rows there explain most of the frustration admins report with Lightning Sync: email content, attachments, meeting invitees, and custom objects. None of them ever synced. So whatever you move to will capture more than Lightning Sync did, and that’s a decision to make deliberately rather than inherit. 

Migration and Retirement Guidance

With Salesforce’s retirement of Lightning Sync, organizations need a clear migration strategy.

What Changes When You Move Off Lightning Sync

Einstein Activity Capture is Salesforce’s designated replacement, and it does capture email, which Lightning Sync never did. What it doesn’t do is keep that data where Lightning Sync kept it. 

Lightning Sync wrote contacts and events into Salesforce as standard records. Reportable through standard reports, available to standard automation, and they stayed put. EAC writes calendar events and contacts as standard records too, but captured email sits on the separate Activity Platform under a retention window unless you enable Sync Email as Salesforce Activity. That one setting decides whether your reports can see it. 

Retention is the second change. Lightning Sync data followed standard Salesforce retention. EAC applies a rolling window, and anything outside it becomes inaccessible. 

The trade is consistent: more gets captured, less can be done with it. If all you need is activity visible on a record, that’s fine. If your reporting, forecasting, or automation depends on activity data, it moves the problem rather than solving it. 

Concerns Admins Raise About Einstein Activity Capture

Five come up again and again, and each is easier to resolve before a migration than after. 

Data ownership and compliance. Because captured data sits outside your core Salesforce database, you’ll get questions about data sovereignty, GDPR obligations, and long-term access. 

Reporting. Activities captured by EAC aren’t available in standard Salesforce reports, which makes analyzing sales activity alongside your other CRM data awkward. 

Retention. Six months on standard licenses means historical activity disappears well inside a normal sales cycle for considered purchases. 

Automation. Captured data can’t trigger standard workflows, Process Builder, or flows. Anything keyed to activity gets rebuilt or abandoned. 

Customization. Fewer options for deciding which fields sync and how they map. 

Salesforce’s own comparison documentation tells you to weigh these carefully before migrating, especially if your reporting or compliance requirements are complex.

Salesforce Lightning Sync Alternative

You have several options to move forward with.

Stay on Lightning Sync Until April 2027

Not a replacement, but a sensible first move if your date is October and you’re not ready to choose. Microsoft 365 orgs on EWS move the connection to Microsoft Graph, which takes the immediate deadline away and buys you time to run the audit properly. 

The catch: no further development is coming, and you still have to migrate eventually. 

Move to Einstein Activity Capture

The bundled path, with a Migration Assistant that transfers your Lightning Sync settings into an EAC configuration. 

It works if you’re running standard objects, have a modest user count, don’t depend on deep activity history, and can live with one set of sync rules across the whole org. Those are the constraints of a bundled feature rather than defects in the current release. 

And it’s closed to you entirely if your org holds more than 100 non-Sales Cloud licenses, runs on Government Cloud, or has data residency requirements. That’s Salesforce’s own guidance, not a competitive claim. 

Move to Revenue Grid

Revenue Grid answers the five concerns above directly.  

      Reporting. Captured activity is written as native Salesforce records, so it’s available to standard reports, list views, and dashboards. 

      Automation. Because the records are native, they trigger flows and Process Builder. Nothing keyed to activity has to be rebuilt. 

      Retention. No rolling window. And historical activity can be brought in retrospectively in bulk, not just from the day you install. 

      Custom objects. Captured data maps to your custom objects, not only to Accounts, Contacts, Leads, and Opportunities. 

      Coverage. Delegate and shared calendars, recurring events, and partner and Experience Cloud license holders. 

      Data control. Private cloud and on-premises deployment with full encryption, for orgs whose residency requirements rule out the alternatives. 

What You’ll Rebuild Either Way

Whichever option you pick, budget for the same three jobs. Reports and dashboards built on Lightning Sync data or on retiring EAC features have to be rebuilt as standard Salesforce Activity reports. Flows, automations, and custom fields that reference the old structure have to be reconciled. And everything downstream needs re-validating: BI extracts, Last Activity Date logic, inactivity alerts, territory and coverage reporting. 

8 Things to Check in Your Org Before You Choose 

Run this audit before you evaluate anything, including us. It takes an afternoon, and most orgs turn up at least two surprises. 

1. Who’s still assigned. Setup → Desktop Integration → Lightning Sync lists them. You’ll often find configs covering people who left years ago, plus active users nobody knew were included. Your migration scope is this list, not your user count.
2. Which connection method. EWS or Microsoft Graph, and service account or OAuth. The first sets your deadline. The second tells you whether you’re re-authorizing or rebuilding.
3. Where your history actually lives. Synced events are standard Salesforce Event records and they stay. Captured email may sit on separate infrastructure under a retention window instead of in your core database. Get what you have, where it sits, and how long it’s kept confirmed in writing.
4. Last Activity Date dependencies. Reports, dashboards, list views, flows, inactivity alerts, territory and coverage logic, BI extracts. Anything keyed to activity fields goes quiet without erroring. This is usually the longest item on the list, and the one that bites after cutover if you skip it.
5. Shared and delegate calendars. Configured once, forgotten since. Delegate-managed calendars are common in advisory and executive-support workflows, and they break after cutover more often than not. Test one before you commit.
6. Partner and community users. Licensed differently from standard users, so confirm coverage explicitly. Parity isn’t the default.
7. Custom objects receiving activity. Lightning Sync never wrote to them. But if anything downstream expects activity on a custom object, a replacement limited to standard objects will break it.
8. Field mappings and workflow dependencies. Your custom field mappings have to be recreated in whatever comes next, and any process that uses Lightning Sync as a trigger needs identifying before you disable the sync.

Why You Won’t Get a Warning When Sync Stops 

Salesforce raises no failure notice when Lightning Sync stops, and the configuration screens stay visible in Setup afterward. The symptoms show up in a predictable order, which is handy if you’re trying to work out whether you’ve already lost sync. 

Right away, meetings booked in Outlook stop appearing on account and opportunity records. Within days, a rep opens an account to prep for a call, finds no recent activity, and assumes they’ve done something wrong. Within a week or two, last-contacted fields start drifting and automation keyed to recent activity stops firing – inactivity alerts, coverage reminders, anything conditioned on Last Activity Date. Those fail open, so nothing errors and nobody escalates. After that, the gap between calendar and CRM keeps widening until somebody rebuilds it by hand. 

Setup → Einstein Activity Capture → User Status shows each user’s assigned configuration and connection status. That’s the fastest way to see who’s actually still syncing. 

Turning Your Audit Into Requirements 

Every finding maps to something your replacement either does or doesn’t do: 

Take that right-hand column into every vendor conversation. It’s a better evaluation tool than any feature comparison written by a vendor, ours included. 

Three things worth getting in writing from whoever you pick, because these are what turn into escalations later: how long captured data is retained and where it physically sits, whether the configuration decisions you make at setup can be changed later without another migration, and what happens to sync continuity if you ever have to switch again. 

8 Mistakes That Derail Lightning Sync Migrations 

1. Planning around April 2027 without checking the connection method. A Microsoft 365 config still on EWS has an October 1, 2026 date. Check this per config, not per org.
2. Missing the retention window. EAC retention is six months on standard licenses, 24 months with a paid license. Export the history that matters before you cut over.
3. Losing custom field mappings. Inventory them before you migrate and recreate them after. They’re the single most commonly lost item.
4. Finding the Microsoft consent dependency late. Any move onto Microsoft Graph needs your Microsoft 365 admin to grant tenant-level consent. Start that conversation in week one — it’s the most common reason these projects slip.
5. Assigning a permission set without a configuration. Users need both a permission set license and assignment to an active config. One without the other looks configured and syncs nothing.
6. Assuming your automation keeps firing. Lightning Sync events triggered standard Salesforce automation. EAC data doesn’t. Confirm what your replacement triggers before you assume flows carry over.
7. Assuming you can re-enable and recover the gap. Turning capture back on after an outage doesn’t backfill the missed window beyond what retention rules allow. That gap stays in your data.
8. Skipping the sandbox. The settings migration can’t be reversed once Lightning Sync is disabled. Validate with a small user group in a sandbox, with a documented rollback plan, before you touch production.

What the Cutover Actually Involves 

For Microsoft 365 orgs there are two separate jobs: moving the sync configuration off Lightning Sync, and moving the Microsoft connection onto Microsoft Graph. Doing one without the other leaves you exposed. 

Both are one-way. Once the settings are transferred and Lightning Sync is disabled, you can’t restore the previous configuration from those settings, and the Graph connection can’t be rolled back to EWS. Which is exactly why you validate in a sandbox with a real user group against the eight checks above, rather than a smoke test that one email showed up. 

Ready to Transform Your Salesforce Lightning Sync Strategy?

As we’ve explored throughout this guide, Salesforce Lightning Sync has been a valuable tool for keeping contact and calendar data synchronized between email platforms and Salesforce. However, with its retirement for new customers and the limitations we’ve discussed, organizations need to carefully evaluate their synchronization strategy moving forward.

The key challenge many organizations face is balancing the need for comprehensive data integration with concerns about data ownership, reporting capabilities, and long-term support. Revenue Grid addresses these challenges by providing a robust alternative that stores all data directly in Salesforce while expanding capabilities beyond what Lightning Sync ever offered.

Ready to see how Revenue Grid can transform your Salesforce integration? Request a personalized demo today to experience seamless synchronization with no data limitations, advanced revenue intelligence, and enterprise-grade security.