Data Migration Approach | 10 Years | X Tool to ServiceNow

[nowGurukul_SN]

Hi Community.

There are requirements to migrate past 10 years of data from X tool to ServiceNow as part of greenfield ITSM implementation. We need to move all Open tickets, Closed history, Knowledge Articles, User Accounts, SLA Configurations, and Attachment data etc.

If you have such experience , what will you recommend a level design or migration approach ?

Your thoughts will be appreciated.

[Tanushree Maiti]

Hi @nowGurukul_SN 

This data is foundation data and source of truth data of your greenfield implementation and must be migrated first.

• user data, including roles, groups, and locations. // Use LDAP Integration for user and group , use import set /transform map in order to get rid of redundant data.
• Migrate baseline assets and CIs to populate the CMDB before migrating tickets.
• Do not migrate raw SLA logs from the old tool. Rebuild the SLA definitions natively in ServiceNow to align with your new ITSM Standard/Professional capabilities.

Open/Closed ticket: Attempting to migrate 10 years of history is a leading cause of performance degradation and technical debt 

• Closed Ticket: load closed tickets into an archived data store or a read-only custom table to reference for reporting and auditing
• Open ticket :  Migrate in an "In Progress" state directly to active ServiceNow tables. Suppress standard SLA processing and notification triggers during this load

Attachment : Use a scripted API (e.g., REST API to ServiceNow's Attachment API) to extract legacy binaries and link them to the newly imported ticket records

[Dr Atul G- LNG]

Hi @nowGurukul_SN /Gagan

As a BPC and platform owner, this is something I deal with in almost every project.

From your statement, it looks like you are planning to move transactional data from a third-party system into ServiceNow. Based on my experience, this approach is generally not recommended, and there are several reasons for that:

1. Incident Data (3rd Party to ServiceNow)

• If incidents are being resolved in a third-party tool, then bringing them into ServiceNow later and moving them to a resolved state via script is not ideal.
• Email notifications still need to be managed.
• SLA tracking will effectively restart in ServiceNow, which can impact reporting accuracy.

2. Request / RITM / Tasks

• Requests, RITMs, and associated tasks should ideally be managed within a single system.
• If a RITM is in “Waiting for Approval” externally, it will need to be re-handled in ServiceNow approval workflows.
• If multiple tasks are already completed externally, recreating them in ServiceNow adds unnecessary complexity and state mismatch issues.

3. User Data

• User data should be treated as foundational (master data).
• Instead of syncing from multiple third-party sources, it is better to integrate with a single source of truth like AD or SSO.
• This ensures clean, consistent user data in ServiceNow rather than importing fragmented external data.

4. SLA Management

• SLA data from third-party tools can technically be migrated, but it is not recommended.
• It is better to build SLAs directly in ServiceNow so they start fresh and remain accurate.
• This also ensures scheduling and pause conditions are properly maintained.

5. Knowledge Articles

• Direct import is possible, but there are limitations.
• Attachments, formatting, and relationships may not always carry over correctly.
• It is better to gradually migrate or rebuild critical knowledge content within ServiceNow.

---

Summary of my experience

In most cases, instead of lifting and shifting transactional data from third-party systems, it is better to:

• Integrate real-time data where needed
• Rebuild processes natively in ServiceNow
• Keep ServiceNow as the system of record going forward

This ensures cleaner data, better reporting, and less operational complexity in the long run.