ServiceNow Data Migration and Import Sets Best Practices

Stage Data Transformation in Separate Import Sets Before Committing to Target Tables

Data migration from legacy systems often requires transformation: mapping fields, reformatting values, resolving duplicates, validating data quality. Using Import Sets in ServiceNow allows you to stage incoming data in temporary tables before loading it into production tables. Create an import set for each data source (users, assets, incidents) and load raw data there first. In a separate step, transform the data: map legacy field names to ServiceNow field names, convert date formats, resolve duplicate records. Use Import Set transformation maps (ISTM) to execute these transformations, or use flows if transformations are complex. By staging transformations separately, you can inspect and validate the transformed data before it affects production records. If transformation produces unexpected results, you can adjust the transformation and retry without having corrupted production data.

Validate Data Quality Before and After Transformation

Source system data is often messier than you expect: missing required fields, incorrect values, duplicates. Before attempting to load data into ServiceNow, validate the source data. Check that required fields are populated, that date formats are consistent, that numeric fields contain numbers. Count records and compare source and target to identify where records were lost or duplicated. After transformation, validate again: spot-check a sample of transformed records, verify that critical fields were mapped correctly, confirm that data quality improved (fewer missing values). Create validation reports and review them before committing to production. If validation fails, fix the source data or the transformation and retry rather than proceeding with bad data.

Use Staged Rollout to Catch Issues Early Without Full Impact

Loading millions of records into production at once is risky; if something goes wrong, you have a full system corruption to clean up. Instead, load data in stages: first load high-value or critical records, verify they are correct, and then load additional batches. For user migration, load a pilot group first: administrators and early adopters who can provide feedback and tolerate minor issues. Verify the pilot group can work normally with migrated data before loading all users. For asset migration, load critical assets first (production servers, network infrastructure) and less critical assets later. Staged rollout allows you to catch data quality issues with a subset of data and fix them before rolling out to everyone.

Build Record Mapping and Verify No Duplicate or Lost Records

When migrating data, you must track which source records were migrated to which target records. Build a mapping table that links legacy system IDs to ServiceNow record IDs. Use this mapping to resolve references between records: if a legacy system has a database that refers to a user by legacy ID, and you migrate both, the reference must be updated to point to the ServiceNow user. Count records in source and target and verify they match. If a source record did not migrate (perhaps because required fields were missing), identify it and decide whether to fix the source and retry or manually create the record in ServiceNow. Build reports on migration completeness: how many records were attempted, how many succeeded, how many had errors. Use these reports to identify systematic issues you need to fix.

Plan Rollback Procedures and Maintain Cutover Flexibility

If a data migration discovers problems after you have migrated most or all data, you may need to roll back to pre-migration state. Plan how you will revert: do you have a database backup from before migration, can you delete migrated records, or do you need to run migration in reverse? Test your rollback procedure before executing migration so you know how long it takes and what systems are affected. Some migrations allow parallel running: you operate both legacy and new systems simultaneously during a transition period while users and integrations migrate. This approach reduces risk because you can revert to legacy systems if migration encounters problems. Plan how long you will run in parallel and when you will shut down the legacy system.

Document Data Lineage and Maintain Migration Audit Trail

After migration completes, you need to understand where data came from and when it was migrated. Document data lineage: which fields in ServiceNow correspond to which fields in the legacy system, how transformation rules worked, which batches of data were loaded and when. Maintain audit logs showing when data was created or modified during migration so you can trace specific records. If a user later questions data accuracy (why is their old address still in the system, or why is their start date wrong), you can refer to the migration documentation to explain. Keep legacy system data available for a period after migration so you can refer back to it if questions arise. Archive or delete legacy system data only after you are confident the migration is complete and correct.

Make every load repeatable before you make it fast

A load that works once is not yet a practice. The question that separates a reliable migration from a lucky one is whether the same file, run again, produces the same result. Repeatability matters because most migrations are re-run at least once, whether because a source extract was corrected, a map was adjusted after review, or a reject queue was cleared and the remaining rows were reloaded. If a second run behaves differently from the first, the team loses the ability to say which result is correct.

The practices below are the ones that protect repeatability. None of them is exotic. Each one removes a way in which two runs of the same input can diverge, and each one leaves a record that someone can inspect later.

A pre-load gate that a load must pass

A gate is a short list of conditions that must be true before a load starts. It does not replace judgment, but it stops a rushed load from going ahead because someone was confident. The gate should be written down, agreed with the data owner, and checked by a person who did not build the load.

1. The extract is frozen, and its row count and control total match the figures the legacy owner has signed.
2. The transform map version to be used is the one that passed the dry run, and no edits have been made since.
3. Reference tables that the load depends on are loaded and reconciled.
4. The coalesce key has been tested for duplicates against the target table.
5. The rollback step has been rehearsed, and the person who would run it is available for the load window.

Keeping the dry run honest

A dry run is only useful when it is close to the live procedure. Teams often rehearse with a smaller file, a different user, or a copy of the environment that differs in its reference data, and then find the live run behaves differently. Run the rehearsal with the same extract, the same map version and the same staging table where the environment allows it. If a difference is unavoidable, such as a smaller volume for speed, name it on the gate and test the scaling separately.

Questions about repeatable migrations

How many dry runs are enough?

There is no universal number. Keep rehearsing until a run produces the same row outcomes as the previous one, and until the reject queue for the rehearsal contains only items with a named owner and an agreed action. A run that surprises the team is a reason for another rehearsal, not for a faster schedule.

What do we do with records a re-run should have updated but did not?

Compare the source identifier on the record with the one in the extract. A missing match often means the source changed identifiers, or the coalesce key is not the one the team believed it was. Investigate before loading again, because a second load on top of an unexplained mismatch multiplies the problem.

Is it safe to keep the map under version control outside the platform?

It is safe as long as the version that runs in the platform is recorded on every load and matches the controlled copy. The risk is not the location of the file but the gap between what is controlled and what is running, so check that gap at each gate.

Next step

A repeatable load depends on the mapping design and the governance around it. Each gate should leave the evidence that the testing and acceptance checklist asks for. The reconciliation controls behind each gate are described in the migration reconciliation controls post, and the reconciliation and cutover service page describes the evidence a cutover should carry.