Data Migration & Data Quality
Move what matters.
Fix what cannot be trusted.
Leave behind what no longer belongs.
Legacy dataTrusted foundation
A new ERP, CRM or operational platform can only perform as well as the information it receives. Data migration therefore needs more than extraction and loading. It needs ownership, definition, cleansing, validation, rehearsal and a clear decision about what belongs in the future operating model.
Data migration is deciding what the new system can responsibly trust.
Bad data does not become better because it reaches the new system successfully.
A technically successful migration can still fail the business if customers are duplicated, supplier information is wrong, opening balances do not reconcile, inventory cannot be trusted, product setup is incomplete, historic records have no purpose, or users return to spreadsheets because the new data is unreliable.
Not a cutover task
Migration should begin while the solution is still being designed.
Data is the fastest honest feedback a programme receives. It tells you what the business really does, rather than what the workshop said it does.
- What is the business object?
- Who uses it?
- Who owns it?
- Is it still active?
- What process depends on it?
- Which system is authoritative?
- Does it need history?
- Does it contain sensitive information?
If data migration starts near UAT, the project has already lost valuable time.
In short
What this page decides.
- Migration starts during solution design, not near cutover.
- Not everything should move. Each dataset gets a recorded disposition decision.
- The business owns the meaning of the data. We cannot decide it for you.
- Data is profiled and measured before scope, effort or dates are promised.
- Cleansing and mapping are done against the future operating model, with named owners.
- Rehearsals prove the run is repeatable, timed and reconcilable before it matters.
- Business users validate real scenarios. Relationships are checked, not only counts.
- Reconciliation proves the business position, not simply that rows arrived.
- Cutover happens when the evidence supports it, with a fallback that reflects what can actually be reversed.
- After go-live the data is stabilised, the migration is closed, and ownership continues.
The migration model
Start with what the data means, not only where it is stored.
The core disciplines remain consistent. The sequence and depth are scaled to the platform, scope, data estate and risk, so the number of cycles, the history approach, the delta strategy and the cutover model differ between engagements.
Understand
What the data means, and who depends on it.
Profile
Measure it before making promises.
Decide
Migrate, archive, reference or retire.
Clean
Correct it at source where possible.
Map
Legacy structure meets the future design.
Build
Repeatable loads, not one-off heroics.
Rehearse
More than once, before it matters.
Validate
Business users test real scenarios.
Cut over
A sequence with owners and decision points.
Reconcile
Prove the position against an agreed source.
Own
Somebody keeps the data good afterwards.
Know what you have
Measure the data before making migration promises.
We profile your actual data and report actual findings. We do not publish generic benchmark percentages about how bad data usually is.
- Customers
- Suppliers
- Contacts
- Products
- Items
- Prices
- BOMs
- Routings
- Locations
- Bins
- Inventory
- Assets
- Projects
- Employees
- Chart of accounts
- Dimensions
- Open transactions
- Cases
- Service users
- Partners
- Documents
An inventory is a starting list, not a commitment. Do not assume every dataset should move.
- Row counts
- Duplicates
- Missing values
- Invalid formats
- Unused records
- Old records
- Reference inconsistencies
- Orphaned records
- Unexpected values
- Data-volume distribution
Decide what moves
Migration is also an opportunity to stop carrying data the business no longer needs.
Every dataset gets one of four decisions, made by a named owner and recorded.
Migrate
Needed operationally in the new platform.
Archive
Needed historically, but not in the live platform.
Reference
Kept accessible outside the transactional system.
Retire
No longer needed by anybody.
The safest migration is not always the largest migration.
Foundation
Master data shapes every transaction that follows.
Get customer, supplier, product, finance and inventory right, and most of the rest becomes manageable.
- Customer
- Vendor
- Product and item
- Site, warehouse and location
- Resource
- Employee
- Account and dimension
- Asset
- Duplicate accounts and conflicting identifiers
- Multiple addresses and missing contact details
- Old customers and incorrect classifications
- Credit information and parent / child relationships
- Where CRM and ERP both hold the customer, decide which platform owns which parts of the record
History
History has value, but it does not all need to become transactional data.
The question is not whether the past matters. It is which purpose the past serves, because operational history, analytical history and governed records have different destinations.
Operational history
Information users and processes genuinely need inside the new platform to do the work. This is the smallest of the three, and the most expensive to carry.
Analytical history
History needed for reporting, trend analysis, forecasting and AI. This usually belongs in an analytical architecture such as Microsoft Fabric rather than in transactional tables.
Governed record and historical access
Information retained for audit, organisational records, statutory, regulatory or contractual requirements and service continuity. This needs a governed archive, appropriate read-only access or another records solution, decided with your own advisers.
An analytical platform is not automatically a records archive simply because it contains historical information.
- Migrate selected history
- Archive the legacy application
- Data warehouse or Fabric
- Read-only access
- Document archive
- Reporting layer
Keeping the legacy system available is itself an architecture and commercial decision. Where legacy access is proposed, it should be qualified and given an explicit future decision rather than continuing by default.
Fix before you load
The new system should not become a cleaner interface over the same data problems.
Cleansing is a business activity supported by technology, not a technical activity performed on behalf of the business.
- Deduplicate
- Standardise
- Correct
- Complete
- Classify
- Deactivate
- Map
- Merge
- Validate
The migration team can identify a duplicate. Only the business can decide which record represents reality.
Old structure to new model
Migration mapping is where legacy assumptions meet the future design.
Every rule needs a meaning, an owner and a test. None of them should live only inside a script.
- Old field
- New field
- Transformation rule
- Default
- Reference mapping
- Owner
- Exception
- Validation
- Do not map a legacy field simply because it exists. Ask whether the future process still needs it.
Defaults should represent a valid business decision, not hide missing data.
Traceability
For important data, we should be able to explain where it came from and what changed it.
This is a control discipline rather than a tooling requirement. Specialist lineage tooling can help at scale, but the point is that a material value in the new platform can be traced back to a source record, a rule and an owner.
Source record
Where the information came from, and which system was authoritative.
Extract
What left the source, when, and at which version.
Mapping
Which rule applied, approved by which owner.
Transformation
What changed, including defaults and derived values.
Load
What the target accepted, and what was rejected.
Target record
What the new platform now holds.
Validation
Who confirmed it represents the business position.
For every material transformation we record the source, the rule, any default, the derived value, the owner, the exception behaviour and the target. A value nobody can explain is a value nobody will defend during an audit or a dispute.
Identity
Identity survives migration even when identifiers change.
New platforms usually issue new keys. The business, the integrations and the historic references still need to recognise the same customer, supplier, item, asset, project or service user.
- Legacy identifier
- Target identifier
- Business key
- System identifier or GUID
- External identifier used by other systems
- Duplicate and merge decision
- Cross-reference table
- Integration dependency
A record is not fully migrated until the systems and processes that depend on it can still identify it correctly.
Relationships and documents
A record can be present and still be wrong if its relationships are wrong.
Counts and balances do not prove that a contact sits under the right account, that a component sits in the right bill of materials, or that a case still has the right owner. Relationship integrity belongs in every rehearsal and every validation cycle.
- Contact belongs to the correct account
- Customer belongs to the correct parent
- Item belongs to the correct category
- Variant belongs to the correct product
- Component belongs to the correct bill of materials
- Location and bin hierarchy remains valid
- Order belongs to the correct customer
- Project belongs to the correct customer or entity
- Case ownership remains correct
- Dimensions and references remain valid
Prove it before cutover
The first full migration should not happen on go-live weekend.
Several cycles, each with a clear purpose, timing and reconciliation. Names vary by project.
DM1
Master data, loaded and inspected.
DM2
Master data plus selected transactions.
DM3
Full rehearsal, timed and reconciled.
Cutover
The final approved load. Names vary by project.
- Extraction works
- Mapping works
- Load sequence works
- Volumes are understood
- Errors are visible
- Timing is known
- Validation works
- Reconciliation works
- Business users can test
- The cutover plan is credible
A rehearsal is a business-confidence exercise, not only a technical load test.
Confidence gates
Technical success is not business validation.
Migration readiness moves through four decision points, with thresholds set for your risk rather than a generic standard. Each one can honestly conclude that scope should reduce, work should be repeated, or the date should move.
Gate 1
Before cleansing or mapping begins
Scope and ownership
The estate has been profiled and every dataset has a recorded disposition decision with a named owner.
Confirmed at this gate
- Profile accepted
- Disposition decision recorded
- Authoritative source agreed
- Named business owner per domain
- Retention and legacy access decisions taken
Decision
Proceed · Reduce scope · Resolve ownership · Re-design
Gate 2
Before the migration build is trusted
Data and mapping readiness
Cleansing has reached the agreed target and the rules that change data are visible, owned and approved.
Confirmed at this gate
- Cleaning target met
- Master-data readiness
- Mappings approved
- Defaults justified and identifiable
- Transformation rules documented and tested
- Identifier and cross-reference approach agreed
Decision
Proceed · Remediate · Re-scope
Gate 3
Before cutover is credible
Rehearsal and proof
The run is repeatable, timed and reconcilable, and business users have validated real scenarios rather than sample rows.
Confirmed at this gate
- Repeatable extract and load
- Timing understood
- Error handling proven
- Business validation passed
- Relationship integrity checked
- Reconciliation passed
Decision
Cutover candidate · Repeat the cycle · Remediate
Gate 4
The go-live decision
Cutover
The final position is agreed, the load is proven against it, and the residual exceptions are understood by the people who accept them.
Confirmed at this gate
- Final source position agreed
- Freeze and delta handled
- Final load reconciled
- Business validation signed off
- Connected systems ready for the new identity
- Residual exceptions owned
Decision
Go · No-go · Controlled deferral
- Record count and field values
- Relationships and status
- Balances and inventory
- Open orders
- Customers, suppliers and products
- Cases and projects
- Business users should validate real scenarios, not sample rows
Underneath the gates
The detailed control layer.
The same disciplines, expressed as the checks a delivery and data team actually work through.
Does it add up?
Important data needs a provable bridge from source to target.
Finance reconciles to agreed control totals. Inventory reconciles to agreed stock positions. CRM reconciles to relevant record counts and ownership.
Source count and value
The agreed starting position.
Extract
What actually left the legacy system.
Transform
What the rules changed, and why.
Load
What the new platform accepted.
Target count and value
What the new platform now holds.
Exception
What did not arrive, and who owns it.
Reconciled
A provable bridge, signed by the business.
IT can confirm the load completed. The business must confirm the data is usable.
Cutover
Cutover is where data, process and time meet.
Clear owners, sequence, dependencies, timing, decision points and fallback. Data readiness belongs in the go-live decision.
- Freeze
- Final extract
- Delta
- Clean
- Load
- Validate
- Reconcile
- Business sign-off
- Go / no-go
Go-live pressure should not convert unresolved data risk into accepted data risk by default.
If the run does not go to plan
Fallback must reflect what can actually be reversed.
Some migrations can be reset cleanly. Others require controlled recovery instead, because transactions have already been created or connected systems have already accepted the new identity. That distinction belongs in the plan, not in the room at three in the morning.
- Partial load
- Target reset or cleanup
- Failed delta
- Reopening the legacy system
- Extending the freeze
- Emergency transaction handling
- Restart point
- Taking a new extract
- User communication
- Reconciliation status at the point of the decision
Connected systems must be ready for the new data identity, not only the new application.
After go-live
Migration ends. Data ownership does not.
The days after cutover decide whether the business keeps trusting the numbers. Defects, missed records, relationship errors and unresolved exceptions need the same discipline as the load itself, and then the migration has to be formally closed.
Cut over
The final approved run, against an agreed position.
Reconcile
Prove the business position, then record the exceptions.
Stabilise
Fix what the first weeks of real use expose.
Close migration
Exceptions closed, sign-off taken, temporary access removed.
Steward
Ongoing business ownership of meaning and quality.
- Post-go-live data defects
- Missed records
- Relationship errors
- Duplicate resolution
- Mapping issues found in real use
- Integration identifier issues
- Unresolved exceptions
- Final reconciliation
Who owns what
We can move the data. We cannot decide what the data means on behalf of the business.
Migration is a joint activity with a clear division of accountability. Where these responsibilities are unclear, cleansing becomes guesswork and sign-off becomes a formality.
- Profiling
- Migration framework and design
- Mapping structure
- Technical migration tooling
- Transformation execution
- Repeatable loads
- Error reporting
- Validation and reconciliation support
- Cutover support
What drives migration effort
Migration complexity is driven by what has to be understood, corrected, transformed, proven and reconciled.
Row count is a poor predictor. These are the factors we qualify before any commercial commitment is made, and they are also the factors that change during a programme if the estate turns out to be different from the description.
- Number of source systems
- Data domains
- Entities
- History depth
- Document volume
- Source data quality
- Transformation complexity
- Duplicate resolution
- Open transactions
- Source system availability
- Integrations affected
- Rehearsal cycles
- Cutover window
- Reconciliation requirements
- Business availability
We would rather qualify scope honestly than price an estate nobody has profiled. Where migration scope cannot yet be established, the responsible first step is a profiling and disposition exercise rather than a fixed commitment.
Data recovery and data health
When the platform is live and nobody quite trusts the data.
Unreconciled balances, untrusted stock, duplicate customers and undocumented mapping rules are common findings. The assessment establishes the position before anybody proposes a fix.
What exists
The datasets, sources and copies actually in use.
What is wrong
Measured, not assumed.
What the business trusts
Often narrower than the system suggests.
What does not reconcile
Balances, stock and control positions.
Who owns it
By domain, with names rather than departments.
Which rules are unknown
Undocumented mapping and transformation logic.
What needs stabilising
The shortest route back to a trusted position.
The outcome is a route rather than a rebuild: Recovery where the position is unsafe, Optimise where quality and ownership need to improve on a working platform, or Transform where the underlying design cannot support what the business now needs.
Data handling
Migration temporarily creates new copies, new access and new risk.
Extracts, staging areas and test environments deserve the same care as the platform itself.
- Extract location
- Staging
- Access
- Encryption
- Sensitive fields
- Test environments
- Retention
- Removal
By platform
The principles hold. The detail changes with the platform.
What matters is which records the future process needs, and what has to reconcile.
- Accounts, contacts, leads and opportunities
- Activities, cases and notes
- Relationships, ownership and status
- Documents
- How much historic activity is actually useful?
- Which relationships need preserving, and what duplicate customer records exist?
What data quality decides
Reporting, prediction and adoption all inherit the same foundation.
Data quality is not a migration phase that ends at go-live. It is what the platform continues to run on.
Reporting
A report is only as honest as the classification behind it. Poor master data becomes disputed management information.
AI and prediction
Models learn from what they are given. Duplicates, gaps and inconsistent categories produce confident, wrong answers.
Integration
Connected systems depend on consistent identifiers. Bad keys become duplicate orders and orphaned records.
Adoption
If users cannot trust the data, they rebuild it in spreadsheets, and the platform quietly loses its purpose.
How this connects
Data shows up in recovery, transformation and improvement.
It is rarely the headline of a programme. It is often what decides whether people trust the result.
Recover
Unreconciled balances, untrusted stock, duplicate customers and undocumented mapping rules are common recovery findings.
Transform
Migration starts during design, not near UAT, and the decision about what to leave behind is part of the future operating model.
RAPID
An accelerated route depends on limited, well-understood data. Large historic estates with unclear ownership usually do not qualify.
Optimise
Cleansing, deduplication, ownership and reporting definitions can be improved on a live platform without a new programme.
What the evidence proves
Delivery evidence and migration evidence are not the same claim.
Our published customer stories are genuine accounts of delivery. They are not, on their own, verified proof of migration quality, cleansing outcomes or reconciliation, and we will not present them as though they were.
Level 1: Method and demonstration
How our migration controls work: profiling, disposition, mapping records, run control, validation and reconciliation.
Available on request
Level 2: Migration proof
Representative or customer data extracted, mapped, loaded, validated and reconciled during a rehearsal cycle.
Proven within delivery engagements
Level 3: Production migration
A verified customer go-live where the migrated position was reconciled and accepted by the business.
No published example yet
Level 4: Verified outcome
Approved evidence of a measurable data-quality or migration result after go-live.
No published example yet
Check the fit
Six questions before migration scope is agreed.
This is a routing aid rather than a scope or commercial decision. Your answers are carried into the conversation, so nothing has to be repeated.
Indicative signal
Answer the questions and we will show a likely starting point. This is a recommended next route rather than a scope or commercial decision. Please keep every answer at organisational level: no customer, personal, patient or case information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions leaders ask about data migration.
Data migration & data quality
What does your data actually look like today?
If you are planning an implementation, approaching cutover, or already live with data nobody quite trusts, we can help establish what should move, what should be left behind, and what has to reconcile.