Cleaning and Migrating Your Data: From Spreadsheets and Ledgers to Your New System

I build the systems and migrate the data into them. Which lets me tell you what sales

presentations do not:

**The system arrives roughly on time. The data is what runs late — and it is what decides whether the

project succeeds at all.**

Where projects actually get buried

Ask anyone who has lived through a system rollout: where did the time go? The answer is rarely

"programming." The answer is always close to this:

• "We discovered we have the same customer three times under different names."
• "The stock balances in the system do not match the warehouse."
• "The old file has half-empty columns and nobody knows what they mean."
• "The numbers went in but the dates are all 1900."
• "The accountant says one figure and the system says another."

Every one of these is a data problem, not a programming problem. And the vendor cannot solve it for

you — because they do not know which "Ahmad" is the real customer.

Why this surprises everyone

Three reasons, all structural:

1. Data is invisible in the demo. You see beautiful screens and assume your file will go into them as

it is.

2. Nobody owns it. The system is the vendor's responsibility and training is a known one — but the

data is "everyone's," which means no one's.

3. Its poor state only shows at the moment of transfer. The file you have lived with for years looks

fine, because you were the one interpreting it. And a system does not interpret — it reads literally.

And the third point is the heart of it. Your data works today because unwritten rules live in your

head: you know "Abu Ali" is the same person as "Mohammad Al-Ahmad," and that the blank column means "cash."

The system knows none of that.

Who is responsible for what

This table prevents half the disputes if it is agreed in writing before starting:

The two bold rows are the whole project. Whoever signs a contract believing the vendor will clean their

data discovers the truth at the worst possible moment.

And this is not the vendor falling short. They do not know your business: they cannot decide that this

customer is a duplicate, or that this balance is wrong, or that this item is no longer sold. **These are

decisions, not technical tasks.**

The test that may save you a month

Before planning any migration, answer:

Do you need your old data inside the new system — or do you only need to be able to look it up?

That is an enormous difference. Looking it up needs no migration: keep the old file, or a read-only

copy of the old system, and start the new one with opening balances only.

And when is that the right call?

• Your old data is chaotic enough that cleaning it costs more than it is worth
• You do not use the history in practice — you only look at the current year
• Your business changed, so the old data describes a different company

A clean start is an entirely legitimate decision, not an escape. Chapter two works through it.

What this book covers

Twelve chapters in the order the work actually happens: what to move and from where, how to understand your

data before touching it, then cleaning at two levels, then duplicates and matching, then coding and keys,

then opening balances, then the dry run, the execution and verification, and finally a migration plan and

an audit producing a work list.

And I will not explain a particular tool. You will most likely work in Excel or Google Sheets with the

import template your vendor gives you — and that is enough for most small projects. What matters is **the

method and the order**, not the software.

And it carries what no translated source has: Arabic data problems specifically — name spelling

variation, Arabic-Indic digits, phone number formats, and encoding on import. Those alone are enough to

sink a migration.

The rule of this book

Do not migrate your data. Migrate the decisions you made about it.

Every row you move is a decision: this is a real customer, this is their correct balance, this item is still

sold. Whoever moves rows without decisions moves their chaos into a cleaner place — and pays for the system

twice.

Action steps

1. Write in three lines: what worries you most about your old data?
2. Answer the test: do I need it in the system, or do I need to look it up?
3. Print the responsibility table and agree it with your vendor in writing before starting.
4. Ask your vendor: who cleans the data? And who verifies it after import?
5. Name one person, by name, responsible for the data — not "everyone."