Migrating from ITSM to CSM: A Step-by-Step Guide

As ServiceNow has evolved over the last 20 years, many customers have built custom solutions on the platform before dedicated products existed. One common scenario is organizations using ITSM to support their external customers before the introduction of Customer Service Management (CSM).

While ITSM is designed for internal IT support, some businesses repurposed it to serve external customers, leading to technical debt, complex customizations, and scalability challenges. With CSM now widely adopted, many organizations are eager to migrate from ITSM to CSM to streamline operations, improve user experience, and reduce maintenance overhead.

Having implemented five of these migrations, I want to share my best practices and recommendations for a successful transition from ITSM to CSM.

Common ITSM Customizations for External Customers

Before CSM existed, companies often adapted ITSM by:

• Storing external customers in the User [sys_user] table, often with a custom flag or role to differentiate them.
• Adjusting Access Controls (ACLs) and Before Query Business Rules to restrict Incident data visibility for external users.
• Implementing custom ACLs to prevent external users from accessing ITSM-related records and functionalities.
• Using the Company [core_company] table for B2B use cases or creating a custom Customer table (extended from sys_user).

These workarounds introduce complexity and require manual maintenance, making upgrades difficult. Migrating to CSM provides a cleaner, more scalable, and out-of-the-box approach.

Key Considerations Before Migrating to CSM

Migrating to CSM is an opportunity to redesign the architecture for long-term success. Before starting, organizations should evaluate:

1. Business Units & Organizational Structure
   • How should case types be structured?
   • What business processes need to be redefined?
2. Selecting the Right Data Model
   • PSDS, Retail, Financial Services (FSO), etc.
   • Does the business primarily serve B2B or B2C customers?

Migration Plan Considerations

1. Customer & Account Migration

• B2B Migration: Move external customers from User [sys_user] to Contact [customer_contact].
• B2C Migration: Move external customers to the Consumer [csm_consumer] table.
• Company Migration: Migrate Companies [core_company] to Accounts [customer_account].

2. Case Management Setup

• Move all SLA definitions from Incident to the Case table.
• Update Notifications to trigger from Case instead of Incident.
• Migrate Inbound Actions from Incident to Case.
• Ensure customers are added to the appropriate groups for role inheritance.

3. Portal Transition & Redirects

• If using /sp (Service Portal) for external support, switch to /csm (Customer Service Portal) or /csp (Customer Support Portal) for a dedicated experience.
• Set up URL redirects to ensure customers attempting to access historical incidents are redirected to the new Case Management interface.
• Ensure that email links from historical notifications pointing to ITSM records correctly redirect customers to the appropriate pages post-migration.
• If historical records are being archived instead of migrated, provide an alternative lookup tool for customers to retrieve past case information.

4. Data Migration Strategy

• Start fresh rather than migrating historical Incident records to Case.
• If historical data must be retained, store legacy fields as text in Work Notes or Description instead of adding unnecessary fields to the Case table.

5. Migrating Reports & Performance Analytics Dashboards

• Identify all reports that currently pull data from the Incident table.
• Update regular reports to pull data from the Case table instead of Incident.
• Migrate Performance Analytics (PA) dashboards and indicators to reference Case data.
• Update interactive filters that were designed for ITSM reports to reflect Case attributes.

6. Reviewing & Replacing Custom Logic

• Customers often have custom scripts, workflows, and form logic in ITSM - use this opportunity to eliminate redundant customizations and adopt OOB functionality.
• Many organizations are surprised to find that their custom ITSM configurations are now out-of-the-box (OOB) features in CSM.

Additional Considerations

Scheduled Jobs & Automation

• Review and migrate legacy scheduled jobs that reference the Incident table.
• Convert legacy workflows to Flow Designer where applicable.

Reverting Old Customizations

After migrating to CSM, cleaning up ITSM is essential to ensure:

• Data security: Prevent data leakage by removing old ACLs
• Business Rules, Client Scripts, UI Policies, and Notifications related to ITSM.
• Maintainability: Deactivate (but do not delete) unused columns to preserve historical reference.
• Archive old Incident data using Data Archive Rules instead of keeping them in production tables.

Final Thoughts

Migrating from ITSM to CSM improves scalability, maintainability, and customer experience. It is also an opportunity to reduce technical debt, eliminate unnecessary customizations, and build a more sustainable architecture.

While the investment may seem significant, it will pay off through easier upgrades, lower costs, and improved efficiency.