Migrations
Moving from spreadsheets to an internal tool
Spreadsheets are a fine place to start. The move makes sense when the sheet has become the system several people depend on every day.
Last reviewed 14 November 2026
Move off Google Sheets or Excel when several people edit the same sheet, when formulas break and nobody knows why, when you need permissions by role, or when one sheet feeds orders, stock or invoices. The usual route is a database such as Postgres or Supabase with an internal tool on top, built in Retool or custom code, while the sheet stays readable during the switch.
Who this is for
Operations, sales and finance teams of 5 to 200 people running a core process from shared spreadsheets.
Signs it is time to move
- Two people overwrite each other’s changes, or a column gets sorted out of line
- Version files named final, final2 and final-use-this
- You need different views and permissions for staff, managers and outside parties
- Row counts or formula chains slow the sheet to a crawl
- A mistake in a cell has already cost money
What it costs on each side
Google Workspace and Microsoft 365 include spreadsheets in the seat price, so the visible cost is low. The real cost is staff time spent copying, checking and fixing. An internal tool adds a platform or hosting fee and a build cost, so the case rests on the hours saved and the errors avoided. We work it out during the audit with your own numbers.
The migration plan, step by step
- 01
Inventory
List every sheet, tab, formula chain and person who edits or reads it, and what decisions each one feeds.
- 02
Map
Turn tabs into tables with keys, write down the rules hidden in formulas, and agree who can see and change what.
- 03
Rebuild
Build the database and the screens people use daily first, with validation where the sheet allowed anything.
- 04
Parallel run
Sync the sheet into the new tool and have a small group work in the tool while others stay on the sheet for a week or two.
- 05
Cut over
Lock the sheet to read-only on an agreed date and move everyone over, with a short walkthrough per team.
- 06
Monitor
Track errors and requests for the first month, and keep a scheduled export to Sheets if people still need it for analysis.
Risks and how we avoid them
| Risk | How we avoid it |
|---|---|
| Rules that only lived in someone’s head or in a hidden formula get lost. | Interview the people who edit the sheet, and test the new tool against last month’s real data. |
| People keep using the sheet on the side. | Set a cut-over date, make the sheet read-only and give people an export for analysis. |
| Building too many screens before the first one is used. | Ship the one daily screen first and add the rest in later sprints. |
What we do and what it costs
We start with the $500 audit, which maps the sheet and gives one fixed price, credited to the build. Internal tools start at $3k and multi-module systems at $5k. Care plans from $50 a month keep it running after go-live.
Questions
Can we keep using Google Sheets for reports?
Yes. Many clients keep a scheduled export to Sheets or connect a reporting tool to the database. The difference is that the sheet becomes a copy for reading.
Retool or custom code?
Retool suits a small internal team that needs screens quickly. Custom code suits many users, outside users or complex rules. Our Retool vs custom code page goes into it.
How long does it take?
A single-process tool usually goes live in three to six weeks, including the parallel run.
Related: Google Sheets, Retool, Supabase, Retool vs custom code, Retool and Supabase automation, Modernise service, comparisons. All migrations.
We will tell you whether the move pays before you start
The audit lists what you run today, ranks it by cost and risk, and ends in one fixed price for the migration, credited to the build.
Book a discovery call
