How does a spreadsheet-to-system migration actually work?

Five stages: map the workflow the sheet encodes (not the sheet itself), design the small system that workflow needs, migrate the data once with validation that surfaces years of silent errors, run both in parallel briefly, then retire the sheet deliberately. Weeks, not quarters, when scoped honestly.

What is the biggest mistake in replacing a spreadsheet?

Rebuilding the grid: cloning columns and tabs into an app, which preserves every workaround and loses the sheet’s one virtue, flexibility. The sheet is not the specification; the workflow it grew around is. Map the process, then let the sheet retire as an artifact of its era.

What happens to the spreadsheet’s errors during migration?

They surface, and that is a feature. Audits find most operational sheets contain errors; migration validation is where years of them finally get caught: duplicate records, drifted formulas, impossible dates. Budget a cleanup pass and treat every find as a save.

How long should the parallel-run period last?

One to two full workflow cycles: long enough for the exceptions to arrive, short enough that nobody maintains two systems as a lifestyle. The exit is defined in advance: the sheet goes read-only on a named date, and the archive stays for reference.

From spreadsheet to system: how the migration goes

The short answer

A spreadsheet migration succeeds when it migrates the workflow, not the grid: map the process the sheet grew around, design the small system that process needs, move the data once through validation that harvests years of silent errors, run both for a cycle or two, and retire the sheet on a named date. Cloning columns into an app preserves the workarounds and loses the point.

The decision to replace a sheet gets plenty of coverage, including ours. What happens next usually gets a shrug and a project plan. Here is the anatomy of the migration itself, including the two moments that surprise everyone: the error harvest and the day the sheet refuses to die.

The governing principle: workflow, not grid

The instinct is to treat the sheet as the specification: clone its columns, tabs, and lookups into an app. The instinct is wrong twice. It preserves every workaround as a feature (the duplicate column that exists because of a 2023 incident, the status values nobody uses), and it loses the sheet's one genuine virtue, flexibility, without gaining a system's virtues in exchange. The sheet is an artifact of how the workflow coped without software. The specification is the workflow itself: what arrives, who decides, what the exceptions are: which is why the mapping stage looks exactly like embedded discovery and not like data modeling.

The five stages

01Map the workflow the sheet encodes. With its keeper and its users: arrivals, decisions, exceptions, hand-offs. The keeper’s undocumented rituals are requirements wearing habits; capture them now, per the key-person playbook.
02Design the small system that workflow needs. A real data layer, permissions, the deterministic rules as code, and the reading steps handled in place: the AI-native shape, sized to the workflow and nothing more.
03Migrate the data once, through validation. Every row checked on the way in: types, duplicates, impossible values, orphaned references. This is the error harvest; schedule the cleanup pass it will demand.
04Run both for one or two full cycles. The system leads, the sheet shadows. Exceptions that only arrive monthly get their chance to appear while the safety net still exists.
05Retire the sheet on a named date. Read-only, archived, linked from the new system for reference. Without the named date, the sheet survives as a shadow system and the migration quietly fails.

The sheet is not the specification. It is an artifact of how the workflow coped without software.

The error harvest

Migration validation is where the sheet's history gets audited for the first time, and the findings track the research: audits summarized by Panko found 94 percent of operational spreadsheets contain errors, and a real migration surfaces its share: duplicates that double-counted, formulas that drifted after a row insert years ago, dates that never existed. Treat every find as a save rather than an embarrassment: each one was a mistake in flight toward a customer or an account, caught at the last cheap moment. The harvest is also the argument for doing the move deliberately rather than letting attrition do it during a keeper's notice period.

What the other side looks like

Done honestly, the other side is smaller than the project plan feared: one owned tool where the queue lives, validations at the door, the reading steps handled inside the workflow, and a two-week-test answer that finally passes because the rules live in reviewed code instead of one person's memory. The economics of getting there are the changed math: weeks of fixed-scope build, and the sheet's salary-shaped running costs stop. The grid earned its retirement. The workflow gets a system.