When it's time to leave spreadsheets, how to work out a budget, how to design a data model and how to migrate without stopping the company for a month. A complete guide to the whole process, from first thought to first month live.
Most companies don't start looking for their own system because they want new software. They start because something got lost twice, someone forgot to invoice, or nobody can answer what a job actually earned.
This guide runs through the whole process, from that first dissatisfaction to the first month of live use. Each chapter covers the essentials and links to a detailed piece if you want to go deeper.
1. How to tell it's time
There are four fairly reliable signals. Two of them are enough:
The spreadsheet has more than one editor. The moment two people write into the same file, you start arguing about which version is current. That problem can't be solved with discipline.
Data exists in several places and doesn't agree. The client is in the CRM, their job in the project tool, hours in a spreadsheet, the invoice in accounting. Any question crossing a boundary takes half a day.
Something fell through. A forgotten invoice, a missed deadline, a promise to a client that wasn't kept. Once is chance; twice is a systemic fault.
One person leaving would mean losing the overview. When the process lives in someone's head rather than in a system, that's a risk that grows with the company.
In detail: When a spreadsheet stops being enough and What fragmented tools cost a company.
2. Why you have three systems in the first place
Almost nobody chose a fragmented stack. It accumulated: the CRM arrived with the second salesperson, the project tool with the first larger delivery, the spreadsheet for money because neither could work out margin.
Every one of those steps was right at the time. The problem is the sum - and above all the work that arises on the boundaries between them. Retyping, hunting, monthly reconciliation. None of it appears on any invoice.
Nobody chose this. It accumulated.
Each tool solved one problem and created one boundary. The work that happens on those boundaries appears nowhere.
In detail: CRM, ERP, project tool: three systems that don't talk.
3. Four routes and what they really cost
Once the decision is made, the question is how much. There are four routes:
| Route | Entry cost | Who makes changes | Main risk |
|---|---|---|---|
| Off-the-shelf software | Low | Nobody (you can't) | The process bends to the tool |
| Custom development | Highest | The supplier | Supplier dependency |
| Freelancer + AI | Middling | One person | Person dependency |
| No-code platform | Lowest | Anyone on the team | Platform dependency |
The key is not to look at the first invoice but at the three-year total. The entry price is the one you're quoted; years two and three decide.
The budget also has to include items that are never in a quote: rollout and training, changes (not “in case”, a certainty), operations, and the risk of losing the person who knows the system.
In detail: What a custom app costs in 2026.
4. Designing the data model - the one part you can't skimp on
This is where it's decided whether the system will still be usable in two years. It isn't technical work; it's work on your process.
Start with entities. Write down the nouns you use in the company: client, job, quote, invoice, technician, timesheet, document. Those will be your databases.
Work out the relations. A client has many jobs. A job has one quote and several timesheet entries. An invoice belongs to a job. This step surfaces most of the misunderstandings in a team - it often turns out two people meant two different things by “job”.
Keep the model smaller than you want to. The classic mistake is designing fifteen databases upfront. Start with three that cover the main flow and add as need proves itself.
Test it with a question. A good model shows itself in the team being able to take the next step from it - raise an invoice, send a handover report, calculate a margin. Not in having every column.
In detail: A data model that grows with your team.
5. Who sees what
Permissions often get deferred and that's a mistake - they have to hold in every view, export and email the system sends.
Three questions are enough to answer upfront:
- Who should see sensitive fields (prices, margins, personal data)?
- Who should only read and who should also edit?
- What, if anything, should be visible outside the company?
The answers translate into a role structure you set up once and that applies everywhere. Keep two different things apart: hiding a column governs “what they see inside a record”, restricting database access governs “which records they can reach at all”.
In detail: Access rights and data visibility.
6. Migrating without a big bang
Nobody can switch off three systems on a Monday. A proven approach has three phases:
Phase 1 - one boundary. Find the place that hurts most (usually sales ↔ delivery or delivery ↔ money) and build a shared foundation for that alone. Clients and jobs in one place.
Phase 2 - attach what belongs with it. Timesheets, documents, correspondence. At this point most companies find they no longer need half their spreadsheets.
Phase 3 - switch off the old. Not before a few weeks of running in parallel. Mark the old spreadsheet read-only first and archive it only afterwards.
What not to migrate: the entire history. The last year is usually plenty; the rest only clutters your views.
In detail: Migrating from Excel or Notion.
7. Automations last
A common temptation is to switch on automations on day one. Better to wait until the system has run for a few weeks - only then do you know which steps genuinely repeat.
The first automations that almost always pay off:
- watching for jobs that are finished and have no invoice,
- a reminder a few days before a deadline,
- an alert about missing timesheets at the end of the week,
- creating a record automatically from an incoming enquiry.
In detail: Automation: the complete introductory guide and Automating business processes.
8. The first month live
What to realistically expect:
Week 1. People complain it was faster in the spreadsheet. It was - for one person. Hold your nerve.
Weeks 2–3. The first change requests appear. That's a good signal, not a bad one: it means people are using it. Make the changes promptly.
Week 4. The first moment arrives where somebody finds an answer they'd previously have hunted for half an hour. That's usually where it turns.
What to measure: not satisfaction, but whether a spreadsheet is still appearing alongside the system. If it is, something in the system is missing - and that spreadsheet is a precise instruction on what.
Common questions about introducing a business system
How long does the whole migration take?
The first boundary tends to be days to a couple of weeks. A full move for a twenty-person company usually one to three months - not because the technology is slow, but because people adjust gradually.
Who should own this internally?
One or two “workspace admins”, typically someone from operations or the back office who understands the process. Not necessarily the most technical person - rather the one who best knows how the work actually flows.
What if it turns out we designed the model badly?
That happens almost every time and it's fine. On a no-code platform, fields, statuses and relations change while you're running. In a developed app, changing the data model is a job for a developer - which is exactly why this property matters more than any feature on a list.
Do we have to abandon our accounting package?
No. Accounting has its own legal obligations attached and usually stays where it is. Consolidation makes sense for operational data: clients, jobs, deadlines, timesheets, documents.
How do we win over a team that doesn't want to change?
Best of all by making the first thing the new system fixes something that annoys them. Not reporting for the owner, but an end to hunting or an end to retyping. The rest follows.