Moving off a job spreadsheet without losing four years of history

Ask a trader why they haven't moved off their spreadsheet and you rarely get "I like the spreadsheet." You get some version of: there are four years of work in that file and I don't know what happens to it.

Fair. It's the record of everything you've done. It's also, almost certainly, the wrong thing to be worrying about, because most of it should not come with you.

Your sheet is three documents wearing a coat

Open the average trade job sheet and you'll find three different things sharing a set of rows.

A history. Everything finished and paid, going back years. Dead weight in the working sense, but you keep it, because records have to be kept and because occasionally somebody rings about a job from 2023.

The live list. What's actually happening: quoted and waiting, booked in for next week, done but not invoiced, invoiced and unpaid. This is the part you look at. It's also, in most cases, the part you keep half in your head anyway, because the sheet is on the laptop at home.

Some totals. A row at the bottom, or a second tab, adding up the year for the accountant.

These need completely different treatment, and the reason migrations feel enormous is that people plan to move all three. You need to move one.

Move the live list. Only the live list.

Count the rows that are genuinely in flight — anything not finished, plus anything finished that hasn't been paid for. For a sole trader that's usually between ten and thirty. For a small team it might be sixty.

That is the migration. Not four years. Thirty rows.

It's worth doing that count before anything else, because it changes what the job feels like. "Move my business onto new software" is a weekend you keep not having. "Type thirty jobs in, or export them and upload the file" is an afternoon, and you can do half of it on the sofa.

Leave the history where it is

The instinct is to bring everything so it's all in one place. Resist it, for two reasons.

The first is that history in a new system is actively misleading. Anything that shows you what you're owed, what you've invoiced this month, or which job was your biggest is doing arithmetic over whatever rows exist. Load four years of completed work in and those numbers stop describing your business now. You end up with a dashboard reporting on 2023 and no easy way to tell it not to.

The second is that the old sheet is already a perfectly good archive. It doesn't need converting. Save a copy somewhere it can't be edited by accident, label it with the date you stopped using it, and that's the job done. Records need to be kept, and they need to be readable — they don't need to be in your current software.

If a particular old job genuinely matters — a customer you expect back, a property you'll re-inspect — enter that one by hand. There will be a handful. There will not be four hundred.

Don't run both

This is the one that actually kills migrations, and it's the plan almost everybody makes: keep the spreadsheet going as well, just for a bit, until you're sure.

It sounds careful. What happens is that you maintain two records, badly. Something goes in the sheet because the sheet is habit, and doesn't go in the new system. A week later the new system looks wrong — because it is wrong, because half the week never reached it — and the sensible-seeming conclusion is that the software isn't working. So you go back to the sheet, having proved nothing except that doing everything twice is annoying.

Pick a date. The morning of that date, the sheet is an archive. Everything from then on happens in one place, including the bits that are awkward at first.

Two weeks is enough to know. If it's genuinely worse, you go back, and the cost is re-entering a fortnight of rows from your own invoices — not your business records, which are still sitting in the archived sheet exactly where you left them.

When you should stay on the spreadsheet

Genuinely: if it's working, keep it.

A sheet you built and understand beats software you resent. If you're running a handful of jobs at a time, you know every customer's name, nothing is going out late and nobody is chasing you for an invoice you already sent, then your system works and this whole category is an answer to a question you aren't asking. There is no maturity ladder here, and paying a subscription doesn't make anyone more professional.

Spreadsheets are also better than software at some things, permanently. Anything one-off — a costing you want to model three ways, a quick answer for the accountant, a column that matters this month and never again. No product will let you invent a column in nine seconds. Keep a sheet for that sort of thing forever if you like; plenty of people run both, deliberately, with the sheet used for thinking rather than for tracking.

What a sheet cannot do is more specific than "be professional":

• It cannot tell you a quote has been sitting unanswered for eleven days. It has no idea what today is, and no view of what you sent.
• It cannot send anything — not a quote, not an invoice, not a reminder. Every one of those is you, at a keyboard, remembering.
• It is on one device. On a phone in a loft it is technically openable and practically useless, which means the van and the sheet hold different truths until Sunday.
• Two people cannot both keep it current. The moment a second person is involved you are merging versions by shouting.

If two or three of those are costing you real money — most often the first and the second, in the shape of quotes that went cold and invoices sent a fortnight late — that is what you would be buying. Not tidiness.

The one thing that quietly loses information

If you are going to export the sheet rather than retype it, there is a specific failure worth knowing about, because it is nearly universal in trade spreadsheets and it is invisible until it has already happened.

Colour is not data. If your sheet uses fill colour to mean something — yellow is waiting on the customer, green is paid, red is a problem — it works beautifully on screen and survives nothing. Export to CSV and the colour is gone with no warning and no error; you get the rows and lose the single most useful column, which was never a column.

The same goes for anything else the sheet knows by convention rather than by content: a row's position meaning it's urgent, a strikethrough meaning cancelled, a bold customer name meaning they're difficult. All of it is real information, none of it is in the file.

So before you export, spend ten minutes turning the conventions into a column. Add one called Status, fill it in from the colours, and then the export carries what you actually knew. While you're there:

• One row per job. Not one row per visit with the job name repeated, and not a job split across two rows because it needed two lines of notes.
• One thing per cell. £450 paid 12/3 cash is three facts in one box, and anything reading the file gets none of them. Separate columns for amount, date and how it was paid.
• Headers in the top row, plainly named. Junk rows above the headers are common in exports from other software and are usually handled, but they're one more thing to go wrong.
• Dates in one format. Pick either 12/03/26 or 12 March 2026 and be consistent. Mixing them is how a March job lands in December.

None of this is required. It is just the difference between an import that carries what you knew and one that carries what you typed.

The practical bit

If you've decided to move, the order that works:

1. Count your live jobs. The real number, in flight today. That's your migration.
2. Set up the boring things first — your business details, your tax rate, your standard prices. Ten minutes, and it means the first quote you build isn't also a configuration exercise.
3. Get the live jobs in. Either type them, if there are twenty, or export the sheet and upload it.
4. Archive the old file with the date you stopped.
5. Do the next real job entirely in the new place, start to finish — quote, book, invoice. One complete lap teaches you more than an afternoon of clicking around, and it's the only way to find out whether it fits how you actually work.

On step 3: grafter.ly takes a .csv or .xlsx straight from a spreadsheet or another product's export, reads the columns, and shows you what it found — how many jobs, how many customers, which ones it has marked as paid — before anything is created. Nothing is written until you say so, and if it comes out wrong you can remove the whole import in one go; anything you've already worked on since is kept rather than deleted.

That's the part where a migration usually goes wrong, so it's the part worth being fussy about: you should always see the interpretation before it becomes your data. You can try it free for 30 days, no card to start.

---

Still deciding rather than moving? How to choose job management software covers what actually differs between these products, and is it worth it when it's just you makes the case for staying put where staying put is right.