Keeping SLA alerts working through a sales tool switch
What happens to SLA alerts during a sales tool migration, the four places they break first and the cutover plan that keeps response times honest.
ON THIS PAGE · 7 SECTIONS
- Why SLA alerts break first when you switch sales tools
- What an SLA alert actually is and what depends on it
- The four places SLA alerts live in your stack
- A cutover plan that keeps alerts live
- Worked example: SLA alerts through a routing tool switch
- What to check in the first 30 days after cutover
- Questions about SLA alerts and sales tool migrations
THE SHORT VERSION
- An SLA alert almost never migrates with the rest of your data. It has to be rebuilt by hand in the new tool, trigger, timer and notification channel together, before the old system goes dark.
- Every SLA alert lives in one of four places: the routing or assignment engine, the CRM workflow, the sequencing tool or the notification layer itself. A tool switch usually touches two or three of these at once.
- Run the old and new alert chains in parallel for at least one full SLA cycle, not just one lead, before you trust the new one and switch the old one off.
- Test the tightest SLA first. If your 5-minute tier-1 alert fires correctly on day one of cutover, the slower tiers almost always follow.
- Name an owner for the alert system itself before cutover, someone who gets paged when the alert breaks, not just when a lead breaches it.
Keeping SLA alerts working through a sales tool migration means rebuilding each alert's trigger, timer and notification channel by hand in the new system before you turn the old one off, then running both side by side until a full SLA cycle has passed clean. The data behind an SLA alert usually migrates fine. The alert itself rarely does, because it is not a record, it is a small piece of logic sitting between a timestamp and a Slack message. That logic is specific to the tool that built it.
Why SLA alerts break first when you switch sales tools
Most migration plans treat SLA alerts as part of the CRM export and move on. That is the mistake. A contact record, a deal, a company all map cleanly from one system to another because they are data. An SLA alert is a chain of three separate things: a trigger (a lead assigned, a reply logged), a timer counting against a deadline and a notification action that fires when the timer runs out. Each link in that chain is built differently in every tool. None of it comes along in a CSV.
Switch your CRM and the workflow that started the timer is gone. Switch your sequencing tool and the task that counted as "first touch" no longer exists in the new system's data model. Switch your routing tool and the escalation rule that paged a manager at 80% of the deadline has to be rewritten from the trigger up. Teams that get this right treat the alert chain as its own migration project, separate from the data migration, with its own test plan and its own cutover date. RevOps Co-op's CRM migration checklist, built with Syncari and Carabiner Group, flags the same gap at a wider scale: automations and workflows do not map one for one between platforms and have to be rebuilt and tested by hand, not assumed to carry over (RevOps Co-op, 2026).
The cost of getting it wrong is not abstract. LeanData's case data shows what a working alert chain is worth: SUSE cut its speed to lead by 70% in a single quarter after building priority-based SLA alerts, bringing response time on high-intent leads down to 1.3 hours with 100% SLA attainment. Zendesk cut response time by 82%, from 45 minutes to 8, while cutting manual assignment work by 45% (LeanData, 2026). Those gains took months to build. A badly handled tool switch can erase them in a weekend, with nobody noticing until a quarter of leads show a 2-day average response time on the new system's own dashboard.
What an SLA alert actually is and what depends on it
An SLA alert is an automated warning that fires when a time-bound commitment, usually a response time to a lead or a reply, is about to be missed or has already been missed. The three things it needs to work are a clean trigger event, a timer that survives system restarts and ownership changes and a notification channel someone actually watches. Take away any one of the three and the alert either never fires or fires too late to matter. What depends on it is bigger than one missed lead. Lead routing decisions, manager escalation paths and the weekly numbers on your outbound KPI scorecard all assume the SLA alert is telling the truth. If the alert goes quiet during a migration, the first thing that breaks is not a lead. It is the trust your team has in the dashboard that is supposed to tell them whether outbound is working at all.
The four places SLA alerts live in your stack
Before you touch a migration plan, map where every current alert actually lives. Most teams find alerts spread across more places than they expected, each with a different rebuild path.
| Where it lives | What triggers it | What breaks in a switch |
|---|---|---|
| Routing or assignment engine | A lead or reply is assigned to a rep | Priority tiers and round robin state do not carry over; escalation rules have to be rebuilt tier by tier |
| CRM workflow or flow | A field changes or a record is created | One tool's workflow logic has no one-to-one equivalent in another; field names and triggers both change |
| Sequencing or engagement tool | A task goes overdue or a step is skipped | "First touch" and "overdue task" are defined differently in every tool, so the timer starts at a different moment |
| Notification layer (Slack, email, SMS) | Any of the above fires its action | API keys, webhook URLs and channel IDs all have to be reauthorized and repointed |
A tool switch rarely hits just one row. Most migrations touch two or three at once, which is why alerts go quiet without anyone changing them on purpose.
In Salesforce, for example, a Slack alert is not a generic integration. It runs as a Send Notification action inside Flow Builder, tied to a specific custom notification type and a record ID. It also needs the Send Custom Notifications permission to fire outside normal user context (Salesforce, Send Notification Action). None of that configuration exists in a HubSpot workflow or an Outreach sequence rule. If your new system is not Salesforce, that entire action has to be rebuilt from nothing, not reconnected.
A cutover plan that keeps alerts live
Treat the alert chain as a separate workstream from the data migration, with its own checklist and its own go/no-go decision.
- Inventory every current alert. List each one with its trigger, timer length, escalation path and notification channel. Most teams find three to five more than they remembered once they check Slack channel admin and workflow lists side by side.
- Rank by tightness. A 5-minute tier-1 alert needs to work on hour one of cutover. A weekly stale-deal alert can wait a day without costing you a lead.
- Rebuild the tightest alert first, end to end. Trigger, timer and notification, tested with a real lead or a test record that behaves like one, not a manual flag.
- Run old and new in parallel. Keep the old alert chain live and watching the same activity while the new one runs underneath it, so you have a second alarm if the new one misses.
- Compare a full cycle of alerts, not one. One correct alert proves the trigger works. A full cycle, a week for daily SLAs, a quarter for monthly ones, proves the timer survives weekends, timezone changes and a rep going on leave.
- Cut the old chain only after the comparison is clean. Keep the old system's alert config documented even after shutdown, since the next migration will ask the same questions.
THE USUAL WAY
- Assume the SLA rule migrates with the CRM export.
- Test the new system with a handful of manual clicks, not live leads.
- Switch off the old alerts the day the new CRM goes live.
THE SYSTEM WAY
- Rebuild every alert's trigger, timer and channel as its own task, checked off by name.
- Run both alert chains against the same real activity for a full SLA cycle.
- Name a person who owns the alert system itself, not just the leads it watches.
A migration moves your data. It does not move the logic watching that data.
Worked example: SLA alerts through a routing tool switch
As an example, picture a 12-rep team moving its lead routing from a spreadsheet-based round robin inside its old sequencing tool into a dedicated routing tool connected to a new CRM. The team had one tier-1 SLA, a 5-minute Slack alert for inbound demo requests, plus a tier-2 SLA, a 4-hour alert for marketing qualified leads.
On cutover day, the team ran both alert chains against the same 40 inbound leads for one week. The old chain, still pointed at the live form, fired 38 of 40 tier-1 alerts inside 5 minutes. The new chain, still being tuned, fired 31 of 40, with the 7 misses traced to a round robin assignment that skipped reps marked "away" in the old tool but not yet synced to the new one's status field. That gap took two days to find and a single field mapping fix to close. Only after a second week, with the new chain matching the old one lead for lead, did the team retire the spreadsheet-based router. Skipping that second week, which is the tempting shortcut once the first week looks clean, is exactly how a status field mismatch like this one goes unnoticed for a month instead of two days.
FROM THE YARD
The alert that breaks first is never the one you tested. We have watched teams rebuild and triple-check a tier-1 SLA alert, get it working perfectly, then lose a tier-3 "stale deal" alert nobody thought to inventory because it lived in a Zapier automation one person set up two years ago and never documented. Before cutover, ask every manager and rep individually what they get paged for. The answers rarely match the list IT has on file.
What to check in the first 30 days after cutover
A clean parallel-run week does not mean the job is done. Three things tend to surface only after real volume and real edge cases hit the new system:
- Timezone handling once reps or leads outside the home timezone start a timer, since "5 minutes" means something different at 11pm local than at 11am.
- What happens when an alert's recipient is out sick or has left the team and whether the escalation path falls back to a manager automatically or goes nowhere.
- Whether the SLA numbers in your reporting layer match what the alert system itself recorded, which is the same reconciliation check that matters after any CRM migration touching live pipeline.
Our outbound system build treats alerting as part of the sending and routing layer, not an afterthought bolted on once the CRM is live, which is the main reason it survives a tool switch instead of quietly going dark for a month.
Questions about SLA alerts and sales tool migrations
Do SLA alerts migrate automatically with a CRM export?
No. A CRM export moves records, fields and history. An SLA alert is a trigger, a timer and a notification action built inside that specific tool's automation engine. None of the three carries over in a data export, so each alert has to be rebuilt by hand in the destination system.
How long should you run old and new SLA alerts in parallel?
At least one full SLA cycle, not one lead. For a daily response-time SLA that means a full week, so the comparison covers weekends, a rep out of office and normal volume swings rather than one clean test case.
Which SLA alert should you rebuild and test first?
The tightest one. A 5-minute tier-1 alert exposes timing and routing problems immediately, while a weekly or monthly alert can hide a broken trigger for weeks before anyone notices a miss.
What is the most common cause of a broken SLA alert after a migration?
A status or field mismatch between the old and new system, most often around rep availability or lead ownership, that makes the new routing logic skip or misassign a record the old system would have caught.
Who should own SLA alerts once the migration is finished?
One named person, usually in RevOps or sales operations, who is responsible for the alert system itself, not just the leads it watches. Without a named owner, a silent alert failure can run for months before a manager notices response times have slipped.
Sources: LeanData, Speed to Lead, 2026, Salesforce, Send Notification Action, RevOps Co-op, CRM Migration Checklist, 2026