Why migration is the step that decides success
A new system with empty or wrong data is worse than the spreadsheet it replaced. People open it, can't find their client, and go back to the file they trust. Within weeks, the new system is abandoned.
That's why migration isn't a technical afterthought. It's the moment the company decides which version of the truth to keep. Our guide on replacing Excel with business software covers when and why to switch. This article is about the move itself.
Who needs to be involved
A migration can't be done by the builder alone. The builder knows how to move data; only your people know what the data means.
You need three kinds of people. Someone with authority to decide what's correct when sources disagree. The people who use each spreadsheet every day, because they know the shortcuts, codes and exceptions hidden in it. And someone from finance, because outstanding invoices, payments and stock values have to reconcile to the cent.
Their time commitment is modest: a few short sessions to explain the files, and a couple of review rounds on sample imports. But without them, the migration will be technically clean and practically wrong.
Step 1: Inventory every source
Start by finding everything. It's always more than people think.
- The main spreadsheets everyone knows about, and every copy and 'final_v7' variant.
- Personal files on laptops that one person uses to track their part of the work.
- Exports from old tools, including ones you've stopped paying for.
- Email folders, chat groups and shared drives where decisions and attachments live.
- Paper: job sheets, logbooks, signed forms that may need to be captured or at least referenced.
Step 2: Decide what's worth moving
Not everything needs to come across. Moving ten years of history into a new structure is expensive and often unnecessary.
A common split: move all active records in full (current clients, open jobs, live contracts, current stock, active staff), move closed records from a recent period in full, and keep older history as a read-only archive you can still search. Agree the cut-off dates with the people who actually need the history, like finance and account managers.
Step 3: Understand the real structure
Spreadsheets hide structure. One sheet might mix clients, sites and contacts in the same row. Another might use colour to mean 'paid'. A column called 'notes' might contain dates, amounts and phone numbers.
The job here is to figure out the real entities (clients, sites, jobs, products, people) and how they relate. In a database, each becomes its own table with clear links: a client has many sites, a site has many jobs, a job has many time entries. Getting this model right is what makes every later report and automation possible.
Step 4: Clean the data
Cleanup is where most of the effort goes. Typical problems, and what to do about them:
- Duplicates: the same client entered three ways. Merge them, and decide which details win.
- Inconsistent formats: dates, phone numbers, currencies and addresses written differently. Standardise them.
- Meaning hidden in formatting: colours, bold text, comments. Turn each into a proper field or status.
- Free text that should be structured: 'paid 12.3., partial' becomes a payment record with a date and amount.
- Missing values: decide whether each field is required, and who fills the gaps.
- Obsolete records: old price lists, reused product codes, clients that merged or closed.
Step 5: Map, then import a sample
Each column in each source gets mapped to a field in the new system, with rules for transforming it. Then comes the step people skip and regret: importing a sample first, not everything.
Take a slice of real data, import it, and show it to the people who know it. They'll spot things in minutes that nobody else would: a client that belongs to a different branch, a price that's wrong, a status that means something different in practice. Fix the mapping and the cleanup rules, then repeat. Two or three rounds are normal.
Step 6: Full import and sign-off
When the sample looks right, run the full import. Then check it with totals that can be compared to the source: number of clients, open jobs, stock value, outstanding invoice amounts. If the totals match, spot-check a few records per person. Someone on your side with authority should sign off that the data is correct.
Step 7: Cutover and the read-only rule
On the go-live day, the old spreadsheets become read-only. This is the most important rule in the whole migration. If people can still edit the old file, some will, and you'll have two versions of the truth within a week.
Keep the old files accessible for reference for a few months. Most people stop opening them within a couple of weeks once they trust the new system.
Pick a cutover day with low activity, like the start of a week after a quiet weekend or the first working day of a month. Run a final delta import of anything that changed since the full import, check the totals once more, and announce clearly that from now on, the system is the only place to enter data.
Common mistakes
These are the patterns we see most often.
- Leaving migration to the last week of the project.
- Migrating everything, including decades of history nobody needs in the live system.
- Letting the builder decide what's correct instead of the people who know the data.
- Skipping the sample import and discovering problems after go-live.
- Keeping the spreadsheets editable 'just in case'.
Where Excel still belongs
Moving the company's core data into a database doesn't mean banning spreadsheets. Excel is still an excellent tool for one-off analysis, modelling, what-if scenarios and quick calculations.
The difference is direction. Before, the spreadsheet was the source of truth and everything else was copied from it. After, the system is the source of truth, and a spreadsheet is something you export for a specific question and throw away. If people start keeping data in exported files and editing them, that's a sign the system is missing a feature, and it's worth adding.
What it costs, and who does it
In many projects, migration is quoted separately, and it's where budgets quietly grow. With us, full data migration from Excel, exports and old tools is included in every plan: Core at €18,000, Maxxed at €48,000 and Empire from €120k. That's deliberate. A system without good data doesn't get used, and then nothing else we built matters.
If you'd like help moving off spreadsheets, apply and show us your files. We'll map the structure, give you a fixed price, and you'll see your own data in a first working version within 24 hours of kickoff.