Moving your team from spreadsheets to a shared database

A spreadsheet stops behaving like a spreadsheet the moment three people edit it at once. Formulas point at rows that have moved, the same client is written in four different ways, and the one column everybody actually needs lives in a tab nobody dares to touch. My job is not to talk anyone out of spreadsheets, they were the right tool for a long time, but to move the part that has outgrown them into a small database with a normal web interface, so the team keeps working the way it thinks and stops paying for it with lost rows.

I start by reading what you already have: the sheets, the hidden tabs, the side file someone keeps on a laptop, and, more importantly, the way people actually work with all of it. Out of that comes a list of real entities and the links between them, and only then a structure. Data moves over with a cleanup pass and formats brought to one shape. After that come input forms instead of typing into cells, reference lists instead of text retyped a hundred times, access by role so that an accountant and a new hire see different things, search and filters that work across the whole set rather than one visible tab, reports instead of pivot tables rebuilt by hand every Monday, and a change history that answers who moved that number and when.

Three things I say before we start, because they decide how the whole project feels. A move off spreadsheets always uncovers contradictions in the data, duplicates, typos, two records for one person, and I bring every one of them to you rather than correcting them to my own taste, because only your side knows which of the two is real. The old spreadsheets are kept as an archive until the team has worked in the database for a month; nothing is deleted on launch day. And the export back into a spreadsheet stays in the system on purpose, because without it people quietly slip back to the old way and the new base turns into a second place where nobody enters anything.

What the work includes:
— reading the current sheets and watching how the team really uses them;
— entities, links and structure agreed with you before anything is built;
— data transfer with de-duplication and format alignment;
— input forms with validation instead of free typing into cells;
— reference lists in place of repeated text;
— access by role, down to individual fields where it matters;
— search, filters, reports and a full change history;
— export to a spreadsheet for everyone who prefers one;
— training for the team and a settling-in period after launch.