The short answer
Move open orders only. Export everything closed once, date the file and archive it where your accountant can reach it. Start new orders in the new system and let the open ones finish where they are — no cutover day. Delete nothing for three months. Done this way it is an afternoon, and nothing is lost, because almost none of what you were afraid of losing needed to travel.
Almost every attempt to leave a spreadsheet dies in the same place, and it is not choosing the tool. It is the moment you open the sheet to start moving things and see three years of rows looking back at you.
The pattern from there is reliable. You start with 2024, hit a column called status 2 that nobody can explain, decide the sheet should be cleaned up first, and three weeks later the new tool is empty and the sheet is still running the business.
The mistake is not choosing badly. It is treating a migration as a data problem when it is a scope problem.
Why the history is the trap
History feels valuable because it was expensive to produce. But ask what you would actually do with a 2024 order inside a new system: it is delivered, it is paid, and no decision this year depends on it. Its remaining job is to be findable if the tax office or your accountant asks, and a dated CSV does that job perfectly.
Meanwhile the rows that carry real weight are the fifteen open orders with money still moving through them, and those are the ones that a three-week cleanup project delays.
What moves: seven fields per open order
This is the whole list. If a field is not on it, it does not need to be in the new system on day one.
- Customer. Name and one way to reach them.
- What it is. A description you will recognise in three months without opening a chat.
- Total price. The agreed figure, including whatever you agreed about tax and delivery.
- Deposit received, and the date. The date matters more than it looks the first time you have to reconstruct something.
- Balance outstanding. The number that makes the system useful on day one rather than in a month.
- Promised date and current status. Even approximate. Especially approximate.
- Production cost, if you know it. If the workshop has not invoiced yet, leave it empty and fill it when the invoice lands.
Fifteen open orders at seven fields is an afternoon of typing with a podcast on. That is the entire technical component of the project.
What gets exported once and frozen
Everything closed. Export it to CSV, put the date in the filename, and store it somewhere that is not the same account as the sheet — a folder your accountant can already reach is ideal.
Two categories are worth pulling out of that archive before you file it, because they are the only parts of your history that still make decisions:
- Recent batch costs. Your only reference for estimating the next one. If they live only in supplier invoices in a folder, they effectively do not exist.
- Promised dates against actual delivery dates. The one dataset that tells you whether your lead times are honest, and nobody has it unless they kept it.
Neither has to enter the new system as records. They need to be readable in a year, which is a different and much cheaper requirement.
There is no cutover day
Businesses with IT departments plan a switchover weekend. A two-person workshop should not, because the cost of getting it wrong lands entirely on the two people, on a Monday, with customers waiting.
The alternative is simpler and almost boringly effective:
- From a chosen date, every new order is created in the new system and nowhere else.
- Open orders finish wherever they are today. If one has months to run, move that one across by hand.
- When the sheet has no open orders left, it is finished. That usually takes six to eight weeks and requires no decision from anyone.
The one rule that prevents the classic failure
For new orders there is exactly one source of truth, decided on day one and not revisited. Every abandoned migration has the same middle chapter: someone kept updating both "just for now", the two stopped agreeing within a fortnight, and the new system became the one that was wrong.
Delete nothing for three months
Freeze the sheet — rename it, mark it read-only, move it out of the way — and leave it there for a quarter. Keeping it costs nothing. What it buys is the ability to answer "that balance looks wrong" by checking the original rather than by arguing from memory.
Deleting early converts every small doubt in the first weeks into a real problem, and the first weeks are exactly when small doubts happen.
The whole thing, as an afternoon
- Export the sheet to CSV. Date the filename. Archive it.
- Filter to open orders. That is your migration list, and it is short.
- Enter them with the seven fields. Leave costs blank where you do not have them.
- Check one number: total balance outstanding across open orders, in the new system against the sheet. If they agree, the data moved.
- Set the date from which new orders go in the new system only. Tell anyone else who enters orders.
- Freeze the sheet. Do not delete it. Put a reminder three months out.
Step four is the one people skip and the one that makes the rest trustworthy. One number, checked once, and you never have to wonder again whether something got lost in the move.
Open orders, deposits, balances and what each piece cost — in one place, from an afternoon's typing.
See how it worksMove it, archive it, or leave it
When something is not on this table, the default is archive. It is the cheap answer and it is almost always the right one.
| Move it | Export and archive | Leave it behind | |
|---|---|---|---|
| Open orders with money outstanding | Yes | — | — |
| Deposits taken, with dates | Yes | — | — |
| Promised delivery dates and status | Yes | — | — |
| Delivered and fully paid orders | — | Yes | — |
| Batch costs from past production | Recent ones | Yes | — |
| Customer contact details | Active ones | Yes | — |
| Build notes nobody has reopened | — | — | Yes |
| Columns whose meaning is lost | — | — | Yes |
Tell your accountant before, not after
One short message, and it prevents the only genuinely awkward version of this: your bookkeeping stops looking the way it did halfway through a financial year, and nobody warned the person who has to close it.
Say what changed, from which date, and where the archived export lives. That is the whole conversation. It also surfaces early whether they need anything in a particular format, which is much easier to hear now than in March.
What actually takes the time
Not the typing. The habit. A system is working when a deposit gets recorded the day it arrives and a cost the day the invoice comes in, without anyone reminding anyone.
If in week three you are catching up in a batch to get current, the migration technically happened and the habit did not — and that is the state where a system starts quietly lying, because it is half-current and looks complete. Better to notice it early and record less, honestly, than to keep a full-looking record nobody trusts.
One thing worth settling first
Migrating well into the wrong category of tool is still a wasted migration. What is actually in the custom order software category separates the families, and the five signs a spreadsheet has stopped working is the honest test of whether it is time at all. If the sheet is still answering your questions, this whole article can wait.
The bottom line
Leaving a spreadsheet is a small job that people turn into a large one by deciding that three years of rows have to come along. They do not. Open orders move, the rest is exported once, new work starts in the new place and the sheet retires on its own.
Nothing is lost by not migrating history. Things are lost by spending three weekends on it and giving up.
Frequently asked questions
Do I have to move all my history?
No, and believing you do is what kills most attempts. Open orders need to move, with their deposit, balance and dates. Closed ones are reference: export them once, keep the file where your accountant can reach it, and leave them there. You are not going to query a delivered and paid 2024 commission inside a new system.
Should I switch over in one weekend or gradually?
Gradually, for a small workshop. Start new orders in the new place and let the open ones finish where they are. In six to eight weeks the sheet empties itself and there was never a cutover day to plan, staff or get wrong.
What if I change my mind halfway through?
That is exactly why nothing gets deleted for the first three months. Freeze the sheet, do not remove it. If a number looks wrong in the new system you still have the original to check against, and a doubt stays a doubt instead of becoming a problem.
How do I avoid entering everything twice?
Decide on day one which place is the source of truth for new orders, and then do not negotiate with yourself about it. Double entry is what happens when nobody made that call, and it is the single most common reason a migration is abandoned in week three.
What fields do I actually need for an open order?
Customer, a description you will recognise, total price, deposit received with its date, balance outstanding, promised delivery date and current status. Batch or production cost if you have it; if you do not, it goes in when the workshop invoices you.
How long does this really take?
Entering ten to fifteen open orders is an afternoon, not a weekend. What takes weeks is the habit — recording a payment the day it arrives rather than at the end of the month. The typing is never the hard part.
My sheet has columns no tool will accept. What do I do with them?
Read them before you decide. Long build notes and one-off comments are usually the columns in question, and most of them have not been read since the day they were written. What matters becomes an order note; the rest existed because a column was free, and carrying it forward is work with no reader.