What Moves First? A Migration Order That Keeps You Trading

What Moves First? A Migration Order That Keeps You Trading

Part three finished the cleaning: names unified, dates in one format, numbers that are actually numbers, and meanings that used to live in cell colours turned into written fields. The data is ready to move. What remains is the decision that determines whether the transition passes quietly or turns into weeks of confusion: what moves first?

It looks like a technical detail for whoever is implementing. It is in fact an operational decision, and it is yours. Your company will not pause for the migration. Customers will order, invoices will go out, suppliers will deliver — all while half your data sits in one place and half in another. The right sequence is what makes that period manageable instead of a stretch where everyone works twice.

Why the big-bang move does not work

The instinct is understandable: move everything over the weekend, open Sunday on the new system, done. That scenario usually fails for three reasons that have nothing to do with the quality of the system.

First, you will discover more during the move than you expect. Every migration surfaces missing data nobody had noticed: a customer with no tax number, an item with no unit of measure, an invoice with no reference. Move everything together and all of those discoveries arrive at once, at the tightest possible moment.

Second, your team learns the system while operating it. Nobody masters a new tool in a day. A single-shot move asks everyone to learn everything simultaneously, so when an error appears you cannot tell where it came from: is the data wrong, is the system configured wrong, or has the employee simply not understood the screen yet?

Third, it leaves you no way back. If a fundamental flaw surfaces two days in, your only options are pushing through or reverting entirely, and both are expensive. A phased move always keeps part of the business standing on stable ground. This is one of the patterns that recurs in system projects that stall: the fault is rarely the tool, and usually the attempt to change everything on the same day.

Static before transactional: the rule the whole sequence rests on

Your data comes in two kinds. Static data: customers, suppliers, items or services, employees, the chart of accounts. And transactional data: invoices, orders, purchase orders, stock movements, receipts.

The difference between them is not importance but direction. Transactional data always points at static data: every invoice points to a customer and to items, every purchase order points to a supplier. The reverse is never true. So the sequence is governed by dependency, not preference: move the static first, because the transactional cannot settle on top of something that is not there.

Reverse the order and you get the classic failure: you import three thousand invoices, the system auto-creates a new customer for every name written in them, and you end up with a customer list holding the same company three times in three spellings. You will have reproduced, inside the system, the exact mess part three was spent cleaning — except correcting it is harder now.

In practice the order runs like this:

• First: the core entities. Customers, suppliers, items and services. Short lists, moved once and reviewed by eye. This is the layer everything else stands on.
• Second: opening balances. What each customer owes you and what you owe each supplier, stock quantities at the starting moment, account balances. This is not history; it is the zero point the system starts from. Pick one specific date for it and hold to it.
• Third: open transactions only. What is live right now — orders not yet delivered, invoices not yet collected, purchase orders not yet received. This is what the team touches daily, and it is far smaller than you imagine.
• Last, and possibly never: the historical archive. Closed invoices from prior years.

The historical archive: the question that saves you weeks

The single largest consumer of time and money in a migration is the insistence on carrying the company's entire history into the new system. The question that must come before that decision: what will you actually do with that history?

If the answer is we need it to look things up or for a statutory review, the archive already performs that function as it stands — preserved in its original format, in a known and searchable place. Your statutory obligation is to retain invoices and records and to be able to produce them on request, as set out by the Zakat, Tax and Customs Authority, not for all of them to live inside the new system specifically.

If the answer is we want reports comparing this year against previous years, then you need part of the history, not all of it, and usually at a summarised level rather than every invoice line. The difference between those two migrations is large in both effort and cost.

The working rule: move the history you will build a decision on, and keep the rest as an archive. Do not make archive migration a precondition for going live — it can be done later without pressure, while going live cannot be deferred indefinitely.

Parallel running: necessary, and dangerous if left open

Parallel running means recording transactions in the new system and the old file at the same time for a defined period. It has one specific purpose: to confirm the system produces the same results you already know. You compare the week's sales total, customer balances, the quantity of an item or two. If the numbers match, the system is behaving; if they diverge, you know it before anyone builds a decision on a wrong figure.

But parallel running has a real cost: your team works twice. That cost is acceptable for two weeks and destructive over three months. The danger is not only the effort. Double entry starts to slip after a while — someone records in one place and postpones the other — so the two copies drift apart and the exercise loses its meaning entirely, because you no longer know which one is right.

So the only rule that matters here: parallel running with an end date declared to everyone from day one. Write the date down, tell the team, and extend it only by an explicit decision with a written reason — never by drift. An open-ended period is not caution; it is a deferred decision, and it is the most common way a new system stays half-used for a full year. This sits inside the change-management work covered at length in our guide to implementing a system in phases.

The Origami view

When we build a custom system for a company running on spreadsheets, we treat the migration plan as part of the design, not as an execution step at the end of the project. The reason is that migration order forces decisions about the structure of the system itself: which entities must stand alone, which fields must tolerate being temporarily incomplete, and where we need repeatable imports that do not duplicate records.

We also fix the date the old file closes with the client before we start, because that date is what turns the project from a parallel experiment into an actual transition. It is the same approach we take in phased digitisation roadmaps, and it extends across our services: every phase delivers something that works, not a promise that everything will work at the end.

The signal that tells you the move succeeded

You will not learn whether the transition worked from a completion report or a migration percentage. You will learn it from a behaviour nobody was asked for: an employee stops opening the old file without being told to. When the system becomes the thing they open first thing in the morning because it is the faster route to what they need, the move has genuinely happened. When they keep opening the file every morning despite everything being migrated, the move has not happened yet, whatever the progress figure says.

Watch that signal rather than the numbers. And if you find people going back to the old file, the reason is usually not resistance — it is that the system does not give them something they need, or gives it slowly, or in more steps. That is a fixable cause, but only if you see it early and ask about it.

In the parts ahead

The data has moved in the right order, and a question appears that did not exist in the world of files: whoever opens a file sees everything in it, whereas a system decides who sees what. The next part is about permissions — payroll, margins and customer data, and who gets to see each. Then we move to the reports you used to build by hand every month, and close the series with the first thirty days after the move.

Sources

• Zakat, Tax and Customs Authority — e-invoicing requirements and the retention and production of invoices and documents.
• Saudi Data and AI Authority (SDAIA) — the Personal Data Protection Law and controls on handling personal data during transfer and storage.
• Ministry of Human Resources and Social Development — requirements for retaining employee records and data.
• Ministry of Commerce — provisions governing commercial books and records for establishments.
• National Cybersecurity Authority — controls relating to data protection and backup.