Data profiling report template for a migration

Copy the scope and coverage header

A migration profiling report should state which source rows and fields were examined, how each metric was calculated, what defects were found, and who decides what happens next. Define the population and rules before running profiling queries.

Download the Excel template · View the filled example

Free download: blank template and fictional example (.xlsx). No registration required.

Paste tool exports into Table results (5,000 prepared rows) and the technical detail sheet (10,000 prepared rows). Enter shared run details once. Use Exceptions only for issues needing action; Fictional example shows both summary and technical results. Extend the tables and copy formulas when more rows are needed.

Run details — enter once

Keep query versions, rules, selected columns and sampling details in the referenced check configuration and tool output. Record a per-table override only when it differs. The summary is a navigation aid for a large estate, not a replacement for detailed evidence.

The template is a proposed working control, not a vendor standard. For a wider migration plan, use the migration readiness guide; profiling describes the source condition before target comparison begins.

Define the checks before measuring them

Keep Source schema and Source table in separate columns. The fictional examples use source as the schema name.

One row per table

Rows missing required values counts each row once if any configured required field is null or blank. Excess duplicate rows counts rows beyond the first per configured non-null key. Coverage is Full, Sample, Partial or Not run. Import Result from the profiling output; Clear means only that the configured checks passed over their stated scope. Blank measurements mean unavailable, never zero.

Keep an explicit not assessed state; zero failures means something different from no check.

• Null and blank: count SQL NULL separately from empty or whitespace-only strings after an agreed trim rule. Divide each by the eligible row count, not all rows if the field applies only to a subset.
• Uniqueness and duplicates: state the candidate key and grain. Count null keys, distinct keys, duplicate key groups and excess rows; duplicate groups and duplicate rows answer different questions. Composite keys need the full set of columns.
• Distribution and range: record frequencies for important categories, minimum and maximum for dates or values, and out-of-domain counts. Keep units, currency, timezone and precision with the result. A min/max pair cannot reveal a missing middle period.
• Relationships: specify parent and child filters, permitted null foreign keys, and join semantics. Count child rows whose non-null parent key has no eligible parent; document whether historical or archived parents are intentionally outside scope.
• Validity and consistency: test allowed status values, required field combinations and cross-field rules that matter to the target. Record the approved rule version and exceptions instead of treating every unusual value as an error.

Column and partition profiling

Use Column profile for one row per table, column and partition. Paste row, null and distinct counts, minimum, maximum and numeric sum from the profiling output. Profile keys and required fields; add other columns where the migration rules need them. Leave inapplicable measurements blank.

Define whether distinct counts exclude nulls and how blanks are treated in the shared check-set. Use the same partition boundaries and record units for sums. Keep category distributions and row-level evidence in the linked export.

Microsoft's SSIS profiling task documents null ratio, value distribution, candidate-key and value-inclusion profiles. The metric dictionary and decision fields above are Monic's suggested report design.

Rate = affected eligible rows ÷ eligible rows × 100. For zero eligible rows, report not applicable; for an unrun check, report not assessed. Duplicate excess rows = rows with non-null keys − distinct non-null keys. Count orphan order rows separately from distinct missing account keys.

Filled example: a fictional orders migration

Fictional batch summary

Fictional batch examples show how to filter table results. Record manual actions only for flagged issues.

Illustrative data only: run PR-014 profiles a frozen 24,000-row orders extract for one migration wave, using a full scan at 10:00 UTC on 27 September 2026. The intended grain is one row per order_id; an accounts extract from the same boundary supplies the parent set. All 24,000 order rows and 12 of 14 mapped columns were examined; two free-text notes were excluded pending a privacy-approved method. These are invented teaching figures, not Monic customer results.

The sample demonstrates why one headline quality score would obscure different actions: a key collision threatens joins, a blank account key needs a policy decision, and an out-of-range date may be a source correction or an intended business state. The fictional rows are internally illustrative; use real query output and retained evidence in a live report.

Turn findings into owned decisions

Only record issues that need action

Preserve the pre-fix result alongside the post-fix result.

Filled example: F-01, duplicate order_id values, 4 groups and 8 excess rows in PR-014; potential overwrite when the target uses order_id as a primary key. The data steward owns root-cause investigation by 29 September; the migration engineer holds the load for this dataset, then reruns the candidate-key and row-count checks against a new extract. No exception has been accepted yet.

Record each decision's rationale and effective rule version. If cleansing intentionally changes a value, keep that approved rule for later reconciliation. A source profile is a baseline and an investigation aid, not evidence that the migrated target is correct. The reconciliation report template covers source-to-target comparison and sign-off.

State the limits of coverage and sampling

Prefer a complete pass for small or high-impact key and relationship checks when source load permits. If profiling is sampled, record the exact selection rule, seed, population, selected keys, exclusions and strata. Sample the same business grain that the rule measures. Include nulls, large amounts, old and recent dates, unusual encodings and known edge cases where relevant; a simple random sample can miss rare defects.

Do not turn sample results into a whole-dataset pass rate or a confidence claim without a suitable sampling design. A relationship check over sampled children still needs a defined parent population. Mark untested columns and inaccessible tables as coverage gaps with an owner and follow-up date. Store masked examples or controlled evidence references instead of exposing sensitive values in the report.

For a good fit, use this report before mapping, cleansing and migration rehearsals, then repeat it on the cutover extract to detect changed source conditions. For a poor fit, do not use profiling alone as acceptance evidence for transformed target data; use the separate reconciliation and business acceptance checks. Microsoft and Great Expectations describe useful profiling and integrity checks, but the sampling and decision rules here are editorial recommendations.

What is the difference between profiling and reconciliation?

Profiling describes source-data quality and coverage. Reconciliation compares an approved source expectation with a target result. Use the profiling baseline to identify pre-existing defects, then record whether migration preserved, corrected or introduced differences.

Does this template run profiling queries?

No. It records query or tool results, definitions and decisions. Run checks in your approved data environment, retain controlled evidence and copy the resulting measurements into the report.

Prepared by Monic Solutions Services. About our delivery experience.

The global SAP migration case describes reusable profiling, cleansing, matching and validation rules. That is why these templates retain rule versions, evidence and decision owners. The downloadable examples are fictional and are not client project records. Global SAP migration case.

Primary references

• Microsoft: SSIS Data Profiling Task profiles
• Microsoft: completeness and uniqueness in DQS
• Great Expectations: data integrity and relationships