How it works

A workbook is a program nobody wrote down. Formulas copied down columns are loops, lookup tables are joins, named ranges are parameters, and the saved values in every cell are a test suite the author never knew they were writing. Power Migrate reads all of that and produces code that passes the suite.

1. Parse

The file is read twice: once for formulas and defined names, once for the values Excel last calculated. Dates stay as Excel serial numbers so nothing is lost in conversion. The package itself is inspected for macros, external links, Power Query connections and pivots, because each of those is something the code will have to replace or declare.

2. The dependency graph

Every reference is resolved to a concrete cell or range. Ranges are nodes of their own, so a lookup table read by nine hundred formulas is expanded once. The graph says which cells are inputs (constants a formula reads), which are outputs (formulas nothing else reads), and in what order everything can be computed. Circular references are found here and reported, not hidden.

3. Logic blocks

Two formulas with the same R1C1 form are the same formula copied to different cells. Such cells are grouped into rectangular blocks: a column copied down, a row copied across, a table filled in. A block that reads its own earlier cells, a running total for example, is given a loop direction that visits precedents first. Blocks are ordered so that everything a block reads is computed before it runs.

4. Generate

Code is written by rules. Each block becomes one function in the Python target, one column operation in the pandas target, or one CREATE TABLE AS SELECT step over typed sheet tables in the SQL target, where a column that reads its own previous row becomes a recursive query. Names come from the labels next to the cells. An AI model may be used, with your own endpoint, to propose better names and plain-English descriptions; it sees formulas and structure with every literal redacted, and the reconciliation checks its work. Anything the rules cannot express, a user-defined function without source, an unstable INDIRECT, a function with no equivalent, becomes a clearly marked stub whose result propagates to every dependent cell and is listed in the report.

5. Reconcile

The generated code runs on the workbook's own input values and every formula cell is compared with the value Excel stored in the file. Numbers match within a tolerance you choose, text must match exactly, errors must match by code. The report gives the count by sheet, lists every mismatch with both values, and lists every cell that was not converted with its reason. Where Excel is available, generated input variations are run through Excel and the code side by side, which catches semantics the stored values alone cannot. We say tested equivalence, never guaranteed identical: the report certifies the checks it ran.

What SQL cannot represent

Excel has one dynamic cell type and seven error values; SQL has typed columns and NULL. The SQL target infers one type per block, keeps a separate physical column where a sheet column mixes text and numbers, and declares its policies: Excel errors and the empty string are NULL, a blank input counts as 0 in arithmetic, text compares case-insensitively. The reconciliation counts every cell that matched only under those policies and explains every mismatch they cause, so a reviewer sees exactly where the two systems part ways.

Settling what Excel does

Questions about Excel's behaviour are not answered from memory. A small script puts the formula to an installed copy of Excel and the answer is recorded as a test. That is how we learned that Excel checks operands left to right, that DATEDIF's "yd" unit is month arithmetic rather than a date difference, that a wildcard criterion only treats a tilde as an escape when it also contains an asterisk or a question mark, and that serial 0, a blank date, is a Saturday.