Every organisation has a spreadsheet that has quietly become a system: the capacity plan, the contract register, the onboarding tracker. It works, but it has no permissions, no history and no workflow, and only one or two people really understand it. If you have decided to replace spreadsheets with an application, the hard part is not the build but the move, and it goes much more smoothly with a plan.
Step 1: Understand what the spreadsheet really does
Before touching any data, find out how the spreadsheet is used in practice. The file itself only tells part of the story.
Sit with the people who use it and note:
- Which tabs matter and which are abandoned experiments.
- Which columns are data and which are calculations, lookups or formatting.
- Hidden rules: colour coding that means "waiting for finance", a column only one person updates, a comment everyone checks.
- Who reads it and who edits it, and whether anyone should not see certain columns.
- What happens around it: emails sent when a row changes, a weekly copy pasted into a report, a manual export to another system.
This list is your requirements. The hidden rules in particular are where most spreadsheet migrations go wrong, because nobody wrote them down.
Step 2: Import the data as it is
Start with a copy of the real data, not a tidied sample. Importing messy data early shows you what you are dealing with.
Vibe can build a working application directly from an existing spreadsheet, generating the data model, screens and workflows in hours, and it imports CSV and SQL if your data lives elsewhere. The FAQ on importing data from spreadsheets covers the options. Treat this first import as a draft: you are going to look at it closely and probably import again.
Step 3: Clean the data and shape the model
Spreadsheets tolerate inconsistency; applications should not. Look for:
- The same thing written different ways: "Acme Ltd", "ACME" and "Acme Limited".
- Mixed values in one column, such as dates, notes and "TBC" in a date field.
- Repeated groups, such as Contact 1, Contact 2 and Contact 3 columns, which usually belong in their own entity.
- Lists that should be controlled: statuses, regions and categories that should come from a fixed set.
Use what you find to shape the data model. A single wide sheet often becomes several related entities, for example contracts, suppliers and renewal actions. In Vibe you can adjust the model by pointing and clicking or by describing the change in plain language, and AI can propose a structure and explain what a change will do. Every change is versioned and reversible, so it is safe to experiment.
Once the model is right, re-import the cleaned data into it.
Step 4: Set permissions and rebuild the hidden rules
This is where the application starts to be better than the spreadsheet rather than a copy of it.
Turn the notes from step 1 into explicit controls. Define roles for the people who read, edit and approve, and apply role-based access on each entity and action so that, for example, contract values are visible only to finance. Sign-in goes through single sign-on over SAML or OIDC, so nobody needs a separate password.
Then replace the hidden rules with visible ones. The colour that meant "waiting for finance" becomes a status with an approval step. The email somebody sent when a row changed becomes a notification. The weekly copy into a report becomes a dashboard on live data. Our guide to business analysts building their own apps covers this kind of refinement in more detail.
Step 5: Run both in parallel
Do not switch everyone over on a Monday morning. Run the application and the spreadsheet side by side for a defined period, long enough to cover at least one full cycle of the process, such as a month-end or a full onboarding.
During the parallel run:
- Pick a small group who use the application for real work.
- Compare outputs: do the totals, statuses and reports match?
- Log every gap where someone had to fall back to the spreadsheet, and fix it in the application.
- Agree the exit criteria in advance, so the decision to cut over is not a matter of opinion.
Parallel running feels slower, but it is where trust is built. People who have seen the application get the same answers as their spreadsheet are far more willing to give the spreadsheet up.
Step 6: Cut over and retire the spreadsheet
When the exit criteria are met, do a final import of any changes made in the spreadsheet during the parallel run, then make the application the only place to work. Make the spreadsheet read-only and archive it, so there is no temptation to keep updating both. Tell people clearly where the new application is and who to ask for help.
After cut-over, keep watching for a few weeks. Audit logging shows who is using the application and how, and because every change is versioned, fixing a rule that turns out to be wrong carries little risk. The application runs on infrastructure bizapps.io manages, with point-in-time backups, patching and monitoring, so the data is safer than it ever was in a shared file.
Choose your first spreadsheet
The best first candidate is a spreadsheet that several people edit, that drives a real process and that causes regular trouble. Our article on spreadsheet sprawl and shadow IT can help you find it, and the FAQ on how Vibe differs from spreadsheets explains what changes. When you have one in mind, tell us about it: design partners build their first application with direct access to our engineers, free during the programme.