Common ServiceNow Data Migration and Import Sets Mistakes and How to Avoid Them

Underestimating Data Quality Assessment

Data migration succeeds or fails based on data quality. If source data is incomplete, inconsistent, or corrupted, migration produces garbage-in-garbage-out results. Many migration projects discover serious data quality problems mid-migration when it is too late to change approach or fix the source. The root cause is insufficient upfront data quality assessment.

Before committing to a migration approach, audit the source data in detail. Create a data quality report that documents record counts, completeness, consistency, and known issues. For example, how many customer records are missing addresses? How many phone numbers are in invalid formats? Are there duplicate records? Use this assessment to understand the true scope of data cleanup needed. If data quality is poor, factor data cleanup costs into your migration plan and timeline. Sometimes the best approach is to clean source data before migration, even if it takes longer, rather than to migrate dirty data and spend weeks cleaning after migration.

Incomplete or Incorrect Field Mapping

Field mapping is the translation layer between source and ServiceNow. If mapping is incomplete or incorrect, data ends up in the wrong fields or is lost. A critical field might be mapped to the wrong target field, so the data arrives but is in the wrong place and causes downstream processing errors.

Document field mapping explicitly: for each source field, specify the target field and the transformation rule (if any). Involve business stakeholders in mapping decisions so that you map data to fields that matter for their use cases. Test mapping with a sample of real data before running the full migration; verify that transformed data is correct and useful. Handle unmapped fields explicitly: either map them to a target field or document why they are not needed. Create a mapping audit trail so you can explain to stakeholders why each field was mapped or excluded.

Inadequate Testing and Validation

Data migration testing is often minimal because testing is time-consuming and it is tempting to skip validation to meet migration deadlines. A pilot migration is run but not thoroughly validated; discrepancies are noted but not investigated; the team proceeds with full migration hoping problems will be rare. This approach is risky: small discrepancies in pilot can become large problems when multiplied across millions of records.

Develop a comprehensive migration validation plan: automated checks verify data arrived and is in the correct fields, spot checks manually verify record accuracy, completeness checks verify all expected records were migrated, and consistency checks verify data relationships are intact. Run validation on a pilot subset (a small sample of records) and fix issues before full migration. Document validation results in a formal report. Do not proceed with full migration until pilot validation passes and stakeholders have reviewed and approved the results.

Performance Issues and Long Migration Windows

Large data migrations can consume significant computing resources and take hours or days to complete. If migration performance is not planned for, the migration window extends to unacceptable lengths and business is disrupted. Large loads compete with normal users for instance resources, and delays multiply.

Test migration performance on a non-production environment that mimics production size and complexity. Calculate how long migration will take, when it can start and finish within a maintenance window, and whether batch sizes need adjustment. Use parallel processing where available to speed migration. Consider staging migration in phases: critical data first (customer and contact records), then transactional data (orders, tickets), then supporting data (configurations, reference data). This allows phased business validation and reduces the total downtime for any single phase.

Inadequate Data Cleanup and Deduplication

Source systems often contain duplicate or obsolete records that should not be migrated. A customer might exist in the system multiple times under slightly different names; an order might have been canceled but never deleted; a configuration record might be superseded but both versions are in the system. If duplicates are migrated, data quality in ServiceNow suffers from day one.

Before migration, identify and clean up source data. Check the source file for duplicate keys before loading, because the coalesce setting only protects the target table. For each duplicate, decide: keep the most recent record, merge records, or delete obsolete records. Document deduplication decisions so you can explain to business stakeholders why some source records were not migrated. For migrated records, implement a consolidation process where you identify near-duplicates in ServiceNow (similar names or IDs) and merge them during the first weeks after migration when business is still learning the system.

No Rollback Plan and Point-in-Time Recovery

If migration is successful, you declare victory and move forward. But if something goes wrong after migration (data integrity issues discovered days later, business processes fail because data was not migrated correctly), you need a way to roll back. If you do not have a backup or rollback plan, you may have to spend weeks manually fixing records or even recreate the data from scratch.

Before starting migration, take a backup of all production systems and data. Keep the backup available for a retention period agreed before migration, long enough to recover if critical issues are discovered. Document rollback procedures: how quickly can you restore the backup? How do you notify stakeholders? How do you handle work that occurred after migration but before rollback? Communicate rollback procedures to leadership so they understand the safety net. After that retention period, if migration is stable and no significant issues have been discovered, you can delete the backup and declare the project complete.

Mistakes that show up first in the import row results

Many teams learn they have a problem only when a dashboard looks wrong a week after go-live. The earlier signal is already sitting in the import row results, if someone reads them. A load can report the same number of rows as the source and still have written empty values over good ones, matched the wrong existing records, or silently skipped every row that pointed at a reference value that did not exist. The mistakes below leave exactly these traces, and each one has a check that can be run before the next load starts.

Why the coalesce key deserves more attention than the field map

The coalesce key decides whether an incoming row becomes a new record or an update to an existing one. Teams often spend days on the field map and five minutes on this choice, which reverses the risk. A good key is a value the legacy system guarantees to be unique and stable over time, usually its own primary identifier, stored in a dedicated target field that users never edit. A name, an email address or a free-text description fails both tests. Names change, addresses are reused, and descriptions are rewritten, so a re-run quietly creates a second copy of a record that already exists.

Store the legacy identifier on every migrated record from the first load. It costs a column, and it turns every later question about a record into a simple lookup. It also makes a partial re-run safe, because the same source row always resolves to the same target record.

A diagnostic order for a load that looks wrong

When a load produces results that do not match expectations, the instinct is to change the map straight away. That often makes the picture worse, because the original evidence is overwritten. Work through the steps in order instead.

1. Stop any further loads from the same file so that the evidence stays stable.
2. Export the row results grouped by outcome, so that inserted, updated, ignored and errored rows can each be counted.
3. Compare those counts with the numbers the program expected, and write down every gap before explaining it.
4. Pick a handful of rows from each outcome and compare them field by field with the source record.
5. Only then change the map or the script, and rerun the corrected logic into a scratch table or a copy of the environment before touching the live tables.

Mistakes that are easy to make and expensive to undo

Two problems deserve their own attention because they rarely appear in row results. The first is treating an incomplete export as a complete one. If a legacy extract stops early and the file is loaded as if it were the full population, the missing rows do not fail. Nobody notices them until a user asks for a record that should exist. Compare the source row count from the extract job with the count inside the legacy system before loading, and keep both numbers on the load record.

The second is overwriting fields that carry history. Created-by values, original opened dates and legacy status history are easy to remap by accident when a transform copies a block of fields. Protect those fields in the map with an explicit rule, and check them in the sample review, because a record that looks correct on its face can still have lost the information an auditor will ask about.

Questions raised after a bad first load

Can I delete the rows a bad load created?

Possibly, but treat it as a change in its own right rather than a cleanup step. Identify the rows through the import set and the coalesce values rather than through creation dates, which can overlap with genuine records. Test the selection on a sample, get the platform owner to approve the scoped deletion, and confirm that the deletion can be reversed if the selection was wrong.

Should the team fix the map or the source file first?

Fix the source when the source is wrong, such as duplicate keys or malformed dates, and fix the map when the source is right but the interpretation is not. The row sample often shows which one it is quickly. Fixing the map to hide a source problem simply moves the defect into the target.

How do I tell a platform fault from a source fault?

Take one failing row and trace it through three points: the value in the legacy system, the value in the staging row, and the value in the target record. If the first two match and the third does not, the fault is in the transform or the platform. If the first and second differ, the problem is in the extract. This three-point trace takes a few minutes and often settles disputes between the migration team and the source owner.

Next step

If a load has already produced results you cannot explain, a short review of the row outcomes with someone who has run imports before is a useful first step. How the maps themselves are shaped is covered in the design post on transform maps. Checks that would have caught these earlier are in the testing and acceptance checklist.

Import set tables, transform map events and row states: the names behind a migration

A ServiceNow import loads source rows into a staging table, then a transform map moves them into the target table. The staging table extends sys_import_set_row, each load creates an import set record, and the transform typically records per row whether it was inserted, updated, ignored, skipped or errored. Most migration mistakes show up in those row results.

These are common out-of-box names; check them on your own instance and release, because labels and menu paths differ between releases. Knowing which record holds which part of a load shortens every diagnosis, and it makes the implementation roadmap easier to follow step by step.

A transform map can also run script at four common points: onStart, onBefore, onAfter and onComplete. Inside onBefore the variables source, target, map and log are usually available, and setting ignore to true drops the current row. The broader set of loading options is laid out on the data migration and import sets page.

Example (hypothetical): a team loads a spreadsheet of office locations. It marks the field holding the unique location code as the coalesce field, runs the load on a non-production instance, and opens the results of the run to compare the inserted, updated, ignored, skipped and error counts against the number of rows in the file. The production load is scheduled only after those counts make sense.

What does the Coalesce checkbox do on a field map?

Coalesce makes a field map part of the match key. When a target record already matches on the coalesce fields, the row updates it; when none matches, the row inserts a new record. Marking several fields means a record must match on all of them to count as the same one.

Where do I see which rows failed?

Open the import set record and the results of the transform run, then filter the staging rows by their state. Error rows normally carry a comment that names the cause. Menu labels differ by release, so look under the System Import Sets application.

Can a transform script skip a single row?

Yes. In an onBefore script, setting ignore to true stops that row being written to the target table, which suits rows that break a rule a field map cannot express. Write the reason to the log so the skip can be explained to the data owner later.