Skip to Content

Spreadsheet to ERP Migration: The 30 Day Plan That Actually Finishes

Pick one process, load less data, run parallel for two weeks, then switch off. The plan that actually gets done.

Every owner I speak to gets to the same sentence eventually. We know we have outgrown the spreadsheets. Then nothing happens for another year, because a migration sounds like a project that eats a whole quarter and nobody has a spare quarter lying around.

It does not have to be that. A spreadsheet to ERP migration is only slow when you try to move everything at once. Move one process properly and the rest follows on its own momentum. Here is the thirty day version that actually finishes, and you can start the first step this afternoon.

Pick the one process that costs you money when it breaks

Do not start with the org chart or the module list. Start where the money leaks. For most small and mid sized businesses it is one of three places: leads that never get followed up, quotes that never turn into invoices, or stock numbers nobody trusts.

Pick one. Just one. If you are not sure which, ask which spreadsheet somebody opens every single morning. That is the file holding the business together and that is the one to move first.

This is not about tidiness. A system that fixes something painful in week two gets used. A system that arrives complete in month six gets ignored, because by then everyone has built a workaround, and the workaround is a spreadsheet.

Write down what is true before you touch any software

Take an hour with the person who actually runs that process, not the person who owns the company. Ask them to walk one real record from start to finish while you write the steps in plain language.

You are looking for three things. The stages a record passes through, the fields somebody genuinely uses to make a decision, and the moments where a human has to be told something happened. That last one is where the value hides. Most of the pain in a manual process is not the typing, it is that nobody knows a thing has gone wrong until it is already late.

You will find the process has far fewer real stages than the spreadsheet suggests, and that a handful of the columns are decision fields. The rest are notes, colour coding and something a former employee added years ago that nobody has dared delete.

Load less data than you want to

This is where migrations die. Somebody decides all history has to come across, then spends three weeks cleaning years of inconsistent company names and loses the will to continue.

The rule I use is simple. Bring across everything currently open, plus the master records you need to work: customers, products, suppliers. Everything closed goes into one archive file, stored and searchable, not imported. If you truly need a closed record from three years ago you can find it in the archive in half a minute. That is a fair trade for three weeks of your life.

Clean the master data before it goes in, never after. Deduplicate the customer list, fix country and currency, put every phone number into international format so a dialer or a WhatsApp integration can use it later. Dirty data that lands in a new system does not get cleaner, it just gets copied.

Run both for two weeks and let the spreadsheet lose

Parallel running scares people because it sounds like double work. Do it anyway and keep it short. Two weeks, one process, no exceptions.

The point is not safety. The point is that in those two weeks you will find the four or five small things nobody mentioned in the walkthrough. The discount someone applies by hand. The customer invoiced under a different legal name. The approval that happens verbally in a corridor.

Fix each one in the system as it appears. By the end of two weeks the system does everything the spreadsheet did plus the things the spreadsheet never could, and the team has already stopped opening the old file because the new one is faster. That is the moment a migration is actually won, and it comes from daily use, not from a training session.

Put the switch off date in writing

Pick a date, send it in an email, and name the person who owns the process after that date. Without this you get a permanent hybrid where half the team uses the system and half keeps a private copy, and a hybrid is worse than either option because now nothing can be trusted.

On the switch off date, move the spreadsheet to a read only folder. Do not delete it. Nobody needs to feel their safety net was cut, they just need to stop editing it.

The three things that sink most migrations

The first is buying by feature list. Every system demos beautifully. What matters is whether your real process fits it without heavy customisation, which is exactly why you write the process down first and then demo against your own steps with your own data. A demo using the vendor sample company tells you nothing about your business.

The second is nobody owning it. A system with no named owner drifts back to spreadsheets within a quarter. The owner does not need to be technical, they need to care that the data is right and have the standing to tell someone to fix a record.

The third is treating training as an event. An hour of group training teaches almost nothing. Ten minutes with each person inside their own real work in their first week teaches everything, because they are learning the two screens they will live in rather than the whole product.

Hold off on the dashboards

Reporting built on two weeks of clean, real usage is honest. Reporting built on imported history is usually a beautiful chart of how badly the old spreadsheet was maintained. Give it a month of proper use, then build the three numbers the owner genuinely looks at and stop there. A dashboard nobody reads is a cost, not an asset.

What to do today

Open the spreadsheet somebody touches every morning. Write its real stages and its decision fields on one page. Split the data into open records and closed history, and put the history in an archive you are not going to import. Then book an hour with the person who runs the process and walk one record end to end.

That is day one, and it is the part almost everyone skips, which is exactly why their migration takes six months instead of thirty days.

If you would rather have this built once and built properly, on your own domain with your own logo and your own process inside it, that is what we do at Talent Alliance Hub. Tell me the one spreadsheet that hurts most and I will tell you honestly whether it is a thirty day job. Get in touch.

Related reading

If this was useful, you may also want what an Odoo implementation actually costs, UAE e-invoicing for SMEs and what to fix before July 2027 and what a CRM setup actually costs a small business.

What an Odoo Implementation Actually Costs, and Where the Money Really Goes
The licence is the small part. Here is what actually moves an Odoo quote, and how to scope a first phase you can say yes to.