Getting your data out of the old system

The question comes up in every second conversation, usually near the end: "And what about our data?"

That is rarely curiosity about file formats. Behind it sits the experience that a project once got stuck at exactly this point — or the worry that in the end somebody will retype 3,000 articles.

What actually makes a migration hard

Not the volume. 5,000 customers are no challenge for an import, and neither are 50,000. Three other things are:

Grown fields. The "notes" column has collected everything that fitted nowhere else for twelve years: delivery hints, phone numbers, "careful — prepayment only!", a termination date. No import can split that automatically, and it isn't wise to try: what a free text means is known only inside the business.

Duplicates. "Müller GmbH", "Mueller GmbH", "Müller G.m.b.H." — three entries, one company. And sometimes genuinely three companies. No software may make that call on its own; it can only prepare it.

Half-truths. The stock in the sheet hasn't matched since the last count. The contact person left two years ago. Move data like that unfiltered and you have the same errors in a newer system — only harder to spot, because now they look tidy.

On top of those sit the small format traps that trip up every import at the same place:

What the file says	What it becomes when nobody looks
01.03.26	1 March 2026 — or 3 January, depending on where the file came from
0171 1234567	Leading zero gone, phone number treated as a number
1.250,00 and 1,250.00 in one column	A factor of 1000 off
Article number 00734	734, and the link to the supplier is lost
Umlauts from a legacy system	Müller instead of Müller, on every row
Trailing spaces	Two customers that look identical and are not

None of it is dramatic — as long as it surfaces before 20,000 rows have been written.

What an import has to do

Those three points define what a usable import must do — and what it should deliberately not do.

• Preview before writing. You see what would arrive before anything is stored. An import that writes straight away is one you only get wrong once.
• Mapping you decide. Which column of your file goes into which field is your call. The system may guess a suggestion, nothing more.
• Errors per row, not a global abort. Thirty rows with a bad date format must not block the other 2,970. You fix the thirty and load them again.
• Repeatable. The first run is always a test. So is the second. Only the third counts.
• Traceable. After the import it is on record who loaded what and when — in the audit log, not in someone's memory.

That's what data import does here: CSV and Excel as self-service, with preview, column mapping and row-by-row feedback. For larger moves — a database from a legacy system, several linked sets, real clean-up — we take it on as a guided migration if you want. The difference isn't the technology, it's who makes the decisions: on your own it's you, guided it's both of us.

The order that works

A migration has a natural sequence, and reversing it means doing the work twice.

1. Master data first — customers, articles, suppliers, staff, equipment. Everything else hangs off it. An order without a customer isn't half a row, it's no row at all.
2. Then the open items. What is running today has to come: open orders, live projects, upcoming deadlines.
3. History last — and only what you truly need. Closed items from ten years back are rarely the answer to a question anyone asks you tomorrow. For record-keeping duties, a clean archived export in the old format is often enough.

The point of number three isn't convenience. Every row of history you take along has to be understood, mapped and then carried forever. "Move everything" sounds safe and is the most common reason migrations never finish.

There is one honest exception: data you must keep accessible for legal reasons and that will stop being readable in the old system because the licence ends. That isn't history, that's archiving — and the question is not "how does it get into the new system" but "in what format is it still readable in ten years".

The test to run first

Before anything goes live: take 20 rows. Not 20 pretty ones — 20 typical ones, including the two ugly ones that come to mind immediately. Load them, look at the result, and read the free-text fields.

If those 20 arrive cleanly, 20,000 will too. If they don't, you have found a question you wanted answered beforehand — on 20 rows, not on your entire dataset.

Concretely, the selection should include:

• the customer with the longest notes field,
• the article with special characters in its name,
• a record your team already considers broken,
• one of the suspected duplicates,
• an entry nobody has touched in years.

What happens after the import

A migration is not the day the file goes through, it's the two weeks after. That is when you notice what arrived formally correct and factually wrong — the address that belongs to the wrong site, the category that meant something else in the old system.

So it pays to keep the old state readable during that period (an export, not continued operation) and to name one person where such findings land. Not as a project — as a collection point for two weeks.

And the real reason this works here has nothing to do with the import: your data lands in a database of its own, not in a shared one with a customer number beside it. A test run concerns you and nobody else. And when you want to move on one day, your data sits there as a self-contained set.