Lightning Sync to Einstein Activity Capture: a 4-sprint migration playbook for mid-market RevOps

Most senior Salesforce admins have August 2026 marked on their calendar. That's the wrong date to plan around.

It is one of three deadlines colliding in 2026, and the date itself is the easiest part. The harder problem is the set of irreversible decisions you make during the migration. Salesforce ships them as defaults, the rollback path doesn't exist, and the documentation tells you what to do but not what you'll lose.

We've sequenced this work for clients in four sprints. Here's the playbook.

The three deadlines, not one

Salesforce's release notes give you the headline date. Lightning Sync with Office 365 + EWS basic auth retires in August 2026. Move to Einstein Activity Capture (EAC) by then, or sync stops.

Two more clocks are running in parallel.

The first is Microsoft's. EWS in Exchange Online begins phased disablement in October 2026, with full retirement in 2027. (See the Microsoft Learn EWS deprecation page for the current timeline.) If your EAC instance is still authenticated against EWS, even modern-auth EWS, you have a second migration to do, this time to Microsoft Graph.

The second is a Salesforce-side reporting deprecation. Per the Summer '26 release notes, Activity 360 Reporting, Activity Metrics, and the Activities Dashboard all retire in that release. If your forecasts and pipeline-progression dashboards run on those objects, they stop working whether or not you've migrated off Lightning Sync.

The compound effect is the part that catches teams out. An admin who moves to EAC in July 2026 and considers the project closed will find dashboards broken in Summer '26, and EAC sync degrading in October when Microsoft starts the EWS shutdown. The August 2026 date solves the first deadline. It doesn't touch the other two.

What doesn't migrate cleanly

Salesforce's framing is that EAC has the same functionality as Lightning Sync, plus more. In practice, EAC is a different data model with a different storage layer and a different feature surface. A few specifics to know before you begin.

Activity data lives on AWS, not in Salesforce

EAC stores captured emails and events on Amazon Web Services. What you see in the Activity Timeline is a virtual record. It isn't a true Task or Event. It isn't visible to Apex, triggers, Flows, validation rules, or standard Salesforce reporting. Default retention is 6 months on the standard license, 24 months on the paid tier. After that, the data is purged.

Recurring events do not sync

Lightning Sync handled them. EAC does not. If your customer-success org runs weekly QBR series, recurring 1:1s, or renewal cadences against Outlook or Google Calendar, those meetings will never appear on an Activity Timeline. Engagement metrics built on Event records will silently undercount.

Custom field mapping is gone

Lightning Sync supported custom-field mapping between Exchange or Google and Salesforce Event and Contact records. EAC supports standard fields only. Any custom-field-driven reporting or automation built on synced activity over the last five years stops working. Silently. With no error.

Shield Platform Encryption isn't supported

If you run Shield Platform Encryption on activity-related fields (email body, subject, attendees), EAC will not function under those configurations. We have seen this discovered late in regulated-industry migrations, after security review has already started.

The "Sync Email as Salesforce Activity" toggle is a one-way door with a 180-day cap

Salesforce released this feature in Summer '25 to address the "EAC isn't native records" complaint. It writes captured emails as native Task and EmailMessage records going forward. It is the single most consequential decision in this migration, so it gets its own treatment in Sprint 2 below. The headline is that enabling it is irreversible. Historical backfill is hard-capped at 180 days, and any email older than 180 days from the toggle date stays as a virtual AWS record forever and gets purged at the 24-month retention boundary.

Internal-domain email is not associated to records

Emails between users on the same domain are filtered out by default. Internal handoffs that cc the customer, alias addresses like support@ or sales@ routed through your tenant, internal CSM-to-AE handoffs. None of that gets captured against the Account by default.

These aren't edge cases. They are the shape of EAC. The migration plan has to start with what you'll lose, not what you'll gain.

The 4-sprint playbook

Here's the sequence we run for mid-market clients, from kickoff to Lightning Sync deactivation, in 8 to 12 weeks of elapsed time.

Sprint 1: discovery and dependency audit

The goal of Sprint 1 is to know what breaks before you touch a connector.

Inventory every report, dashboard, Flow, validation rule, Apex class, and trigger that references Event or Task custom fields. These are your silent-failure surface. List every recurring event series your sales and CS teams actually use. Decide whether you'll move them to single-instance occurrences, to third-party calendar tooling, or accept the visibility loss.

Audit Shield Platform Encryption coverage. If activity fields are encrypted, escalate to security and compliance now, not in week 6. Confirm your Microsoft auth state. If you're on EWS basic or EWS modern, you have a Microsoft Graph reconfiguration ahead. If you're already on Graph, Sprint 2 is shorter. Pull a pipeline-engagement baseline from your current Activity 360 dashboards. You'll need this to validate Sprint 4.

Sprint 1 exits with a written list of irreversible decisions, a list of dashboards that need rebuilding, and a list of users in the pilot cohort.

Sprint 2: Microsoft Graph reconfiguration and pilot

The goal of Sprint 2 is to prove the connector works against Graph, not EWS, before any cutover.

EAC against Microsoft Graph is a separate setup from EWS. It uses either an org-level OAuth flow or a service account with impersonation rights. Both require Microsoft 365 admin coordination. Plan two weeks for the Microsoft side alone.

Stand up the Graph connector in a sandbox or against a 5- to 10-user pilot cohort. Enable EAC contact sync with conservative settings. Limit Contact creation to contacts already linked to accounts owned by the rep. The default behavior creates new Contact records on every matched email participant. When that default interacts with existing Contact dedup rules, assignment rules, or insert-time Flows, you get duplicate-Contact volume that takes weeks to clean up. Trailblazer Community threads on EAC contact sync regularly surface five-figure duplicate counts after enablement. The conservative-defaults pattern is what we use to avoid that outcome.

Then enable "Sync Email as Salesforce Activity" on the pilot cohort only. This is the one-way door from the previous section. Enabling it on a user is irreversible. Historical backfill is hard-capped at 180 days, and email older than that stays AWS-virtual forever and is purged at the 24-month retention boundary. Enable it only after the contact-sync configuration is hardened. Confirm the writes look correct in the Activity Timeline and on Account and Opportunity records before turning it on for the rest of the org.

Sprint 2 exits with a working Graph connector, a hardened contact-sync configuration, and pilot users running Sync-as-Activity for two weeks of real traffic.

Sprint 3: dashboard rebuild and org-wide hardening

The goal of Sprint 3 is to replace what Activity 360 was doing for you.

Rebuild pipeline-engagement dashboards on top of the new Sync-as-Activity Task and EmailMessage records. These are native Salesforce records and behave like any other report source. Stand up monitoring on EAC sync status. The default sync-failure surface is buried in Setup, so we add a scheduled report that surfaces sync errors to the admin team daily.

For any custom-field reporting that broke in Sprint 1's audit, rebuild the field on the EmailMessage or Task object, populate it via Flow on insert, and rewrite the report. EAC's virtual records won't help here. Only the native Task and EmailMessage path will.

Run a duplicate-Contact reconciliation job against any Contacts created during pilot. Use a real merge tool, not a manual sweep.

Sprint 3 exits with the new reporting layer live and the pilot cohort fully productive.

Sprint 4: cutover and Lightning Sync deactivation

The goal of Sprint 4 is to deactivate Lightning Sync with the org-wide migration validated and reporting continuity confirmed.

Migrate the rest of the user base to EAC against Graph. Use a phased rollout. Sales first, then CS, then any internal users. Confirm the pipeline-engagement baseline from Sprint 1 is being met or exceeded by the new dashboards. If it isn't, investigate before deactivating Lightning Sync.

Deactivate Lightning Sync. Watch sync error rates for two weeks. Document the irreversibles you triggered (Sync-as-Activity toggle, contact-sync defaults, AWS retention setting) in your org's runbook so the next admin doesn't re-trigger them by accident.

At cutover, Lightning Sync is off, EAC is running on Graph, the reporting layer is rebuilt, and activity-engagement metrics are continuous from before to after the migration.

Where most migrations go wrong

The pattern we see most often. A team moves the connector, doesn't audit dependencies, and discovers in Q3 that a forecast model has been running on stale data for two quarters. The dashboards still rendered. The reports still returned numbers. The numbers were just wrong.

The deadline isn't the hard part. The irreversibles are. Sequence the work so you make those decisions deliberately, in a pilot, with monitoring, not in a Friday afternoon Setup session in late August.

If you want this sequence run for your org, our Lightning Sync to EAC migration engagement covers the four sprints above end-to-end. Sprint 1 dependency audit (Event/Task custom field inventory, Shield Encryption check, Microsoft auth state confirmation, pipeline-engagement baseline). Sprint 2 Graph reconfiguration plus pilot cohort. Sprint 3 dashboard rebuild and sync monitoring. Sprint 4 phased cutover and Lightning Sync deactivation. Engagements run 8 to 12 weeks elapsed. The Sprint 1 audit alone is a fixed-scope two-week deliverable that exits with a written list of irreversibles, dashboards-to-rebuild, and pilot-cohort users. It is usable on its own if you'd rather run Sprints 2 to 4 in-house.

For related reading, our post on why Salesforce reports can't always answer "why" covers the reporting layer your Sprint 3 rebuild has to land on. The Spring '26 Einstein Conversation Insights walkthrough explains how EAC data flows into the AI features layered on top of activity capture.

Related articles

Picking Your Post-CPQ Path for Mid-Market RevOps: Revenue Cloud, Composable, or Wrap-with-Agents

Salesforce CPQ went end-of-sale. Choose between Revenue Cloud, composable, and wrap-with-Agents using a four-axis framework built for mid-market RevOps.

Read Article →

Who Has Access to Your AI Agent? A Governance Framework for Agentforce in Production

A six-layer governance framework for Agentforce in production: who runs the agent, what it can touch, and why permission set hygiene comes first.

Read Article →