The First Thirty Days After the Move: What Breaks

The First Thirty Days After the Move: What Breaks

Part six dealt with the report: how it stops being a file you assemble over two days and becomes a view you open onto the current moment. That completes the picture we have built across six parts — when a spreadsheet stops being the answer, which file actually runs the company, cleaning the data before moving it, the order things move in, who sees what, and the end of the hand-built report.

What remains is the part that decides whether any of it pays off: the first month in production. And here is something everyone who has run a project like this knows. Most migrations do not fail during the build. They fail in the first few weeks of use. The system works, the data is there, the screens are correct, and yet the real work quietly drifts back to the old file. This part is about why that happens and about a plan that prevents it.

Resistance is not stubbornness, it is risk arithmetic

The first thing you meet in week one is hesitation from the team. The common mistake is for an owner to read that hesitation as resistance to change or laziness and to answer it with pressure. It is usually neither.

The employee who used to open a file and finish the task in two minutes now needs ten to learn the path through the same screen. From where they stand, they are paying today's cost for a benefit they have been told about but cannot yet see, and they answer to their manager for today's output, not for the project's success. The hesitation is entirely rational.

It intensifies when the owner of the old file is someone whose standing in the company was built on knowing it. Whoever was the single reference for a file may fear the system makes their role redundant. Ignoring that fear does not remove it; it pushes it underground. Addressing it directly works better: give that person a declared role in the new arrangement as the owner of data quality in their area, so they move from guarding a file to being the reference for the data itself.

The genuine change in month one is that work has become visible. When data lived in a file, a late entry was invisible. In a system, who recorded what and when is on the record. That is reassuring to anyone who works consistently and uncomfortable for anyone used to flexibility, and it is better said openly in the first meeting than discovered two weeks in.

The quiet return to the old file

The most dangerous thing in month one does not happen loudly. Nobody objects to the system in the meeting, but a copy of the old file stays open on somebody's machine and they record in it because it is faster, intending to enter it into the system at the end of the week. Usually they do not.

That produces the worst possible outcome: two sources of truth instead of one. Before the project you had a single inaccurate file that everyone agreed was the reference. Now you have an incomplete system and an incomplete file, and nobody knows which is more recent. You are worse off than where you started, and this is one of the patterns covered in Why ERP Projects Fail and How to Make Yours Succeed.

The signals appear early if you look for them: a figure quoted in a meeting that does not exist in the system, a file shared in the team chat two weeks after launch, an employee who asks to export the data to work on it outside and never brings it back. Do not treat any of these by blaming the person. Ask one question: what was the file giving them that the system does not? The answer is normally a missing step, an absent field, or a path longer than it needs to be — all fixable in days once you know about them.

The gaps that surface after the move, not before

However well you cleaned the data beforehand, as part three set out, gaps will surface that could only have been found at the first real transaction. The logic is straightforward: the file tolerated emptiness, so a blank cell stayed blank and nothing stopped you issuing the invoice. The system asks for the field because a later step depends on it.

What usually shows up at this stage:

• Incomplete counterparty records. A customer held by name alone, with no tax number, address or documented contact, all of which used to be asked for verbally when needed.
• Opening balances that do not reconcile. The opening figure for a customer or an item disagrees with what the old file says, and the difference surfaces on the first statement.
• States that were never classified. A pending order, a partial payment, a return that was never closed. In the file they were a note in the margin; in a system they need a defined state.
• Multiple units and prices. An item sold by the carton and bought by the unit, priced differently for one customer tier than another, all of it held in the sales lead's head rather than written down.
• Exceptions with no rule behind them. A customer on special terms for years with no document, so nobody knows how to define it in the system or who has the authority to approve it.

None of this is evidence that the migration failed. It is the first real benefit of it: the system exposed what the file was hiding. But handling it takes discipline. Record every item on one declared list, with the person who owns the answer and a date for closing it. Handle each case separately in a side conversation and it will come back next month in another form.

Training delivered once is not enough

The most repeated pattern in struggling projects is training given as a single session on launch day, attended by everyone, walking through the whole system end to end. Everyone then returns to their desk having forgotten most of it, because they heard it before they needed it.

The alternative that works rests on three principles:

• Train the role, not the system. The accountant does not need warehouse screens and the sales lead does not need permission settings. Each team learns the path it will walk daily — shorter and far more focused.
• Repeat after a week of use. The second session is the one that earns its keep, because the questions in it are real ones drawn from daily work rather than hypothetical. And questions repeated across teams tell you exactly where a screen is unclear.
• Document with pictures, not prose. One page per role with the steps in order and screenshots, pinned up or sent out. Most questions after launch are recall questions, not comprehension questions.

You also need one person inside each team who is asked first, because an employee asks a colleague before opening a support ticket. That informal role shortens response time more than any external support channel. This kind of change management is not unique to leaving spreadsheets behind, and we covered it as part of the implementation phases in How to Implement an ERP Successfully.

The Origami view

We treat launch day as the midpoint of a project, not its end. A system does not take hold in a company merely by working; it takes hold when it becomes the shortest route to getting the day's work done. Every day the old path stays faster than the new one is a day working quietly against the project.

So in the first month we keep a declared list of observations with dates for closing them, and we measure actual usage rather than impressions: who logs in, which transactions are recorded as they happen, and where a screen stalls people. That is what we apply when building custom systems as part of our services, because fixing a small stall in its first week costs an hour, while fixing it after two months costs the confidence of an entire team.

A thirty-day plan

This is a plan you can run as written, and its most important feature is that every stage has a declared end:

• Days 1-7: bounded parallel running. Work is recorded in both the system and the old file for one reason only — comparison. At the end of the week take a small sample, compare the two figures, and log every difference by its cause rather than its size.
• Day 8: the old file goes read-only. This is the single most important step in the plan. The file stays available to look at and nobody writes to it. Without a declared closing date parallel running continues indefinitely, and it always ends with the old file winning because it is easier.
• Days 8-14: second training and closing gaps. A short session per team on the questions that actually came up, and closure of the top five items on the gap list.
• Days 15-21: measure usage. Review who is genuinely using the system and who is not, and for every transaction recorded late, ask why. What you learn is a signal about how clear the path is, not about individual discipline.
• Days 22-30: stabilise and review. Close the remaining observations, produce the first monthly report from the system alone, and sit with team leads for half an hour to identify what is still happening outside the system and why.

The honest measure of success is not team satisfaction in a survey or the number of screens in use. It is a single moment: someone stops opening the old file without being asked to. At that point the system is no longer a project you are managing — it is how the company works.

Closing the series

Across seven parts we have walked the whole route: the signals that a spreadsheet has passed its limit, the inventory that tells you which file is really your system, cleaning the data, the order things move in, setting permissions, turning the hand-built report into a live view, and finally getting through the first month.

The conclusion worth keeping is this. Excel is an excellent tool, and the problem was never the tool but what it was asked to carry. Moving to a system is less a technical upgrade than a decision that the company's data belongs to the company rather than to a file or a person. And it starts with one small step: open the file that runs your company today and ask who updates it, when, and what happens if they are away.

Sources

• Saudi Data and AI Authority (SDAIA) — the Personal Data Protection Law and obligations toward data once it moves into new systems.
• Zakat, Tax and Customs Authority — e-invoicing requirements and the retention and production of documents on request.
• Ministry of Human Resources and Social Development — provisions governing employee records and the retention of their data.
• Ministry of Commerce — provisions governing commercial books and records for establishments.
• Small and Medium Enterprises General Authority (Monsha'at) — programmes enabling establishments to adopt management and digital transformation tools.