From Spreadsheet to Software: What Happens to Your Data During Migration

One question comes up before almost every custom software project:

“We’ve been tracking everything in spreadsheets for five years. What happens to all of it?”

Client records, project history, inventory counts, financial data — that’s years of institutional knowledge sitting in files on someone’s desktop. A migration that goes wrong, or gets skipped, leaves it stranded in a spreadsheet nobody maintains anymore.

This post walks through exactly what happens during a spreadsheet-to-database migration, from audit through cutover. If you want to understand how migration fits into the overall project cost, the database development cost breakdown covers that. This post is about the process itself.

---

What Data Migration Actually Means

Migration isn’t copying your spreadsheet into a new system. That almost never works.

A custom database has structure — tables, fields, relationships, data types. Your spreadsheet has a flat layout optimized for one person reading it on a screen. Getting from one to the other requires mapping columns to database fields, cleaning inconsistencies, writing import scripts, and verifying the result before anyone goes live.

Done well, you open the new system on day one and your data is already there — clean, organized, and searchable. Done poorly, you spend months reconciling what’s in the system against what’s still in the old file.

---

The Migration Process, Phase by Phase

1. Data Audit

What it is: A review of everything you’re bringing over. Which spreadsheets exist, what’s in them, how consistent the data is, and whether records in one file relate to records in another.

What it looks like: The developer asks for your source files, reviews the column headers, spot-checks for consistency, identifies duplicates, and flags anything that won’t import cleanly.

Why it matters: The audit sets the scope for everything else. Clean data from a single well-organized spreadsheet takes a few hours to migrate. Messy data pulled from four overlapping files can take days. Knowing which situation you’re in before the build starts prevents surprises mid-project.

Your role: Pull together the actual source files — not just the main one, but any supplementary spreadsheets where related data lives. The audit can only catch what it can see.

---

2. Data Cleanup

What it is: Fixing inconsistencies in your existing data before it gets imported. This is the phase that surprises most people.

What it looks like: Common problems that surface in almost every migration:

Problem	Example
Inconsistent naming	“ABC Corp” vs “ABC Corporation” vs “ABC Corp.”
Duplicate records	Same client entered twice under slightly different names
Missing required fields	Blank phone numbers, incomplete addresses
Inconsistent formats	Dates as “Jan 15 2024”, “1/15/24”, and “15-Jan-2024” in the same column
Merged cells	Excel formatting that doesn’t translate to structured data

Why it matters: Every inconsistency becomes a decision: merge these records, keep them separate, or flag for review. That’s manual work, and manual work takes time.

What to watch for: Data cleanup is one of the most common sources of scope creep on small business projects. Four years of data entered by three different people with no naming conventions will extend this phase. Plan for it.

Your role: The most valuable thing you can do before the project begins is clean your own data. Consistent naming, no duplicates, complete key fields. A few hours of your time here is worth far more than paying developer rates for the same cleanup.

---

3. Schema Mapping

What it is: Defining how each column in your spreadsheet maps to a field in the new database.

What it looks like: A spreadsheet column called “Client Name” might map to a clients table with separate first_name and last_name fields. A column of freeform status text might become a dropdown with defined options. Some columns get split; others get combined; a few get dropped entirely.

Why it matters: Decisions made here shape how the system behaves for years. What becomes a required field. What becomes a dropdown versus a text field. How records link to each other. Getting this right requires both technical judgment from the developer and context from you about what the data actually means.

Your role: Review the mapping before development starts. The developer handles the technical decisions, but you know how the data is actually used — and that context catches mistakes before they’re built in.

---

4. Migration Scripts and Test Import

What it is: Writing the code that reads your source data, transforms it to match the database structure, and loads it into the system.

What it looks like: The developer writes scripts that process your files and run them into a test environment — not the live system. The first pass almost always surfaces something the audit didn’t catch: a date format the script didn’t account for, a record that breaks because a required field is empty, a duplicate that slipped through cleanup. The test environment is where these get caught and fixed.

Why it matters: This step is why migration takes longer than “just importing the spreadsheet.” Skipping it means problems surface in production, where they’re harder to fix and more disruptive.

Your role: Nothing at this stage. This is developer work. Worth knowing it exists.

---

5. Data Verification

What it is: Confirming that what’s in the database matches what was in the spreadsheet — and that it makes sense.

What it looks like: The developer compares record counts, spot-checks key records, and runs queries to verify totals and relationships. Then you review the imported data against your source files.

Why it matters: If there’s a discrepancy, you want to catch it before cutover — not three months later when someone asks about a missing client record.

Your role: This is one of the more important steps for you to actively participate in. The developer can verify completeness and structure; only you can verify that the data makes sense in context. Set aside real time to check it.

---

6. Parallel Operation

What it is: A defined period where both systems run simultaneously — the old spreadsheets and the new database.

What it looks like: Your team starts using the new system for new entries. The spreadsheet stays available as a reference but isn’t updated. New data goes into the database only.

Why it matters: Parallel operation gives your team time to get comfortable before the old system disappears. It also provides a safety net — if something unexpected comes up after launch, the spreadsheet is still there as a backup.

What to watch for: Parallel operation can drag on indefinitely without a fixed end date. When it does, the team defaults to whichever system they’re more comfortable with — usually the spreadsheet — and the new system collects a mix of data while the old one quietly remains authoritative. Set a cutover date before parallel operation begins.

How long: For most small business projects, two to four weeks is enough. Longer without a specific reason and you’re maintaining two systems without a good one.

---

7. Cutover

What it is: The point where the new system becomes the only system.

What it looks like: A specific date everyone knows about. New entries go into the database only. The spreadsheet moves to an archive folder — not deleted, but no longer the active record.

Why it matters: Cutover is where the project actually finishes. Without it, you have a new system running alongside the old one indefinitely, and the ROI you were expecting never materializes because the old workflow never fully stopped.

Your role: You set the date. The developer can tell you when the system is ready. Committing to the cutover is a business decision. If your team hesitates, parallel operation extends and the project stays in limbo.

---

What to Do Before the Project Starts

The cleaner your data when the project begins, the smoother the migration goes.

Consolidate your spreadsheets. If the data you need lives across multiple files, bring it together into one. Note inconsistencies you find along the way.

Standardize naming conventions. Pick a format for client names, project names, status values — anything that appears frequently. Apply it across the file.

Remove duplicates. Common in spreadsheets that multiple people have added to over time. Identify and resolve them before the project starts.

Document what each column means. Some columns are obvious. Others carry context that only makes sense to the person who created them. Write down what they represent before that knowledge becomes hard to recover.

Identify what you don’t need. Not everything in your spreadsheet needs to come over. Old test rows, deprecated fields, data from a project three years ago with no ongoing relevance — identifying what to leave behind saves migration time and produces a cleaner system.

---

Red Flags to Watch For

Migration not addressed in the proposal. If a proposal doesn’t mention data migration, ask directly: “Is migration included, and what assumptions are you making about our data?” The answer tells you a lot.

No test environment. A developer planning to import directly into the live system without a test pass is skipping a step that exists for a reason.

No defined cutover plan. Migration without a cutover date tends to drift. You need a specific plan for ending parallel operation.

“We’ll figure out migration later.” Migration scope affects project scope. Deferring the conversation means scope surprises mid-build.

---

How Long This Takes

Here’s what a typical migration timeline looks like for a small business project:

Phase	Who Does It	Typical Time
Data audit	Developer reviews your files	1–3 hours
Data cleanup	You, with developer guidance	A few days to a week
Schema mapping	Developer with your input	2–4 hours
Migration scripts and test import	Developer	4–12 hours
Data verification	Both	2–4 hours
Parallel operation	Your team uses both systems	2–4 weeks
Cutover	You set the date	One defined day

Total developer time for a clean migration is usually 8–20 hours. For messy multi-source data, it runs higher. This is one of the real variables behind what a custom database project actually costs — the state of your data affects the scope in ways that aren’t visible from the outside.

---

For a small business that’s been running on spreadsheets for years, migration tends to feel like the most uncertain part of the project. The honest answer is that it’s manageable when the process is defined and the data is reasonably clean — and it’s still manageable when the data is messy, as long as everyone understands what that means for scope and timeline.

The biggest risk isn’t data loss. It’s launching a system with all your records, but those records being inconsistent, duplicated, or incomplete in ways that were already there before the project started. That’s a problem worth addressing before the build begins, not during it.

My pricing page covers how I handle migration as part of a project — what’s included, what affects scope, and what you can do to reduce the complexity before kickoff. If you’d rather start with a conversation about your specific data situation, that works too.