Data Quality Rules (DQR) explained: deciding what data to bring across
Key points
- Data Quality Rules define the checks a record must pass before it enters your new system.
- Rules can cover missing information, formatting, duplicate records and business logic.
- Business owners, system admins and migration engineers work together to agree what valid, usable data looks like.
- Records that fail need an agreed action, such as correction, review or exclusion from the migration.
- Defining and testing rules early helps reduce problems with reporting, automation and everyday work after go-live.
George Tye
CEO & Founder
What makes data ready for migration?
Before moving data into a new system, you need to decide what’s ready to use, what needs correcting and what should stay outside the migration. A record might exist in your current system without containing everything your team will need from it in the next one.
Data Quality Rules (DQRs) make those requirements clear. They are the pass/fail criteria your data must meet to enter your new system, turning expectations such as “customer records should be complete” into specific checks that can be applied consistently.
Think of them as bouncers at the door. If a legacy record doesn’t meet the agreed entry requirements, it needs attention before it can come across.
For example, you might agree that every active customer profile needs an email address or phone number. A record with at least one of those contact details passes that completeness check. A record with neither needs a decision about what happens next. If you need support with Data Quality, Visit our data quality service page.Examples of Data Quality Rules in practice
The right rules depend on your business and the system you’re moving to. They need to reflect both the target system’s requirements and how your team will use the information once it arrives.
These examples from the Migrate Data team show how common requirements become practical migration checks.
| Rule type | Example rule | What needs to be checked | Why it matters |
|---|---|---|---|
| Completeness | Active customer profiles must have an email address or phone number. | Does each active profile contain at least one of these contact methods? | Teams need a way to contact active customers. |
| Format | Dates must use the format required by the target system, such as YYYY-MM-DD. | Can each date be interpreted reliably and converted to the required format? | Incorrect or ambiguous dates can cause loading errors or affect reporting. |
| Uniqueness | Where agreed as a business requirement, no two supplier accounts can share the same tax ID. | Do multiple accounts share an identifier that should be unique? | Potential duplicates need reviewing before they create confusion in the new system. |
| Logic | A contract end date cannot be earlier than its start date. | Do the dates follow a valid sequence? | Contract information needs to make sense for reporting and operational use. |
Passing one check doesn’t necessarily mean a record is ready. A customer profile might contain all the required fields but still be a duplicate. A contract might use the correct date format while showing an end date before its start date.
The detail of each rule matters, too. Checking that an email address is present is different from checking that it has a valid format. Neither check proves that the mailbox still exists or belongs to the right person.
Who decides what counts as good data?
Agreeing Data Quality Rules requires input from people who understand the business, the new system and the migration process.
At Migrate Data, three groups contribute to those decisions.
Business owners
Business owners decide what data matters for day-to-day work. They explain which information teams rely on and what would make a record incomplete or unusable.
An active customer account, for example, may need different information from an inactive historical account. Those distinctions help the team apply rules to the right records.
System admins
System admins understand how the new system handles data and where its requirements could affect the migration.
They help identify required fields, accepted formats and edge cases. They can also explain how missing or unexpected values could affect workflows once the data is loaded.
Migration engineers
Migration engineers turn those business and system decisions into automated checks.
This allows the agreed rules to be applied consistently across the migration data, making failures visible before the final load. The team can then work through the exceptions with the people responsible for the information.
What happens when a record fails a check?
A failed check means a record doesn’t currently meet the agreed requirements. It doesn’t automatically mean the record should be deleted.
Some issues can be corrected through an agreed transformation, such as converting a recognised date into the required format. Missing contact information may need to be supplied by the client. Potential duplicates may need a business owner to review them before anyone decides whether to merge the records.
For each rule, it helps to agree:
- Which records the rule applies to.
- What counts as a pass or a failure.
- What action should follow a failure.
- Who is responsible for resolving exceptions.
Records outside the migration scope may be excluded from the new system, but their treatment still needs to be considered separately. Leaving a record behind can also affect related information. Excluding a customer account, for example, could have consequences for linked contacts, contracts or transactions.
Resolving those decisions before the final migration helps avoid rushed corrections close to go-live.
"Fixing data errors after launching is painful and expensive."
Why defining DQRs early improves the post-live experience
Once people are using the new system, data problems start interrupting everyday work.
An incomplete customer profile can leave someone searching the old system for contact details. Duplicate accounts can split information across multiple records. Incorrect contract dates can affect reports or automations that depend on them.
Defining DQRs early gives the migration team time to identify these issues, agree how to handle them and check the corrected data before the move.
Testing the rules against real source data also shows where further decisions are needed. A requirement may sound straightforward until the checks reveal a group of legitimate records that need different treatment.
DQRs work alongside test migrations and business-user review. Automated checks confirm whether records meet the defined conditions, while users help confirm that the migrated information supports the work they need to do.
Together, these checks help reduce avoidable disruption and give your team greater confidence in the data they’re using from day one.
Agree your data quality requirements before the move
Migrate Data works with business owners and system admins to define Data Quality Rules and turn them into automated migration checks.
If you’re planning a migration, speak to our team about your data quality requirements and how to identify which records are ready to bring across.
Frequently Asked Questions
What are Data Quality Rules in data migration?
Data Quality Rules (DQRs) are the pass/fail criteria records must meet before entering a new system. They define what acceptable data looks like, including required information, valid formats, uniqueness and logical relationships between values.
What are some examples of Data Quality Rules?
Examples include requiring an email address or phone number for every active customer, checking that dates meet the target system’s format requirements and ensuring contract end dates don’t fall before start dates. Rules can also flag potential duplicates using agreed identifiers, such as a supplier’s tax ID.
Who should be involved in setting Data Quality Rules?
Business owners identify the information their teams need, system admins explain the target system’s requirements, and migration engineers turn those decisions into automated checks. Together, they agree which records each rule applies to and how exceptions should be handled.
What happens if a record fails a Data Quality Rule?
The record needs an agreed next step before it can be accepted. That might involve correcting a value, adding missing information or reviewing a potential duplicate. Some records may be excluded from the migration, but failing a check doesn’t automatically mean the source record should be deleted.
What is the difference between Data Quality Rules and data cleansing?
Data Quality Rules define the standards your data needs to meet. Data cleansing addresses issues in the data, such as inconsistent formatting, missing values or duplicates. The rules guide that work and provide a way to check whether the corrected records meet the agreed requirements.
When should Data Quality Rules be defined?
Define them during migration planning, before the final data load. Applying the rules to source data early gives the team time to investigate failures, resolve exceptions and test corrected records before go-live.
Do Data Quality Rules guarantee accurate data?
No. DQRs check whether data meets specific conditions, so their effectiveness depends on what those checks cover. An email address can pass a format check and still be outdated or belong to the wrong person. Test migrations and business-user review help assess whether the data is fit for everyday use.
Let Migrate Ensure Your Data Quality With a Full Review
Speak with a Migration Expert
Migrate Data can review a sample of your source data, identify the main migration risks and provide a clearer basis for the project scope, budget and timeline.