Designing Smarter Data Migration for ServiceNow

[Gaurav Bajaj]

Often times, when a customer is starting their journey on ServiceNow platform, we come across a situation where in new customers decides to migrate their legacy transactional data into ServiceNow. This decision may stem from regulatory obligations to preserve historical data or to ensure operational continuity, particularly when there is a plan to decommission the legacy service management system.

I’m going to discuss a few design principles to ensure we meet this requirement while preserving the integrity of the ServiceNow platform

• No migration at all

The most efficient data migration strategy might be... no migration.

ServiceNow is the system of action for the whole enterprise and should only store data to support services across business functions. For example - Bring the minimum required personal details or beneficiary information from HCM tools to ServiceNow when you plan to provide services like adding/updating beneficiaries, updating personal details.

Migrating historical transaction data does not offer any value-added benefits to support the services; rather, it merely consumes storage capacity and negatively affects performance(not to forget the nightmare of data transformation exercise to map old field information into ServiceNow schema). This is certainly not a situation in which customers would wish to find themselves.

Therefore, best approach is to advocate about problems of migrating historical data into ServiceNow while also striving to understand the underlying requirements.

Ask a few question like - Are your users actively accessing this old data, or is it more of a "just in case" scenario?

Does the regulation suggests that legacy data should be preserved for X years or should be accessible as well?

This will help you identify a viable solution.

• Store Legacy Data in a Low-Cost Database

 A simple and practical approach is to offload legacy data into a low-cost storage system while still ensuring it remains accessible if required.

• Export historical data to affordable storage options such as Azure SQL, AWS RDS, Google Cloud SQL, or even flat-file databases.
• Secure the data with appropriate encryption, retention policies, and role-based access controls to meet compliance standards.
• Retrieve data on demand through lightweight integrations or reporting tools, without impacting the production instance.

•  Limited migration into ServiceNow

At times, the company requires a complete migration. If it's unavoidable, try to minimize the complications and impact on platform health, data quality and performance.

• Focus only on primary ticket data (short description, category, resolution, etc.)
• Skip on migrating attachment, email logs, ticket history which are top consumer of ServiceNow storage data.
• Do not transfer active tickets and recommend that the customer prepare for a transition period to resolve tickets in the legacy tool prior to migration.
• Do not create new fields to store legacy custom field information in ServiceNow, This will unnecessarily add technical debt and customization into ServiceNow without a business value. If needed, you can merge all such information in name values pairs, and plan to add in comments or work notes entries.
• You can also plan to archive this data when it comes to ServiceNow to avoid performance overhead on data access .

Data migration isn't merely a technical job—it's a design choice that impacts your performance, user experience, and expenses in ServiceNow. Don't approach it as a simple "lift-and-shift." Rather, question every assumption regarding what should be migrated and create a strategy that caters to your future, not just your history.