Answer.

In the history of IT global experience, data migration tasks have often become sources of unexpected failures: distortion, loss, or duplication of information, especially in large, heterogeneous information environments (for example, when transitioning from a monolith to microservices or from legacy platforms to modern solutions).

The problem lies in the lack of a unified understanding of migration: clients or developers often perceive this task as purely technical, underestimating the risks to business processes and failing to work through boundary case scenarios (incompatibility of data formats, structures, loss of one-time business rules in the old system).

The solution consists of a systematic approach:

Complete inventory of data models, including non-obvious relationships and business rules.
Development of detailed migration scenarios: what happens to historical, outdated, orphaned, and disparate data.
Explicit documentation of migration requirements, including the order of loading, rollback methods, and checks for completeness and correctness of transfer.
Documentation of risk areas: what is not transferred, why, and how this is documented.

Key features:

Close communication is required between the business analyst, architect, and DBA.
A validation stage of the migration is always added (for example, selective replication and subsequent audit).
Faceted (step-by-step) documentation: what is fully transferred, what is partially transferred, and what requires manual work.

Trick Questions.

Can data migration be conducted without the participation of business units if "everything is in the database"?

No, without the involvement of the business, it is impossible to determine the validity, criticality, and relevance of data. Old business rules, even if not formally described, can affect the lifecycle of information.

Is it mandatory to preserve all fields from the old data model in the new system?

Not always: some fields may be rudimentary or have lost their significance. However, this decision should be agreed upon and documented; otherwise, there will be a risk of inconsistency in business processes.

Can we limit ourselves to selective migration of only "fresh" data?

This depends on business requirements. Often, historical data is needed for reporting, compliance, or audits. Selective migration without agreement creates risks of losing legal or operational information.

Typical Mistakes and Anti-Patterns

Lack of specification for data transformation (which fields are converted and how).
Omitting attributes that affect downstream processes.
Ignoring the need for retesting and audit tracing of migrations.

Real-Life Example

Negative Case: A bank transitioned to a new CRM system; analysts did not document the relationships between the customer's city and regional tax benefits. This led to errors in bonus calculations.

Pros:

Rapid implementation of the solution.

Cons:

Thousands of compensation payments to customers.
Legal risks and loss of customer trust.

Positive Case: Before migration, analysts created a detailed attribute map, conducted a pilot sample and data extraction, tested the correctness of each transaction on random customers, and agreed on all scenarios with the business and audit.