Moving to ServiceNow AIOps: Migration Considerations

This page helps an operations team decide how to move its event handling into ServiceNow AIOps. It covers the event source inventory, incident and process mapping, data cleansing, cutover approaches, validation and rollback, team readiness, and a crosswalk of old alert rules to the new grouping.

Event Source Inventory and Assessment

Begin by documenting all monitoring tools that currently feed alerts into ServiceNow. Record the event volume from each source: does your largest source generate hundreds or tens of thousands of events daily? Note event attributes: which fields exist (severity, resource, service, component), which are consistently populated, which are sparse? Assess event quality: are duplicate events a problem? Are alerts firing for conditions that have already resolved? Do you have alert fatigue from excessive noise?

Interview your ops teams about alert handling: which events do they actually care about, which do they ignore, which would they ignore if they could? This feedback is crucial for tuning correlation and filtering during migration. Document your current event suppression rules, manual deduplication, and any custom workflows that enhance events after arrival.

Incident and Process Workflow Mapping

Map how incidents currently flow from events. How are incidents created from events today? Is this manual, automated, or a mix? What attributes are populated on incident creation, and from where? Document your incident lifecycle: standard fields, mandatory workflows, SLAs, escalation paths. Identify which automation rules depend on event attributes or incident fields.

Map your change management process similarly: which changes are triggered by events, which are scheduled, how do you handle conflicts between events and planned changes? Understand your current CMDB: what entities exist, what relationships matter, how accurate is it? AIOps depends on accurate relationships to correlate events correctly.

Identify edge cases: do you have processes for bulk event dismissal, manual grouping, override workflows? These must continue to work after migration and may require new automation in AIOps.

Data Preparation and Cleansing Strategy

Determine which historical event data must migrate. Do you need event history for auditing, for metrics, for training correlation models? ServiceNow can import historical events, but this is time-intensive. Decide: migrate only the last month, last quarter, or several years? Cleansing is harder than you think: duplicate events with slightly different attributes, incomplete attributes, events with wrong severity or status. Run a data audit first: how many events lack a resource identifier, how many have timestamps that are obviously wrong, how many are clearly test events?

Plan cleansing: will you clean during migration or migrate raw and clean later? Cleaning before is slower but safer; cleaning after is faster but risks issues. Identify which data quality issues must be fixed before cutover and which can be tolerated temporarily.

Cutover Approach and Timeline

Three main approaches exist: big-bang cutover stops the old system on a specific date and moves entirely to AIOps. This is fastest and cleanest but riskiest; if issues arise, the only option is to troubleshoot live. Parallel running maintains both systems for days or weeks, comparing results. This is safer but costly in resources and training burden. Phased cutover moves one event source or team at a time, reducing risk but extending the migration over weeks or months.

One workable approach is a hybrid: parallel running for critical sources for a set period, phased cutover for non-critical sources, and documentation frozen at cutover for knowledge consistency. Consider your risk tolerance, team capacity, and the complexity of your event flows.

Validation and Rollback Preparation

Plan validation before cutover: which scenarios must work identically to the old system? Create test cases: send a critical alert and verify it creates an incident with correct priority and owner. Send duplicate events and verify they group as expected. Send low-severity noise and verify it is suppressed or aggregated correctly. Plan the validation window: one day of parallel run or one week?

Document rollback criteria: if more than X incidents are incorrectly created, or if Y incidents fail to create, or if data loss occurs, you will roll back. Plan the actual rollback: do you keep the old system running, or restore from backup? Communicate rollback criteria to stakeholders before cutover so everyone knows what triggers a rollback decision.

Team Readiness and Support Planning

AIOps introduces new capabilities: event correlation, deduplication, enrichment, and AI-assisted alerting. Your ops team must learn new processes, new configuration, and new dashboards. Plan training before cutover, not after. Train on the new alerting paradigm: fewer, higher-quality alerts require different response behavior than high-volume, lower-quality alerts. Establish a support model for the first weeks: faster response times, escalation paths, and a dedicated point person for AIOps issues.

Identify early adopters and power users among your ops teams. Involve them in pilots and testing; they become internal advocates and help troubleshoot issues faster during rollout.

Mapping the old alert rules to the new grouping before anything moves

Migration to AIOps is often planned around data and dates, and the rules that produced the old alerts are treated as an afterthought. That is a mistake, because each old rule encoded a decision someone once made: a threshold chosen after an outage, a filter added for a noisy device, a routing exception for a team that no longer exists. When the rule disappears in the move, the decision disappears with it, and the first sign is often a responder asking why a fault that used to page them now does not. Build a crosswalk table before cutover. It should list every active alert rule, the reason it exists, the group or incident it produced, and the equivalent behavior in the new platform, or an explicit note that no equivalent is intended.

The crosswalk is also a practical way to find rules that no longer do anything. Rules in long-running estates often match events that no source has sent for a long time. Retiring those is a cleanup, but it has to be done deliberately, with the owner’s agreement, rather than during the move.

Crosswalk structure for the move

Handling incidents that are still open at cutover

Open incidents are the part of a migration that teams often leave until the end. An incident raised under the old system may be mid-handoff, awaiting a vendor, or waiting on a change, and it must not be orphaned when the grouping logic changes underneath it. Agree a rule before the cutover date. One workable rule is that incidents opened before cutover stay with their original routing and tooling until they close, and that only new events enter the new grouping. Another is to link each open incident to its nearest new group so that responders can see both views, but that approach needs a clear owner for the duplicate link.

Whichever rule is chosen, publish it to the responders in plain terms. A responder who does not know which system owns an open incident may assume the worst and act on both.

Ordered sequence for the final week before cutover

1. Freeze new alert rule changes on the old platform, except emergency fixes that are logged and copied into the crosswalk.
2. Confirm the crosswalk with each rule owner, and record the agreed decision against each row.
3. Run the open-incident rule on a sample of live incidents and confirm each one remains visible to its owner.
4. Check the event sources feeding the new platform against the source list in the crosswalk, and confirm none has been added or removed without a record.
5. Brief the on-call rota on what changes at cutover, and who to contact if a fault that used to page them does not.
6. Agree the moment the old platform stops creating new incidents, and make sure the switch is recorded in both systems.

Common surprises after cutover

• A fault that paged the team for years can stop paging, because the grouping logic treats it as a symptom of a larger event that is not itself alerting.
• Reports built on the old incident fields can break because the new platform fills some fields differently.
• Scheduled jobs that counted old events continue to run and report zero, which looks like improvement until somebody checks.
• Historic data loaded for training carries the old rule’s blind spots, so the model can learn to ignore the same faults the old rules ignored.

Questions teams ask about moving alert history and rules

Should we migrate all historical events or only recent ones?

Migrate the period needed for the reports, the audits and the training data you have decided to use, and no more. The crosswalk will tell you which rules were active over that period, and history that predates the current rule set is often misleading for training.

Can we run the old and new grouping side by side without paging people twice?

Yes, if the new grouping sends its output to a review queue rather than to paging. That lets responders compare the two views during the overlap, and it avoids the double pages that erode trust in the new platform.

What do we do with a rule whose owner has left?

Assign it to the team that owns the service it protects, and ask that team to decide. Retiring a rule nobody owns is a decision too, and it should be recorded with the same care as keeping one.

Is a phased move easier than a single cutover for rules?

It is easier to reason about, because each source and team moves on its own schedule and its crosswalk rows can be checked in isolation. The cost is a longer period when two platforms must be kept consistent, so the crosswalk must be shared and current.

For the event side of this move, the event management migration considerations guide is the companion read, and the CMDB migration considerations guide is the place to check the configuration data that correlation relies on. The data migration, reconciliation and cutover page covers how a cutover is evidenced.