Moving to ServiceNow Now Assist for ITSM: Migration Considerations

Now Assist for ITSM is generative AI assistance for IT service management teams. It can suggest incident categories, recommend knowledge articles, draft incident summaries and help with change impact analysis. Its results depend on the data behind it, so check incident quality, knowledge currency and team readiness before you roll it out in phases.

Now Assist Capabilities and Prerequisites

Now Assist for ITSM uses large language models and generative AI to assist your IT Service Management team. It can suggest incident categorisation based on the incident description and historical patterns, recommend related knowledge articles that might solve the user’s issue, draft incident summaries from ticket content, or assist with change impact analysis by reading change descriptions and identifying potentially affected systems. Before migrating to Now Assist, assess your readiness: do you have clean incident data with properly categorised records that the AI can learn from? Do you have a knowledge base with quality, current articles that are actually useful? Do you have documented change processes that Now Assist can learn patterns from? Poor data quality limits AI effectiveness significantly.

Assessment and Readiness

Begin with a readiness assessment. Audit your incident data quality: what percentage of incidents have descriptions (required for AI analysis)? What percentage are properly categorised? Poor data quality limits Now Assist’s effectiveness. Audit your knowledge base: how current is it? How complete? Now Assist works best when it has good training data.

Assess user readiness: are your teams comfortable with AI-assisted workflows? Do they understand that AI suggestions are not guaranteed correct and require human review? Some teams embrace AI assistance; others distrust automated suggestions. Cultural readiness matters as much as technical readiness.

Data Preparation

Clean your incident history before activating Now Assist. Remove test incidents, fix mis-categorisations, and ensure incident descriptions are meaningful. Train your team to enter complete incident information going forward—Now Assist learns from quality data, so data quality standards are critical.

Ensure your knowledge base is current. If Now Assist recommends an article but the article is outdated or incorrect, you have harmed user trust in the system. Archive or remove outdated knowledge before activating Now Assist.

Phased Rollout Strategy

Start with a pilot team: perhaps your tier-1 support staff who handle high volume. Let them use Now Assist features for a limited scope—for example, suggesting knowledge articles but not automatically categorising incidents. Monitor usage and satisfaction. If the pilot is successful, expand to tier-2, then expand the scope of capabilities. If the pilot surfaces issues, refine configuration before broader rollout.

Training and Change Management

Train users on Now Assist features and expectations. Show them how to use suggestions, when to trust them, when to override them. Emphasise that AI is an assistant, not a replacement for human judgment. For example, when Now Assist suggests a category, the support agent should verify it makes sense for this particular incident.

Communicate the change to your users and stakeholders. How will Now Assist improve their experience? Will incidents be resolved faster? Will categorisation be more accurate? What is the business value? Communication that focuses on benefits encourages adoption.

Monitoring and Tuning

After deployment, monitor Now Assist suggestions and accuracy. How often are Now Assist’s categorisation suggestions correct? How often do users override suggestions? If accuracy is low, the model may need tuning or retraining. If users override suggestions consistently, they may not trust the AI or the feature may not be configured for their specific use cases.

Change Management for AI Features

Deploying Now Assist is a change to your operational procedures. Support staff learn to trust or question suggestions. Users may see categorisations changing over time as the model improves. Communicate these changes clearly. Explain what Now Assist does and does not do. Show examples of how it helps. Address concerns: “Will AI replace my job?” Answer honestly: no, it will change your job. You will spend less time on routine categorisation and more time on complex problems and customer interactions.

Feedback Loops for Model Improvement

The best models are built with continuous feedback. When support staff correct an AI suggestion, that correction should feed back into model retraining. When a suggestion is unhelpful, that negative feedback guides model improvement. Build feedback mechanisms into your processes. Make it easy for users to rate suggestions or flag problems. Collect this feedback systematically and use it to improve the model over time. The more feedback you collect, the better your model becomes.

Expected Benefits from Now Assist

Clear benefits justify adoption. Reduced time on routine tasks: if Now Assist handles categorisation, support staff focus on resolution. Improved data quality: automated suggestions are more consistent than manual entry. Faster user resolution: if Now Assist surfaces relevant knowledge immediately, users get answers faster. These benefits may take time to materialise as your team adapts to the new way of working.

Integration with Existing Processes

Now Assist should enhance your existing processes, not replace them. Incident management workflows, approval processes, and escalation procedures should remain intact. Now Assist suggestions should appear alongside your existing tools and processes, helping humans decide faster, not replacing human decision-making.

Separating what moves from what must be rebuilt

When a service desk moves to the assistant, the temptation is to treat the move as a copy: take the records, the articles and the routing rules across, and switch the feature on. The assistant does not read the past the way a person does. It reads the data it can reach, through the rules and access you give it, and some of what agents rely on in the old tool, such as informal naming conventions and tacit routing knowledge, does not survive a move unless someone writes it down. Start by listing every element of the current service desk and marking it as moves unchanged, moves with cleaning, or must be rebuilt.

A cutover runbook that protects the queue

Run the move as a sequence with a stop point at each step. The aim is that the service desk can always return to the state it was in before the step began.

1. Freeze the category and knowledge changes for the cutover window, and tell the teams that normally make them that the freeze is in force.
2. Run the historical-data selection and document the excluded records before anything is copied.
3. Switch on the assistant for a small internal group only, and check that suggestions appear with the correct access for each test account.
4. Compare the first week of suggestions against a manual sample, and agree a rollback trigger before the group widens.
5. Widen the audience in stages, keeping the old routing available until the staged groups have run a full cycle without a rollback.
6. Retire the old routing rules only after the new ones have a written sign-off, and keep the old definitions in an archive for reference.

Decisions to make before any data moves

Three decisions shape the rest of the work. The first is whether the migration is a fresh start or a continuation: a fresh start means the assistant learns only from the new scheme, which is cleaner but gives it less history. The second is who owns the knowledge base during the move, since articles that change mid-migration make the test results impossible to interpret. The third is what happens to in-flight work at cutover, where an open record created under the old rules needs a clear owner rather than a silent handover.

Signs that the move has gone wrong

Watch for agents who stop reading suggestions in the first week, for a sudden rise in records routed to a catch-all queue, and for suggestions that cite articles the team has already retired. Each of these points to a specific element in the table above, so the response is to return to that element rather than to adjust the assistant broadly.

Can we migrate the assistant without moving historical records?

Yes. It is a legitimate choice when the historical data is poor or the scheme is changing fundamentally. The trade-off is slower learning in the early weeks, which the rollout plan should expect.

Should the old tool stay live during the move?

For a period, yes, as the fallback for routing and as the reference for old records. Set an end date for read-only access, and put that date in the cutover plan so it is not extended by default.

How do we test suggestions before agents see them?

Run a set of representative records through the assistant with test accounts at each access level, and have supervisors score the results against a checklist written in advance.

What if a category was never used consistently?

Merge it into the nearest defensible category during the mapping, and record the merge. Leaving an inconsistent category in place teaches the assistant that the inconsistency is normal.

Who signs off the cutover?

The service desk lead should sign off the operational side, and the platform owner should sign off the access and data side. A single sign-off by one party tends to miss the other half of the risk.

Next step

For the data side of the plan, the guide on integration patterns covers the common inbound and outbound patterns, and the note on data migration validation and cutover covers the checks that support the runbook.