Leaving Spreadsheets Behind: An ERP Migration Plan That Survives Contact With Reality
Most failed ERP migrations were planned as one event. The ones that work are planned as a sequence, with the business running normally throughout.
Business Transformation3 min read
Spreadsheets do not fail loudly. They fail by quietly becoming the only place a critical number lives, on one person's laptop, with a formula nobody else understands. By the time that is obviously a problem, the business is dependent on it.
Replacing that is less about software selection than most vendors would like you to believe.
Move the process, not the file
The common mistake is treating migration as data transfer: export the spreadsheet, import to the system, done. What you get is the same workflow with more clicks, and a team that quietly keeps using the spreadsheet as the real record.
The useful question is not where does this data live but what decision does it support. A stock sheet exists so somebody can decide what to reorder. If the new system does not make that decision easier, it has not replaced anything.
Sequence, do not switch
A phased order that works for most small and mid-sized businesses:
Phase 1 — the money. Quotes, invoices, payments. This is where errors are most expensive, where the regulatory pressure already sits, and where the benefit is easiest to demonstrate. It also forces your customer master data to get clean, which every later phase depends on.
Phase 2 — the pipeline. Leads and deals, connected to the invoicing you just fixed. Now a closed deal becomes an invoice without re-keying, which is usually the first moment the team feels the system giving something back.
Phase 3 — delivery. Projects, inventory or service jobs, depending on your business. By now you have clean customers and real transaction history, so the operational module has something to attach to.
Phase 4 — reporting. Deliberately last. Dashboards built on immature data teach people to distrust the system, and that distrust is very hard to reverse.
The cutover decisions that matter
Do not migrate history on day one. Move open items — unpaid invoices, active deals, current stock. Historical records can be imported later or kept in read-only form. Teams that insist on full history usually delay cutover by months and arrive with dirtier data.
Pick a date with low volume. The start of a quiet week beats the end of a quarter.
Run parallel for one cycle, not three. A single billing cycle in both systems is a reasonable safety net. Longer than that and people simply keep working in the old one.
Name an owner per module. Not IT — the person who actually runs that process. They approve the configuration and they answer questions afterwards.
What to demand from any vendor
- Your data exportable in a usable format, on request, without a support ticket.
- Arabic and English in the same instance, including on printed and exported documents.
- A path to compliant e-invoicing that does not require re-entering data by hand.
- Configuration your own team can change — stages, fields, templates — without paying for a change request each time.
That last point decides your cost over three years far more than the licence price does.
The honest trade-off
An ERP will make some things slower. Structured data entry takes longer than typing a row into a sheet. What you buy with that time is that the number is the same for everyone, retrievable when the person who knew it is on leave, and auditable when somebody asks how it was calculated.
If your team cannot articulate what they are getting for that friction, the rollout will fail regardless of how good the software is.
Weighing an ERP move and want the phasing mapped to your actual operations? Start a project.