OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Migration Reconciliation: Prove Data Integrity

ServiceNow migration reconciliation checks whether data moved into the target in the condition needed for the intended service or process. It should compare source, transformed, rejected, duplicate, and target records, then test relationships, high-risk fields, exceptions, ownership, and sign-off evidence.

For ServiceNow migration owners who need to reconcile source, target, transformed, rejected, and accepted data before closure..

ServiceNow migration reconciliationdata migration controlssource-to-target reconciliation
Discuss this ServiceNow topic

Guide map

Matching Record Counts and Field Values Between Systems

Define the reconciliation boundary

Compare what left the source with what reached the target.

Compare source, transformed, rejected, and target data

Count each stage, then sample the fields that carry meaning.

Check relationships and high-risk records

Test the links between records, since a matching count can hide broken ones.

The practical framework

Reconcile ServiceNow migration data with source counts, transformations, rejects, duplicates, relationships, exceptions, sampling, ownership, and sign-off.

Define the reconciliation boundary

List the objects, fields, relationships, source window, target scope, transformation rules, exclusions, and acceptance condition. Explain what is intentionally not migrated. Without a boundary, a reconciliation report can appear complete while omitting the records that matter.

The ServiceNow data-migration route is the relevant internal destination when migration scope and user acceptance need coordination.

Compare source, transformed, rejected, and target data

Reconcile counts and meaningful attributes across stages. Investigate missing, duplicated, rejected, truncated, defaulted, or transformed values. A count match does not prove that relationships, status, ownership, or dates retained the intended meaning.

The ServiceNow Import Sets route provides an internal path when transformation and load behaviour need review.

Check relationships and high-risk records

Test service relationships, configuration references, access boundaries, lifecycle states, critical identifiers, and records used by downstream workflows. Use representative and high-risk samples where full comparison is not practical, and record the reason for the sample design.

The ServiceNow CMDB route is relevant when migration affects configuration or service context.

Handle exceptions and sampling limits

Record each material exception, owner, decision, corrective action, compensating control, and review trigger. State what sampling can and cannot prove. Do not describe an untested population as reconciled merely because the sample passed.

The ServiceNow health-check route supports review of evidence and remaining risk.

Make sign-off evidence explicit

The sign-off should identify scope, comparisons, results, exceptions, limitations, approver, date, and follow-up. Keep migration closure separate from the decision to accept residual issues. A target can be usable while reconciliation work remains open.

For migration reconciliation controls work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about migration reconciliation

Is matching record counts enough?

No. Counts can match while values, relationships, ownership, status, or transformations are wrong. Reconciliation must test the data elements and service decisions that matter.

Who should sign off migration reconciliation?

The owner accountable for the migrated service or process should accept the outcome, with data, technical, security, or operational reviewers involved where their boundaries are affected.

The research-grounded boundary

A migration is only finished when the target can be trusted for the work it supports. Matching counts do not show that approvals, owners, dates, or relationships came through intact. Before closure, record who owns the migrated service, what evidence shows it works, and the point at which a person reviews or corrects anything that does not match the source.

Match each reconciliation check to the claim it can actually prove

A migration report that says “all records migrated” is making several claims at once, and each one needs a different check. A row count proves that the same number of items arrived. It does not prove that the items are the right ones, that their references still point to the right parents, or that the transformation kept the meaning of a status field. Before running any reconciliation, write down the claims the business will rely on after cutover. Then choose the checks that prove those claims, and state what each check leaves unproven. That statement is what the sign-off authority should read.

In ServiceNow work the claims often concern ownership, open status, attachments and relationships, not just the record count. A ticket that arrives with the right number but without its assignment group will still stop work on the first day.

Reconciliation checks and what they cannot show

CheckClaim it supportsWhat it does not prove
Source and target count by objectNothing was silently dropped in bulkCorrect values or correct relationships
Rejected record reviewEvery exclusion has a reason and an ownerThat the exclusion rules were agreed by the business
Field-level comparison on a sampleTransformations behaved as specified for those recordsBehavior for records outside the sample
Reference and relationship checkParent-child links resolve to live recordsThat the relationship type still means what users expect
Duplicate detection on keysRepeated identifiers were resolved or deliberately keptThat the surviving record is the right one
Business read-back of high-risk itemsOperators can find and act on the records they needAnything the operators did not look at

An order of work that keeps the evidence coherent

  1. Define the reconciliation boundary: objects, fields, source window, exclusions and the acceptance condition.
  2. Freeze the source extract with a recorded timestamp, so later changes in the source do not appear as migration errors.
  3. Run the counts for every object in scope and investigate any gap before looking at field values.
  4. Review every rejected record, grouping them by reason, and get the business owner to confirm each group.
  5. Compare fields on a sample weighted towards records with the most transformation logic, not a random sample alone.
  6. Read back the high-risk records with the people who use them, then record sign-off against the boundary.

Where reconciliation gives false comfort

The most common false comfort comes from reconciling the transformed file rather than the target. If the check compares the output of the transform to the source, it proves the transform ran, not that the platform accepted every value. Reconcile against the target tables after load, including any values the platform changed during insert, such as normalzed case or defaulted fields.

A second trap is a rejected list that nobody reads because it is long. Rejections often cluster into a few reasons, and one of those reasons is usually a rule the business would not accept if it were explained. Group the rejections first, then ask the owner about each group. A group of two hundred records with one cause is a decision; two hundred separate records are a chore that gets skipped.

When full reconciliation is not worth the cost

For reference data that is reloaded from an authoritative source, a count and a sample may be enough, provided the source remains the system of record after cutover. Full field comparison matters most for records that carry commitments or history: open work, approvals, financial references and records under audit. Put the effort where a mistake would be expensive to find later, and document the reasoning for everything you did not compare in full.

Questions about migration evidence that the controls do not settle

What should a sign-off document contain?

The boundary, the checks run and their dates, the rejected groups with owner decisions, the sample results, the known gaps and the named authority who accepted each. A sign-off that only says “reconciled” cannot be defended later when a record is found missing.

Can we reconcile after go-live?

Yes, and you should, for the window when records are still being created in the source system. Keep the reconciliation running until the source is switched off or frozen, and treat the post-cutover differences as a separate list with its own owner.

Who should choose the sample?

Someone who did not build the transform. The builder knows which cases are awkward and is likely to sample the ones that already work. A business analyst or a second developer should choose the sample and document the selection logic.

What happens when a relationship check fails for a few records?

Decide whether the missing parent is a migration defect, an excluded record or a source data problem. Each cause has a different fix, and mixing them in one bucket hides the one that matters most.

Next step: prove the migration before cutover

If a cutover date is already set and the reconciliation plan is a row count, that gap is worth closing now. Raise your migration evidence plan with OBLYTECH. The data migration, reconciliation and cutover page covers reconciliation evidence for a ServiceNow cutover, and the guide to import sets and transform maps explains how source records are staged, mapped, transformed and reviewed, which is where many of the rules these checks test are applied.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading