Data Migration: 12 Risks and a Safe Plan for Moving from an Old System to a New One

In brief: Data migration is moving your data from an old system (Excel, legacy software, another platform) to a new system completely, accurately and securely. It is one of the most underestimated parts of projects: the new system is ready but the data is not clean, fields do not match, relationships break and history disappears. The safe approach is: 1) produce a data inventory, 2) decide what will be moved, 3) clean the data, 4) prepare a mapping table, 5) run and verify trial (pilot) migrations, 6) do the real migration in a planned cutover window, 7) keep your rollback plan ready. Do not treat migration as “the developers' last-week job;” it must be planned at the start of the project, and the business units must take part in verification. Because you are moving personal data, security and KVKK obligations are also part of the migration process.

Last updated: October 2026

Why is data migration so risky?

The typical story when moving to a new system: the code is written, the screens are nice, testing went well. Then migration day comes and this surfaces:

• The same customer is recorded with three different spellings.
• Date fields are in different formats, some empty.
• The “status” codes in the old system have no equivalent in the new one.
• Relationships between orders, customers and products are broken.
• There are unused records accumulated over years that nobody knows about.

Data is the fuel of software; poor-quality data makes even the best system look unreliable. So plan data migration as a separate mini-project. For the general logic of moving, see our moving from Excel to custom software article too.

12 risks and their precautions

A step-by-step safe migration plan

Step 1: Data inventory and scope

• In which systems is there data? (Old software, Excel files, email attachments, shared folders, third-party services)
• Which data types are in each source? (Customer, product, order, stock, invoice, document)
• What is the volume? (Number of records, file size)
• Who is the data owner? (Sales, accounting, warehouse…)

Step 2: Decide what you will migrate

You do not have to migrate everything. The question: “Is this data necessary for the business in the new system?”

The principle of data minimization for personal data supports this: do not move unnecessary personal data to the new system. Consult your legal/KVKK officer on retention periods.

Step 3: Clean the data

Cleaning before migration is much cheaper than fixing afterwards:

• Merge duplicate records (the same customer, the same product).
• Standardize formats: Phone, date, address, currency, upper/lower case.
• Fill in missing required fields or set a rule for them.
• Remove unused records.
• Reduce inconsistent codes (statuses, categories) to a single list.

Do the cleaning together with the business units as much as possible; they know best which record is correct.

Step 4: The mapping table

Write down the equivalent of every field of the old system in the new system:

Identify up front the fields that do not match and the data that cannot be migrated without loss (e.g. free-text notes).

Step 5: Trial migrations (pilot)

Before the real migration, run at least one, preferably several trial migrations:

1. Run the migration script or tool.
2. Check the result: record counts, totals, relationships, sample records.
3. Fix the errors and repeat.
4. Measure the migration time; plan the cutover window accordingly.

In each trial, a person from the business units should verify on real records: “Did this customer's orders come across correctly? Does this product's stock match?”

Step 6: Validation methods

• Record count comparison: 12,480 customers in the source, 12,480 in the target? (Those deliberately not migrated should be documented separately.)
• Total checks: Do total stock units, total balances and order amounts match?
• Relationship checks: Are there orders with no customer, or order lines with no product?
• Sampling: Compare 50–100 random records by hand; especially exceptional and old records.
• Critical scenarios: Create an order in the new system and try it end to end by linking it to old data.
• Character check: Do Turkish characters (ı, ş, ğ, İ) come across correctly?

Step 7: The cutover plan

Make a plan for the real migration:

1. Freeze period: Data entry in the old system is stopped (e.g. over the weekend).
2. Final migration: The current data is moved.
3. Validation: Results are confirmed with a quick checklist.
4. Go-live: The new system opens.
5. Monitoring: Close follow-up and fast support in the first days.

If zero-downtime cutover is needed (systems running 24/7), more advanced methods such as incremental migration (continuously synchronizing changes) and parallel running are required; these are more complex and costly.

Step 8: The rollback plan

The answer to “what do we do if something goes wrong?” must be ready in advance:

• Keep the old system open read-only for a while.
• Take a full backup before migration and test that it can be restored.
• Write the rollback criteria beforehand (e.g. “if there is a critical data inconsistency, we return within X hours”).

Special attention points by data type

Customer data

Duplicates and merging, communication permissions (marketing consents), personal data minimization. Using an old list for marketing without permission information can create legal risk.

Product and stock

Product codes, variants, units (piece/case), stock by warehouse. The moment stock is migrated matters: without a count and a freeze, stock differences arise. For detail, see our inventory management guide.

Orders, invoices and financial data

The figures must match exactly; watch rounding, currency and VAT differences. Do not lose documents subject to legal retention; decide together with your accounting adviser.

Files and documents

File size, folder structure, naming and access permissions; the link between documents and records (e.g. which customer a contract PDF belongs to).

E-commerce and SEO

If the site's addresses (URLs) change, a 301 redirect plan is as important as data migration: see our website redesign checklist. For moving product, order and customer history in a platform change (e.g. from a hosted platform to custom software), see our e-commerce infrastructure choice article.

Security and KVKK

Data transfer is a moment when risk rises:

• Store and send migration files encrypted; do not email raw customer lists.
• Limit access to the people who need it; delete temporary copies when migration ends.
• If you use real personal data in the migration (test) environment, the test environment must be protected as much as production; use anonymized data where possible.
• If a third-party company or tool will access your data, put in place a non-disclosure agreement (NDA) and data-processing terms. Consult your legal adviser on KVKK (Turkey's personal data protection law) obligations.
• Do not leave sensitive data in logs produced during migration.

For general security principles, see our web application security guide.

A sample timeline

Duration varies a great deal with data volume and quality; that is why doing discovery and sample analysis at the start of the project is essential for a correct estimate.

Data migration checklist

• All data sources are listed; volumes and owners are known
• What will be migrated/archived/deleted has been decided
• Data has been cleaned; duplicates and gaps resolved
• The mapping table is written and approved by business units
• Turkish character and format tests have been done
• At least one (preferably several) trial migrations have been done and verified
• Record count, total and relationship checks are defined
• The cutover plan and freeze window have been announced
• A full backup was taken and restoration tested
• Rollback criteria and plan are written
• Security: encrypted transfer, limited access, deletion of temporary copies
• A post-launch monitoring and support plan is ready

8 common mistakes

1. Leaving data migration to the last week of the project.
2. Migrating without cleaning the data.
3. Leaving validation to the developer alone. The business unit must verify.
4. Settling for a single trial migration.
5. Having no rollback plan, shutting down the old system immediately.
6. Not testing Turkish characters and format problems.
7. Neglecting security and KVKK.
8. Nobody knowing why/what the old data contains.

Data migration with Aktaş Digital

In the CRM, ERP, e-commerce and operations systems we newly develop, we treat data migration as a separate, planned part of the project: data inventory, cleaning suggestions, a mapping table, trial migrations, business-unit approval and a rollback plan. If you are moving from Excel or an old system, you can ask for a scope and cost breakdown through our quote form by sharing your current data, for our CRM systems, ERP systems and inventory tracking systems. An NDA option is available for confidentiality. If a live data flow between systems is needed, see our system integration guide.

Frequently Asked Questions

How long does data migration take?

It depends on data volume, quality, the number of sources and the complexity of transformation rules. A clean and small data set can be migrated quickly; years of accumulated, scattered and dirty data takes a long time. Sample analysis is needed for a correct duration.

Can I import Excel files directly?

Often yes; but first the structure (columns, formats) must be consistent and cleaned. Direct import looks easy but duplicates and format errors are carried to the new system too; so do cleaning and mapping first.

Do I have to migrate all the old data?

No. Decide what to migrate based on business need and statutory retention obligations. Archiving or (if permitted) deleting data you do not need reduces both cost and risk.

Does the system have to stop during migration?

Usually a short “freeze” period is needed (e.g. a weekend). Zero-downtime cutover is possible but more complex and costly; decide according to your business-continuity requirement.

When should I shut down the old system?

It makes sense to keep it read-only until trust in the new system's accuracy has built up and a safe archive of the necessary data exists. Plan the shutdown date in advance and seek advice on statutory retention requirements.

What special steps should I take with personal data during migration?

Apply data minimization (do not migrate what is not needed), carry out the transfer encrypted and with authorized people, use anonymized data in the test environment where possible and consult your legal adviser on KVKK obligations.

Conclusion

Data migration determines the first impression of the new system: if users do not see their old customers, orders and stock correctly, they do not trust the system. Produce an inventory, decide what will be migrated, clean the data, write the mapping table, verify with trial migrations and keep your rollback plan ready. The first thing you can do today: write all the data sources you use today (software, Excel, folders, email) in one list and identify the owner of each.