Moving business data involves more than exporting and importing records. Use this 12-step checklist to protect data quality, reduce disruption and prepare a tested rollback plan.
Data migration can appear straightforward when both systems have familiar fields such as customer name, email address and account status. The difficulty usually emerges in the details: duplicate customers, missing identifiers, outdated records, incompatible formats and relationships that exist only because employees understand them.
If these issues are not identified before migration, the new platform may launch with inaccurate reports, disconnected records and frustrated users. The technology may be new, but the operational problems move with the data.
This checklist provides a practical framework for migrating data between CRMs, accounting applications, ERPs, custom software and other business systems.
Table of contents
- What is data migration?
- Data migration versus system integration
- 1. Define the migration objective and success criteria
- 2. Decide what should move—and what should not
- 3. Assign data owners and project responsibilities
- 4. Profile the source data
- 5. Clean, standardise and deduplicate records
- 6. Create a field-mapping and transformation specification
- 7. Select the right data migration strategy
- 8. Protect sensitive information throughout the migration
- 9. Build a repeatable migration process
- 10. Run test migrations with realistic data
- 11. Prepare cutover, communication and rollback plans
- 12. Validate, monitor and close the migration properly
- Common data migration mistakes
- Frequently asked questions
- Move the right data—not every old problem
What is data migration?
Data migration is the controlled movement of information from a source system to a destination system. The process may include extracting, cleaning, transforming, loading and validating the data.
Businesses commonly migrate data when they:
Replace a CRM, ERP or accounting platform
Move from spreadsheets to a central business system
Replace legacy or unsupported software
Consolidate several platforms after restructuring or acquisition
Introduce a custom operational system
Move an application or database into a different environment
A migration is successful only when the destination contains accurate, usable and appropriately protected information. Transferring every source record without an error message does not prove that the business can use the result.
This is why migration planning should begin during system design rather than shortly before launch. BDLP’s business systems consulting helps organisations clarify processes, information requirements and system responsibilities before implementation begins.
Data migration versus system integration
Data migration and system integration are related but different activities.
Migration usually moves an existing body of data into a new destination. It may happen once, in several phases or through a final series of incremental updates before cutover.
Integration keeps systems connected after launch. It continually moves information or coordinates processes between applications.
For example, a business may migrate its historical customer and opportunity records into a new CRM. After launch, an integration may continue sending approved customers and orders to the accounting platform.
Both activities need field mappings, validation and error handling, but they have different operating requirements. BDLP’s system integration services address the ongoing flow of data between websites, CRMs, accounting systems and operational platforms.
1. Define the migration objective and success criteria
Begin by documenting why the migration is taking place. The goal should describe the business result, not merely the movement of records.
Possible objectives include:
Give employees one reliable customer record
Replace an unsupported legacy system
Improve reporting across departments
Remove repeated spreadsheet capture
Consolidate several regional databases
Enable a new customer or supplier portal
Then define measurable acceptance criteria. These might cover record completeness, duplicate rates, financial balances, linked documents, reporting accuracy and the time available for cutover.
Get business stakeholders to approve those criteria. Developers can confirm that records loaded successfully, but finance, sales and operations must confirm that the information is correct and usable.
2. Decide what should move—and what should not
Migrating everything is rarely the safest default. Old systems often contain obsolete accounts, duplicate contacts, temporary records and fields that no longer support a business process.
Classify the source information into four groups:
Migrate: Active and historically relevant information needed in the new platform
Transform: Useful data that needs cleaning, reformatting or restructuring
Archive: Information that must remain accessible but does not belong in the live destination
Dispose: Redundant information that may be removed under an approved retention process
Define the historical period required for each record type. A business may need several years of transaction history but only current marketing preferences and active workflow tasks.
Include attachments, notes, audit trails and record relationships in the scope discussion. These are easy to overlook because they may be stored differently from the main records.
3. Assign data owners and project responsibilities
Every important dataset needs a business owner who can answer questions about its meaning, quality and acceptable use.
A migration normally requires responsibility for:
Business scope and priorities
Source-system access
Destination configuration
Data mapping and transformation
Security and privacy review
Technical testing
User acceptance testing
Cutover approval
Post-launch support
Avoid assigning every decision to the developer performing the migration. A developer should not have to invent the business meaning of an account status or decide which duplicate customer is authoritative.
Name the person with authority to approve go-live or trigger a rollback. That decision becomes difficult when an issue appears during a short cutover window and nobody knows who can stop the process.
4. Profile the source data
Data profiling examines what is actually present in the source—not what the system documentation claims should be present.
Profile each dataset for:
Record counts
Missing required values
Duplicate records
Unexpected formats
Invalid dates or values
Unused fields
Orphaned child records
Broken references
Unusually large attachments
Sensitive personal or financial information
Inspect custom fields and free-text notes carefully. A field labelled “Other” may contain business-critical information that employees have used for years.
Record the findings in a migration issue register. Each issue should have an owner, proposed treatment and deadline rather than remaining a vague concern about “dirty data”.
5. Clean, standardise and deduplicate records
Migration is an opportunity to improve data quality, but cleanup rules must be controlled. Automated changes can damage information just as quickly as they can improve it.
Typical cleanup work includes:
Standardising telephone numbers and addresses
Converting dates into an agreed format
Normalising province, country and currency values
Correcting invalid dropdown values
Resolving incomplete required fields
Merging confirmed duplicate records
Removing temporary or test entries
Define how duplicates will be identified. Matching on name alone is risky. Consider stable account numbers, email addresses, registration numbers or a carefully designed combination of fields.
Keep an audit of important cleanup decisions. If two customer records are merged, the team should be able to determine what happened to their related contacts, transactions and documents.
6. Create a field-mapping and transformation specification
A migration map defines how every in-scope source field reaches the destination.
For each field, document:
Source table, object and field
Destination table, object and field
Source and destination data types
Required transformations
Validation rules
Default values
Treatment of empty or invalid values
Example input and expected output
Map relationships as well as individual fields. If an invoice belongs to a customer and contains several line items, the destination must preserve those relationships after identifiers change.
Record the sequence in which related entities must load. Parent records usually need to exist before their dependent records can be linked.
Where migration requires specialised validation, transformation or administrative tools, a focused custom software component may be more dependable than repeated manual spreadsheet manipulation.
7. Select the right data migration strategy
Big-bang migration
The source stops changing, all final data moves and users switch to the destination within one cutover window. This can simplify the transition but may require significant downtime and a carefully rehearsed rollback.
Phased migration
Data and users move in controlled groups, such as by branch, department or record type. This limits the impact of a problem but may require old and new systems to coexist temporarily.
Incremental migration
An initial bulk migration is followed by smaller updates containing records changed since the previous run. This can reduce the final cutover period but requires reliable change tracking and reconciliation.
Choose according to data volume, allowable downtime, technical capabilities and operational risk—not according to which approach sounds simplest in a planning meeting.
8. Protect sensitive information throughout the migration
Migration often creates additional copies of data in exports, staging databases, test environments and backup locations. Each copy increases the need for controlled access and disposal.
Your security checklist should cover:
Approved access to source and destination systems
Encryption during transfer and storage
Secure handling of exports and backups
Restricted access to staging environments
Masked or synthetic test data where appropriate
Audit logging for sensitive operations
Secure deletion of temporary migration files
Third-party supplier responsibilities
For South African organisations, assess whether the migration involves personal information. Sections 19 to 21 of the official Protection of Personal Information Act address security safeguards and the processing of personal information by operators.
A migration checklist is not a substitute for legal or compliance advice. It should, however, make privacy and security decisions visible before data begins moving.
9. Build a repeatable migration process
Avoid a production migration that depends on undocumented manual edits. The process should be repeatable so the team can test, correct and rerun it consistently.
A controlled migration process should:
Extract an identifiable source snapshot
Record when and how the extract was produced
Apply version-controlled transformation rules
Separate successful and rejected records
Produce useful error messages
Preserve source-to-target identifier mappings
Generate validation reports
Support safe reruns without uncontrolled duplicates
Do not quietly discard invalid records to make the success percentage look better. Rejected records need a reason, owner and resolution path.
Microsoft’s guidance on CRM data migration highlights schema differences, data quality, relationships, security and performance as important planning considerations.
10. Run test migrations with realistic data
A sample of ten clean customers will not reveal how the process handles production volumes, inconsistent records or complex relationships.
Run several levels of testing:
Small technical test: Confirm basic mappings and connectivity
Representative test: Include valid records, edge cases and known quality problems
Full-volume rehearsal: Measure the complete process against the available cutover window
User acceptance test: Let business users validate records, reports and workflows
Validation should examine more than total record counts. Check:
Required fields and important values
Parent-child relationships
Financial totals and balances
Attachments and notes
User access and ownership
Reports and calculations
Search results
Downstream integrations and automations
Time every rehearsal. A migration that produces correct data but cannot finish within the approved downtime still needs redesign.
11. Prepare cutover, communication and rollback plans
The cutover plan should list every production activity in sequence, with dependencies, owners, expected duration and completion evidence.
Include:
Final source-system change freeze
Backups and proof that they can be restored
Final data extraction
Transformation and loading sequence
Technical and business validation
Go or no-go decision points
User access changes
Integration activation
Stakeholder communication
Support and escalation arrangements
Define rollback triggers before cutover. Examples might include failed financial reconciliation, missing critical entities, unacceptable performance or an inability to complete within the approved window.
The rollback procedure must account for information created after the new system becomes available. Switching users back without deciding what happens to those transactions can create another data-loss problem.
AWS provides an example cutover runbook structure that includes pre-migration activities, ownership, issue logging and rollback tasks.
12. Validate, monitor and close the migration properly
Post-migration validation should begin immediately after loading and continue through an agreed support period.
Confirm that:
Record totals and key values reconcile
Users can access the correct information
Reports produce expected results
Automations and integrations operate correctly
Rejected records have been resolved
Performance remains acceptable
Backups and monitoring are active
Keep the source system available in a controlled, read-only state until the agreed validation and retention requirements are satisfied. Do not decommission it simply because the destination opened successfully on launch morning.
Close the project with signed acceptance, updated documentation and a named owner for the new system’s data quality.
Remove temporary migration files, revoke temporary access and archive project evidence according to the approved security and retention plan.
Common data migration mistakes
Migrating every record: Obsolete and duplicated data makes the new system harder to use.
Cleaning data during the final cutover: Important transformation rules should be tested beforehand.
Ignoring relationships: Correct individual records are not enough if contacts, orders and documents are disconnected.
Using tiny test samples: Clean samples hide volume, performance and quality problems.
Validating counts only: Equal totals do not prove that values and relationships are correct.
Having no rollback trigger: Teams often continue a failing migration because nobody knows when to stop.
Leaving temporary exports exposed: Staging files may contain the same sensitive information as the live database.
Decommissioning too early: The source may still be required for reconciliation, audit or recovery.
Frequently asked questions
What is included in a data migration checklist?
A complete checklist covers objectives, scope, ownership, data profiling, cleanup, field mapping, migration strategy, security, testing, cutover, rollback and post-migration validation.
How long does a data migration take?
The duration depends on data volume, quality, relationships, destination complexity, transformation rules and testing requirements. A realistic estimate should be based on profiling and timed rehearsals rather than record count alone.
Should all historical data be migrated?
Not necessarily. Decide what must remain operational, what can be archived and what may be disposed of under approved business, legal and retention requirements.
How do you verify a successful data migration?
Compare source and destination totals, important field values, relationships, financial figures, reports and business workflows. Business users should formally validate that migrated data works as expected.
What is the difference between big-bang and phased migration?
A big-bang migration moves users and data during one main cutover window. A phased migration moves selected groups or datasets over time, reducing the immediate impact but increasing the period in which systems coexist.
Do small businesses need a formal migration plan?
Yes. The plan can be proportionate to the project, but even a small migration needs defined scope, backups, mappings, validation and a recovery process. A short migration does not make business data less important.
Move the right data—not every old problem
A safe data migration starts well before the final import. It requires decisions about business value, ownership, quality, retention and acceptable risk.
Profile the real source data, document every transformation and rehearse the complete process with representative volumes. Establish clear validation and rollback criteria before the cutover begins.
BDLP helps businesses assess existing systems, prepare migration requirements, build custom migration tools and connect the resulting platforms to the rest of their operations.