Moving to ServiceNow Service Level Management: Migration Considerations
This guide helps a service owner plan a move to ServiceNow Service Level Management without losing the meaning of existing targets. It covers what history to carry across and what to leave behind, how to handle records that are open at cutover, and how to run old and new measures side by side.
Understanding Your Current SLA Framework
Before implementing Service Level Management in ServiceNow, understand what SLA framework currently exists. Do you have written SLAs, and if so, are they being tracked and measured? How are SLA breaches identified and handled? Are SLAs defined by service, by incident severity, by customer tier or by some other dimension?
Collect current SLA data: what targets are defined, what is current compliance rate, what are the most frequently breached SLAs and why? This data helps you design SLAs in ServiceNow that are realistic and meaningful for your organization.
Identify tools or systems currently tracking SLAs. Some organizations use spreadsheets; others use specialized monitoring tools. Assess what data is available about current SLA performance and whether this data can be migrated to ServiceNow or if you will start fresh with new measurements.
Designing SLAs in ServiceNow
ServiceNow’s Service Level Management module supports multiple SLA definitions, each with conditions and escalation procedures. Design SLAs around your most important service commitments. Start with a small number of clearly defined SLAs (for example, critical incidents, standard incidents, low-priority requests) rather than trying to create dozens of granular SLA rules.
For each SLA, define conditions (which incidents or requests trigger this SLA), response and resolution targets and escalation procedures. Use historical incident data to calibrate targets. If incidents of type X currently take 8 hours to resolve on average, setting a 2-hour SLA is unrealistic without operational changes.
Consider whether SLAs should be based on business hours or calendar hours. Many organizations define faster response times during business hours (8 am to 6 pm) and acknowledge longer response times outside business hours or on weekends. ServiceNow can model this through business calendars and SLA definitions.
Testing SLA Definitions
Before rolling out SLAs, test them against historical incident data. Load past incidents into ServiceNow and run SLA calculations to see what compliance would have been. This reveals whether SLA targets are realistic and calibrated appropriately.
Test SLA calculation logic: do the escalation procedures fire at the right times, do SLA clocks pause and resume appropriately for customer-waiting status, are breaches calculated correctly? Testing prevents surprises after rollout when teams discover SLAs are not calculating as intended.
Building SLA Dashboards and Reporting
Plan how SLA compliance will be monitored and reported. Design dashboards that show real-time SLA status (which incidents are at risk of breach, which SLAs are being met). Create reports that show historical SLA compliance by incident type, team, and time period.
Dashboards should clearly show incidents that are approaching SLA breach so teams can escalate and act. Color coding (green = on track, yellow = approaching breach, red = breached) makes status immediately apparent.
Change Management and Rollout
Implement SLAs in phases. Start with critical incident SLAs and ensure teams understand the targets and escalation procedures. Once the team is comfortable with those SLAs, introduce additional SLA types. This phased approach prevents overwhelming teams with too many new policies simultaneously.
Communicate SLA targets to all stakeholders: incident managers, technical teams, customers and leadership. Explain why each SLA target was chosen and what it means for team operations. Explain escalation procedures and what teams should expect when incidents are at risk of breaching SLAs.
Monitor SLA performance closely during the first weeks after implementation. Expect some initial struggle as teams adjust to new targets. Use performance data to refine SLAs if they prove to be unrealistic or if organizational changes enable more aggressive targets.
Common SLA Implementation Mistakes
Setting SLA targets that are too aggressive leads to chronic breaches and team demoralization. Use historical data to inform targets, and set targets that are achievable with current team capacity.
Implementing too many SLAs at once overwhelms teams and complicates monitoring. Start with 3 to 5 core SLA categories and add more as teams mature and processes are optimized.
Failing to communicate SLAs to teams and customers leads to confusion about expectations. Transparency about SLA targets and what they mean is essential for successful implementation.
Not escalating SLA breaches effectively. If teams know an incident is breaching SLA but nothing happens, the SLA loses credibility. Ensure escalation procedures are triggered automatically and followed up by management.
Post-Implementation Optimization
After SLAs are live, monitor compliance metrics and work to improve. If certain SLA categories are consistently breached, investigate root causes. Are incidents complex and genuinely require longer resolution? Is team capacity insufficient? Are processes inefficient? Address the root cause rather than just extending the SLA.
Gather feedback from teams about whether SLA targets are fair and achievable. Adjust SLAs as needed based on experience and changing business priorities. Annual SLA review should become a standing practice where targets are re-evaluated and refined based on performance data and business needs.
Deciding what history comes across and what stays behind
Migration to a new service level tool forces a decision that is easy to postpone: which of the old measurements are worth carrying forward. Moving every historical record is often expensive and rarely useful, because the old clocks were probably calculated differently from the new ones. Moving none of it leaves the first year of reporting without a baseline. The workable middle ground is to sort each data item into one of three groups before any load begins.
| Data item | Approach | Reason |
|---|---|---|
| Closed records with raise, assign and close dates | Migrate, then recalculate against the new definitions for a sample | Dates survive the move; the clock logic does not, so the sample shows the size of the difference |
| Historical breach flags from the old tool | Keep as a separate archive with its own label | Those flags reflect the old rules and must not be mixed into new compliance figures |
| Targets agreed with customers in the old tool | Rebuild as new definitions, then reconcile against the signed wording | A target that exists only in the old configuration is a commitment nobody can check |
| Dashboards and reports built for the old tool | Retire unless a current owner asks for them | Many old reports measure things the new definitions no longer track |
The decision for each group should be recorded with an owner. A data item without an owner tends to be migrated by default and then cannot be explained when a customer asks about it.
Handling records that are open at cutover
Records that are open when the switch happens are often the highest-risk items in the whole migration. Each one carries an elapsed time that the old tool was measuring, and a careless load can either restart that time or drop it. Decide, for each open record, whether its clock continues from the original raise date or starts again from cutover. The choice should follow the agreed customer wording, not the convenience of the load script. Where the old tool’s elapsed time is not carried across, record the elapsed figure as a note on the new record so that anyone reviewing a breach later can see the full history.
Consider holding back the cutover for the highest-priority services until their open records have closed naturally. A short freeze costs less than a disputed breach that nobody can reconstruct.
Running the old and new measures side by side
A parallel run lets the team see how the new definitions behave on real work before anyone relies on them. It works best when the old and new measures are calculated on the same records each day and the differences are reviewed rather than explained away. Expect the differences to be concentrated in the cases that matter most: records that were paused in one tool and not the other, and records that crossed a holiday or a weekend.
- Choose a short parallel period and a fixed set of services that represent the spread of priorities and calendars.
- Calculate each day’s compliance under both sets of definitions and list every record where the outcome differs.
- For each difference, identify whether the old or the new definition reflects what was agreed with the customer.
- Correct the new definition where it was wrong, and document the rule that explains each remaining difference.
- Agree the end of the parallel run in writing, with the person who owns the service level signing it off.
- Retire the old calculation only after the agreed end date, and keep the final comparison as part of the migration record.
Keeping reporting continuous through the first period
The first reporting period after cutover is where trust is won or lost. Leadership will ask why a figure changed, and the honest answer is often that the definition changed. Prepare a short bridge that shows the old figure, the effect of each definition change and the new figure for the same period. Publishing the bridge with the first report saves a long argument later, and it makes clear which movements came from the platform and which came from the service.
Schedule the first two reporting periods so they avoid collisions with the business’s own review calendar. A cutover that lands just before a quarter-end review leaves no room to correct anything before the numbers are used.
Should old breach history be migrated at all?
Only where it is needed for a decision or a contractual question that the team expects to face. Otherwise keep it in a labeled archive that is searchable but not included in the new compliance figures. Mixing the two is a common reason for a trend that cannot be explained.
What if the old tool used different clocks for the same priority?
Then the old and new figures will not match, and they should not be forced to. Write down the difference, show its size on the bridge report and agree with the customer which definition will apply going forward. Recalculating history to match the new definition hides the change rather than explaining it.
Can a customer keep the old targets for a transition period?
Yes, if the agreement says so in writing. A transition clause that names the old and new targets, the date each applies and the reporting used for both is clear. A verbal agreement to be relaxed about the change can be remembered differently by each side.
Who should approve the cutover?
The service owner should approve it, with the customer representative informed of the date and the effect on reporting. Technical sign-off confirms that the data loaded correctly; it does not confirm that the commitments are right, which is a separate decision.
For readiness checks before the switch, see the service transition readiness article, and the testing checklist for this topic sets out the test layers for this topic.
Related guides: Data Migration & Integration.
Migrating SLA policies to ServiceNow means rebuilding each definition, not copying it
You can migrate SLA policies to ServiceNow, but in practice you rebuild them as SLA definitions and migrate only the supporting data. Targets, start and stop conditions, schedules and pause rules are re-created, then checked against the wording agreed with the customer and tested on a sample of real records.
A policy in an old tool is usually a bundle of five separate decisions.
| Part of the old policy | Where it typically lives in ServiceNow | What to check |
|---|---|---|
| Target time | The duration on an SLA definition, with response and resolution usually built as separate definitions | The figure and the unit against the signed wording |
| What starts the clock | The start condition | Records that are reclassified or reassigned after they are raised |
| When the clock pauses | The pause condition, typically tied to a customer-waiting state | That the same states pause the clock in both tools |
| Working hours and holidays | The schedule attached to the definition | Holiday lists and time zones, which rarely match |
| Warnings and breach actions | The notifications or flow attached to the definition | A named owner for every warning |
Work through the policies one contract at a time rather than one tool setting at a time. List every policy, note which customers or services it covers, rebuild it, and test it before moving on. Policies for one customer are the easiest to lose, because they often live in a spreadsheet rather than in the old configuration.
The Service Level Management guides explain how definitions are structured, and the migration section covers the wider move. If records need loading, data migration and import sets describes the loading route.
Can SLA policies be migrated with an automatic import?
The records can be imported, but the logic cannot be trusted to follow them. Clock rules depend on conditions, schedules and pause states that must be rebuilt and tested by hand.
Can ServiceNow track response and resolution separately?
Yes. Most teams build one SLA definition for the response target and another for the resolution target, each with its own start, pause and stop conditions, so a record can meet one and breach the other.
How do I handle a customer with its own targets?
Build a separate definition limited to that customer, typically through a condition on the company or a contract record.
Frequently asked questions
What should we do if our team consistently misses SLA targets?
First, investigate the root cause: Are targets unrealistic? Is team capacity insufficient? Are processes inefficient? If targets are unrealistic, adjust them based on historical performance. If capacity is the problem, plan staffing increases or resource reallocation. If processes are inefficient, identify bottlenecks and improve them. Avoiding the root cause by simply extending SLAs without addressing why teams are struggling will not improve service quality.
Should we escalate every SLA breach, or only significant ones?
Escalate systematically based on incident impact. Critical incident breaches warrant immediate escalation to senior management. Standard incident breaches should be escalated to the shift manager or incident coordinator. Low-priority breaches should be tracked and reported but may not need immediate escalation. The key is consistency: define escalation procedures clearly and follow them every time.
How do we handle SLA targets when work is truly blocked waiting for customer information?
Most SLA frameworks allow for SLA pausing when work is blocked by customer response or third-party dependencies. When pausing an SLA, document the pause clearly and notify the customer. When the customer responds or the blocker is removed, resume the SLA clock with the remaining time for resolution. Transparent pausing prevents disputes about whether SLAs are being fairly applied.
Related guides
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us