Excel → Web Application

How to Migrate Excel to a Database

Migrating a spreadsheet to a database means turning columns into a typed schema, splitting repeated blocks into related tables, cleaning what years of manual exceptions left behind, and running both systems in parallel until the numbers agree. The hard part is not the import — it is the business rules hidden in the formulas.

10 min readUpdated 2026-09-15

A database is the storage layer; the team still needs a way to work with it. Datanova helps businesses turn an Excel process into a custom web application.

A database alone will not replace the spreadsheet

Worth saying before anything else: a database is storage. It holds the data reliably, enforces types and relationships, and lets many people read and write at once. It does not give your team a way to work. The moment the data lives in a database, someone needs an interface to enter, edit and review it — which is why most migrations end up building a small application on top, not just a schema.

Step 1 — Find the entities hiding in the columns

A spreadsheet is one flat rectangle. A database is several related tables. The first job is spotting where one table ends and another begins, and the tell is repetition:

A customer name repeated on 400 rows is a `customers` table, referenced by id
Columns like Item 1, Item 2, Item 3 are a child table with one row per item, not three columns
A tab per month or per site is one table with a date or site column — never a table per tab
A column holding two things ("ACME-2024-INV-003") is several columns
A colour used to mean something is a status column that was never written down

That last one matters more than it sounds. Meaning encoded in formatting — highlighted rows, bold text, a cell someone always leaves blank — is real business logic that no import will carry across. Find it by asking the person who maintains the file what each visual convention means.

Step 2 — Extract the rules before touching the data

This is the step that determines whether the project goes well. Every spreadsheet that has run a process for years has accumulated logic in three places, and only the first is easy to find:

Where the rule lives	How to get it out
Formulas and conditional formatting	Readable directly, though nested IFs take patience to unwind
Macros and VBA	Readable, but often undocumented and written by someone who left
People's judgment	Only by asking: "when do you override what the sheet says?"

The third row is where migrations fail. The exceptions people handle by hand are invisible in the file and essential to the process.

Write the rules down in plain language before designing anything. Teams that arrive at a consultation with this document get shorter, cheaper projects, because discovery is the most expensive unknown in any quote.

Step 3 — Clean what the years left behind

A database will refuse data a spreadsheet happily accepted. That refusal is the point, and it is also the work:

Dates stored as text, as numbers, and in two different orders in the same column
Numbers with currency symbols, thousands separators or trailing spaces
The same customer spelled four ways, none of which match the CRM
Merged cells, which have no meaning in a table
Blank rows used as visual separators, and totals rows mixed in with data
"N/A", "-", "pending" and empty all meaning the same thing in one column

Decide deliberately how much history to bring. Migrating three years instead of ten often removes weeks of cleanup for records nobody queries. Old data can be archived as-is rather than cleaned.

Step 4 — Choose the database

For the overwhelming majority of business processes coming off a spreadsheet, the answer is PostgreSQL. It is free, mature, handles relational data well, and every hosting provider supports it. Choose differently only for a specific reason:

Option	When it fits
PostgreSQL	The default. Relational operational data, any scale a spreadsheet was handling
SQL Server	The organization is already on Microsoft infrastructure with in-house skills
SQLite	Single-user or embedded; rarely right when concurrency was the reason to migrate
Airtable / low-code	Small team, standard workflow, and per-user pricing still makes sense
A data warehouse	The goal is reporting and analysis, not running the daily process

Step 5 — Run both until the numbers match

Import history into the new schema and check totals against the spreadsheet — not spot checks, actual sums on the figures the business reports.
Have the team enter into both for two to four weeks. Yes, it is double work, and it is the cheapest insurance available.
Compare outputs daily at first. Every discrepancy is either a migration bug or a rule nobody mentioned in step 2 — both are worth finding now.
Switch only when a full reporting cycle matches end to end.
Make the spreadsheet read-only rather than deleting it. Keep it for a few months as a reference nobody can edit.

Frequently asked questions

Can I just import the Excel file into a database?

You can import the rows in minutes, and that is the easy 10 percent. What the import does not carry across is the structure (one flat sheet becomes several related tables), the business rules living in formulas and macros, the meaning encoded in colours and formatting, and the exceptions people handle by hand. Those are the project.

How long does migrating a spreadsheet to a database take?

For a single well-understood process, typically 4 to 8 weeks including the interface people need to actually work with the data. Most of the variation comes from data cleanup and from how quickly the business can answer questions about its own rules.

Which database should I use?

PostgreSQL unless you have a specific reason not to. It is free, mature, handles relational operational data well and is supported everywhere. Use SQL Server if the organization is already on Microsoft infrastructure with the skills in house.

Do we need to migrate all our historical data?

Usually not, and deciding to migrate less is one of the most effective ways to reduce cost. Bring the history that gets queried — often three years — and archive the rest as read-only files. Cleaning ten years of records nobody looks at can add weeks for no benefit.

Will people still be able to export to Excel?

They should, and any system replacing a spreadsheet needs to keep that door open. The goal is to stop Excel being the system of record, not to stop people using it for analysis — which is what it is genuinely excellent at.

Planning a migration?

In a free consultation we look at the spreadsheet, the rules buried in it, and what depends on it downstream — then tell you what the migration realistically involves, or whether a cheaper step gets you what you need.

Book a Free Consultation