Moving to ServiceNow Data Migration and Import Sets: Migration Considerations

Moving data into ServiceNow is a migration from one or more legacy systems, and the decisions that shape it come before any load. This page covers the source inventory, data quality and cleansing, field mapping through Import Sets, the choice between parallel running and a single cutover, validation and retention. It helps a migration lead settle those decisions.

What to Inventory in Source Systems

Before migrating data to ServiceNow, conduct a thorough assessment of the source systems. Understand the complete data landscape: which tables and fields exist in the source? How much data are we talking about in terms of record volume, database size, and data types? How old is the data and what is its age distribution? Are there known data quality issues in the source system that we need to address before or during migration?

Document source system schemas in detail. Create data dictionaries that map source fields to their data types, sizes, and business meaning. Identify which data will be migrated to ServiceNow, which will be archived in a legacy system, and which will be discarded. This decision affects the scope of migration work and the complexity of transformation logic.

Data Quality Assessment and Cleansing Strategy

Source data from legacy systems is often messy. Real-world data quality issues include: duplicate records where the same entity exists multiple times with slightly different information, missing values in important fields, inconsistent data formats (dates stored as text or numbers instead of date types), and referential integrity violations (foreign keys pointing to non-existent parent records).

Assess data quality comprehensively: count records with missing required fields, identify duplicate records using multiple matching criteria, and verify referential integrity. Develop a data cleansing strategy: some issues can be fixed automatically (standardizing date formats), while others require manual investigation and correction (resolving which of two duplicate records is authoritative).

Plan cleansing effort realistically. Do not plan to migrate dirty data and fix it after cutover; this creates ongoing operational problems. Allocate time to cleanse the most critical data before migration. Less critical data can be cleaned over time post-migration, but core business data must be clean.

Data Mapping and Transformation Logic

Map each source field to its ServiceNow equivalent. Source systems often use different names, data types, and value encodings than ServiceNow. A source system’s ticket status field might have values A (new), B (assigned), C (resolved). ServiceNow expects standard status values: new, in-progress, resolved. Create transformation rules that convert source values to ServiceNow values accurately.

Use ServiceNow Import Sets to stage data, validate it, and transform it. Import Sets provide a staging area where source data is loaded as-is. Transform rules then convert source data to ServiceNow format. This two-step approach allows validation at each stage and easy rollback if transformation logic is wrong.

Test transformation logic thoroughly. Run sample transformations and verify results match expectations. Check for edge cases: what happens if a source value does not match any transformation rule? Build error handling that catches unmapped values and alerts the migration team.

Cutover Approach: Parallel vs. Cutover

Two migration timing approaches exist. Parallel running keeps both systems operational for a defined period: source system continues processing new data, ServiceNow is populated with historical data from the source, and both systems are used simultaneously until cutover date. This approach is safer: if ServiceNow has problems, the source system is still operational. The downside is higher cost: you maintain both systems and must handle data synchronization between them during the parallel period.

Big-bang cutover switches all processing to ServiceNow at a specific time. On cutover day, the source system is taken offline, all remaining data is migrated, and ServiceNow goes live. This is faster and cheaper but riskier: if ServiceNow has critical issues, services are affected until problems are fixed.

Parallel running for a short, defined period allows validation that ServiceNow is working correctly while the source system remains available as a safety net. Define a specific cutover date and communicate it clearly to all teams.

Validation and Testing Before Cutover

Before cutover, conduct comprehensive validation. Verify record counts: the number of records in ServiceNow should match the number migrated. Audit field values: sample records randomly and verify data migrated correctly. Check references: ensure relationships between records (incident to asset, change to CMDB entry) are intact. Test workflows: verify that automation and notification workflows work with migrated data.

Identify any discrepancies and fix them before cutover. Re-run migrations if necessary. Have a rollback plan: if ServiceNow has critical issues post-cutover, can you quickly restore the source system and start over? Define rollback criteria: what problems trigger rollback?

Data Retention and Archival Planning

Historical data in source systems might not need to migrate to ServiceNow. Old records can clutter the system, slow queries, and increase storage costs. Archive old records separately: store them in a separate database, compressed archive, or long-term storage. Migrate only relevant, current data to ServiceNow. This approach keeps the new system cleaner and faster.

Define retention policies: how long should data be kept in ServiceNow? What data is archived? When is archived data deleted? Clear policies help manage system performance and compliance with data retention regulations.

Handling records that change in the legacy system after the first extract

The question that decides whether a migration is calm or chaotic is rarely how to load the bulk of the data. It is what happens to the records that change between the first extract and the moment ServiceNow becomes the system of record. A ticket is updated, an asset moves to a new owner, a contract is renewed. If the migration team loaded a snapshot taken a month earlier, those changes are either lost or must be merged by hand. Plan the delta explicitly. Decide which record classes will get a final incremental extract on cutover eve, which will be frozen in the legacy system for a short window, and which will be allowed to diverge because nobody works from them in ServiceNow.

Each class needs a stated answer. Open work in the legacy system often has to be frozen or re-extracted, because two teams editing the same open item in two systems is the failure that produces duplicate work and conflicting status. Historical reference data can often be loaded once and then left alone. The planning document should name the class, the method for the final delta, and the person who approves the freeze.

Choosing between a freeze window and a parallel period

Parallel running and big-bang cutover are the two familiar options, but many real programs sit between them. A narrow freeze on write activity for the legacy system, combined with a delta load, gives the speed of a single cutover and most of the safety of a parallel period. The trade-off is the length of the freeze and the number of people it stops.

Keeping identifiers stable across the move

Every record moved into ServiceNow needs a stable link back to its legacy identifier. Without that link, reconciliation becomes guesswork and a user who asks about a ticket they remember by the old number cannot be helped quickly. Store the legacy identifier in a dedicated field on the target table, not in a free-text note, and make it unique and indexed so lookups stay fast. Decide before the first load whether ServiceNow numbers will be reissued or whether legacy numbers will be retained as a separate reference. Reissuing is cleaner for new work; retaining the old reference is kinder to people who will be asking about history for years.

A cutover runbook worth writing in full

The migration plan often contains a line that says cutover will happen on a given day. The runbook behind that line should list the steps in order, with an owner and a stop condition for each. A workable structure is below, and it is intentionally short enough to be read aloud at the go or no-go meeting.

1. Announce the freeze and confirm that no legacy writes are still in flight.
2. Run the final incremental extract and confirm its record counts against the legacy system before loading.
3. Load the delta into a staging area, apply the same transforms as the bulk load, and reconcile the delta counts by record class.
4. Check the relationship records between the newly loaded delta and the bulk data already in ServiceNow.
5. Take the go or no-go decision on the reconciliation results, using the stop criteria written in advance.
6. Lift the freeze, switch the legacy system to read-only, and publish the new locations for users.
7. Hold the rollback path open until the first business day after cutover has passed without a critical defect.

What if the legacy system cannot be frozen at all?

Then the delta has to be captured continuously, through a change feed or repeated extracts, and reconciled more often. That is harder and more expensive, which is why it is worth asking early whether the legacy vendor or the business will actually accept a freeze window. Many objections turn out to be about one team’s reporting cycle, which can be moved.

Should historical attachments move on cutover day?

Often not. Large attachments inflate the load time and rarely matter on the first day. Many teams migrate attachment metadata and links first, then move the files in a second wave once the core records are stable.

What retention question should be settled before cutover?

Which records the business will keep in ServiceNow, which will be archived, and which will be deleted, with the rule written down for each class. Migrating everything because it is available is a common cause of a slow instance and an unclear retention position later. The retention workflow guide sets out how that decision can be kept current after the move.

The reconciliation controls guide covers the checks that the go or no-go decision depends on, and the ServiceNow migration overview gives the wider program context.

The ServiceNow data migration process, from first extract to sign-off

A ServiceNow data migration follows one order: agree scope and owners, extract from the legacy system, load into staging tables, transform into target tables, reconcile against the source, rehearse in a non-production instance, then cut over. Skipping the rehearsal or the reconciliation is where most migrations fail.

The order of loading matters as much as the order of steps. Records that others point to must exist first, otherwise reference fields arrive empty and need repair later.

Decide the coalesce fields for every transform map before the first load. A coalesce field is the value that tells the platform a staged row is an update to an existing record, not a new one. Choosing it late is the usual cause of duplicate users and duplicate CIs. Keep the legacy record number in a dedicated field so support staff can search for an old ticket by the number they remember.

Reconciliation needs more than matching row counts. Compare counts by table and by state, then pull a sample of records and read them against the source, field by field. Name one person from the business who signs the result, not only the migration lead.

Rehearse the whole sequence at least once in a sub-production instance cloned from production, with timings recorded, because the rehearsal sets the length of the cutover window. For the service side of this work see data migration and cutover with reconciliation, data migration and integration, and CMDB reconciliation and duplicate control for the configuration data.