ServiceNow Data Cleanup and Reconciliation

Data cleanup and reconciliation is the process of finding problems in ServiceNow records, fixing them and setting controls so they do not return. It typically spans the CMDB and business tables such as incident, change, request and asset records. The page covers who needs this work and when to fix the rules instead of the records.

What Data Cleanup and Reconciliation Involves

Data in ServiceNow degrades over time. Users create duplicate configuration items in the CMDB. Historical records accumulate in incident and change tables. Fields are populated inconsistently or left empty. When data quality falls below acceptable thresholds, downstream decisions suffer: discovery maps fail because the CMDB contains conflicting entries, reporting is unreliable because many records lack key fields, and automation fails when it encounters malformed data.

Data cleanup and reconciliation is the process of identifying these problems systematically, fixing them, and establishing controls to prevent recurrence. It typically spans the CMDB and business-critical tables such as incident, change, request, and asset records.

Who Needs This Service

Organizations at these stages typically commission data cleanup engagements. A team is rolling out a new ServiceNow module and finds that the foundation data is unusable. A large incident queue reveals that many tickets have no assigned asset or are assigned to incorrect ones. A decommissioning effort discovers that configuration items in the CMDB have not been reviewed or updated in years. Reporting shows that key fields have high null rates, making analysis impossible. Discovery integration fails because the CMDB contains duplicates and conflicting attributes.

Cleanup becomes urgent when it blocks other initiatives. If you cannot trust your asset database, you cannot plan cloud migrations accurately. If your incident records have missing impact information, your SLA reporting is meaningless.

What a Cleanup Engagement Delivers

A data cleanup engagement produces several outcomes. An audit report identifies the scope of the problem by table: the total number of duplicates, the percentage of records with missing key fields, the age of unreviewed data, and anomalies or constraint violations. A remediation plan specifies which records will be merged, archived, or corrected, the sequence of corrections, dependencies, and the effort required. The engagement then executes the plan: merging duplicate configuration items, backfilling missing fields from secondary sources, removing or archiving stale records, and correcting known errors.

As corrections proceed, the service includes data validation to confirm that fixes are correct and that the system is left in a consistent state. Testing verifies that integrations downstream (asset management, change management, incident management) operate correctly with the corrected data. Documentation records the corrections made so that the organization understands what was changed and why.

Engagement Approach: Discovery, Assessment, and Execution

Engagements typically unfold in three phases. Discovery involves understanding the business context, which tables are most critical, what integrations depend on data quality, and what constraints or standards the organization follows. The team runs queries to profile the data: identifying patterns of duplication, measuring null rates, finding values that violate business rules, and spotting records that have not been touched in years.

Assessment produces the findings. The audit report presents the magnitude of each problem. Cost and effort are estimated for different remediation strategies. Some duplicates can be merged automatically; others require human judgment. Some missing data can be backfilled from external sources; other gaps require decisions about correction or archival.

Execution follows an agreed plan. The team creates test environments so that corrections can be validated before touching production. Corrections are applied systematically, with validation at each step. Once production is updated, reporting and integrations are tested to confirm that downstream systems work correctly. The team documents the work and, where possible, identifies root causes and recommends process changes to prevent the problems from recurring.

What Your Team Provides

Your organization provides access to the ServiceNow instance, including tables that need cleanup and adjacent systems that might source corrected data. You identify which data is most critical and which problems are most urgent. Your team provides business context: what a duplicate looks like for your organization, how you expect key fields to be populated, what historical data you wish to keep versus discard, and what constraints your business rules impose. You participate in decisions about remediation strategy, especially where cleanup involves judgments about what is correct.

Measuring Success

Success is measured against baseline metrics established during the discovery phase. The number of duplicates in critical tables drops to within acceptable tolerances. The percentage of records with populated key fields reaches the target level. Stale data is archived or removed. Integrations that were blocked by data quality issues resume. Reporting and analytics that depend on clean data become reliable. The organization confirms that automated discovery runs complete without errors related to malformed data.

Partner success depends on skilled execution. Data cleanup prevents cascade failures where bad data in one system causes problems downstream. Clean data means integration works smoothly. Analytics are accurate. Users trust the system. The investment in cleanup eliminates thousands of hours of rework and manual fixes.

Choosing between fixing records and fixing the rules that create them

A cleanup project that only corrects existing records will be back in the same place within a year. Duplicate configuration items usually come from an identification rule that treats two records as different when they describe the same thing, or from a discovery source that never gets matched to a manual entry. Missing owners usually come from a form that let people skip a field, or from an import that never mapped the field at all. The first decision in any engagement is therefore whether the problem is the data or the mechanism generating it. Most teams need both, but the order matters. Fixing records first, while the rules still create new duplicates, produces a clean snapshot that decays on the next import.

A useful test is to take a sample of duplicates and ask which source created each member of the pair. If the answer is mostly a single source, the rule is the thing to fix. If the answer is a spread of manual entries, the problem is usually process and training, and no reconciliation rule will hold without an owner watching the intake.

Remediation options and the damage each one can do

Each record in a cleanup needs one of a small number of treatments. The table sets out what each treatment does and where it goes wrong, which is the part that rarely appears in a plan.

Running the work in an order that can be reversed

A cleanup that cannot be undone will eventually cause an incident of its own. The order below is built around keeping every change traceable to the state it replaced.

1. Export the affected tables, including the relationships and the fields you intend to change, to storage outside the instance before anything else. Confirm the export opens and contains the expected row counts.
2. Agree the rule set that will decide each treatment, written as conditions a person could check by hand. A rule nobody can explain by hand will not survive a dispute about a bad merge.
3. Run the rules against a copy or a non-production environment and review a random sample from each outcome category, not only the largest one.
4. Apply corrections in batches small enough that a bad batch can be reversed without losing the good ones. Log each batch with the rule it used.
5. After each batch, rerun the discovery and reporting jobs that depend on those tables and check that they complete without new errors.
6. Only then move to the next table, and leave a short note on the root cause for each category of error so the rule set can be tightened.

Failure modes that look like success

The most dangerous outcome of a cleanup is a clean report built on wrong data. A merge that combined two servers will reduce the duplicate count and pass every dashboard check, while the surviving record now carries the relationships of both machines. The count improves and the topology gets worse. The second common failure is overwriting a field from a source that the business does not trust for that field. A cost center taken from an old import can look more complete than the blank it replaces and still be wrong.

To test for these, pick a handful of merged or backfilled records and confirm them against the system that owns the real-world item, such as the asset register or the cloud provider’s own inventory. If a sample check disagrees with the record, stop the batch and review the rule before continuing.

When cleanup should wait

Cleanup is the wrong first move during a migration cutover, because the target will change again as data arrives, and corrections applied now will be overwritten by the load. It is also the wrong move while the owner of the table has not been named. Corrections without an owner will drift back, and the next person to see a discrepancy will have no authority to decide which value is right. In those cases, the CMDB health remediation service is better placed to start with governance, and the migration reconciliation work described in the data migration reconciliation and cutover guide should come first.

How to know the cleanup is holding

Measure the same queries before and after, using identical filters. Changing the definition of a duplicate in the middle of a project makes the trend meaningless. Track the duplicate count, the share of records with the fields that matter, and the number of records that changed in the last period without a logged reason. A healthy result is a count that falls and then stays flat when nobody is working on it. A count that rebounds within weeks means the intake rule is still generating the problem.

Can we clean the CMDB while the discovery schedule keeps running?

You can, but expect discovery to recreate or reassign records you have just merged if its identification rules disagree with yours. Agree the identification rules with whoever owns discovery before any merge runs, and pause or narrow the scheduled runs for the tables under work if the rules are still in dispute.

Who should approve a merge when the records look identical?

The owner of the asset or configuration item class, not the person running the cleanup. Identical-looking records can belong to different owners, and a merge removes the option of separating them later. Approval should be recorded against the identifiers used, so the decision can be traced.

What do we do with records nobody can confirm?

Hold them in quarantine with an owner and a review date instead of deleting them. Deleting an unconfirmed record removes evidence that a problem existed. Reviewing a quarantine list on a fixed cycle is usually enough to clear most of it, because many entries turn out to be retired items with no live relationships.

Is a full export really necessary for small tables?

Yes, because the cost of an export is small and the cost of an unrecoverable merge is not. Even a small table can hold relationships that take hours to rebuild by hand. The export also gives you a before-state to compare against when you need to explain what changed.

The CMDB remediation workflow article shows how approval and review steps can sit inside the platform, and the reconciliation rules and duplicate control article goes deeper on the identification side.