Bring your Excel model into DeepCell in 10 minutes

"Can I migrate the model I already have?"

It's the first question every analyst asks, and the right one. Because the honest answer in most tools is: not really. You can import the values — sure. But the formulas come over half-broken, the layout flattens, the named ranges evaporate, and within a day you're rebuilding from scratch. At which point the cost-benefit case has already collapsed.

So before talking about how DeepCell does it, it's worth being clear about what a serious import has to do. It has to read the calculated values, not the stale cache. It has to attempt the formulas, not just the numbers. It has to keep a link back to the source so you can audit where each cell came from. And it has to be honest about what it couldn't convert, instead of writing zero and moving on.

That last one is the hardest. Most importers fail silently.

Two paths, depending on how well you know your own model#

There are two ways into DeepCell. They produce the same kind of .deepcell file at the end. The difference is who's doing the layout work — you, or the agent.

Path 1 — Deterministic import#

Use this when you know your workbook. You wrote it, or you've stared at it long enough to recite the row numbers in your sleep. You tell the CLI exactly where each line item lives and which columns map to which periods, and it does the rest.

deepcell import dcf_model.xlsx \
  --items '[
    {"id":"Revenue","name":"Revenue","level":0,"row":5,"sheet":"P&L"},
    {"id":"COGS","name":"COGS","level":0,"row":6,"sheet":"P&L"},
    {"id":"Gross_Margin","name":"Gross Margin","level":0,"row":7,"sheet":"P&L"}
  ]' \
  --contexts '[
    {"id":"FY2024A","name":"FY2024A","period_type":"annual","column":"B","status":"actual"},
    {"id":"FY2025E","name":"FY2025E","period_type":"annual","column":"C","status":"projected"}
  ]' \
  --name acme_dcf

What that does, in order: opens the xlsx, reads the calculated values from each (row, column) intersection — not the cached blob Excel keeps on disk, the live result — extracts the underlying formulas, converts them to Jingwei syntax where it can, and writes a DataSourceDefinition for every cell so you can trace Revenue × FY2024A back to P&L!B5 six months from now.

Items can target different sheets ("sheet":"Drivers" on one, "sheet":"P&L" on another) — multi-tab workbooks are the common case, not the exception. Add --aggregations to declare roll-ups (SUM, AVERAGE, MIN, MAX, COUNT) and the engine will recompute parents from children instead of importing them as flat values.

It's not auto-detection. The CLI doesn't guess where your model starts. You give it the coordinates, it gives you a faithful translation.

Path 2 — Agent-assisted import#

Use this when you opened the workbook yesterday and you're already lost. A colleague's model, an acquisition target, a legacy DCF nobody owns anymore. You don't want to map rows by hand. You want the structure inferred.

This is the excel-extractor subagent — one of five specialists the DeepCell orchestrator delegates to. You don't call it directly. You hand the file to Claude and describe what you want:

You: Here's our latest DCF. Pull it into DeepCell and tell me what
     assumptions you found.

Claude: [uses excel-extractor]
        Imported P&L tab (rows 4-23 as items, columns B-K as periods
        FY2020A–FY2029E). Drivers tab linked as upstream. 4 formulas
        required review:
          - Gross_Margin (P&L!B7) — circular ref through Drivers!C18,
            stored with warning
          - WACC (Drivers!B12) — INDIRECT() conversion incomplete
          - Terminal_Value (DCF!F28) — references external workbook,
            value imported, formula dropped
          - Tax_Rate (Drivers!B19) — converted as IF chain, please verify
        Everything else converted cleanly. Want me to walk through the
        four flagged cells?

The agent path is slower. It's also tolerant of messy workbooks — the ones with three blank rows between sections, a "Summary" tab that nobody updates, color-coding standing in for status. The orchestrator and the extractor talk back and forth until the structure makes sense, then call the same underlying import endpoint the deterministic path uses. More on this division of labor in an analyst and Claude, working on the same model.

On formula conversion — being honest#

Most Excel formulas convert cleanly. SUM, AVERAGE, IF, SUMIF, NPV, IRR, MIN, MAX, ROUND, COUNT, LOOKUP — these have direct Jingwei equivalents and round-trip without drama.

Some don't. INDIRECT is the usual culprit — it builds a reference string at runtime, which a static dependency graph can't follow. Deeply nested array formulas, three-dimensional references across sheets, external workbook links ([other_model.xlsx]Sheet1!B5) — all of these either degrade gracefully (value preserved, formula flagged) or fail loudly with a warning attached to the cell.

The cell still imports. It just imports with a marker saying this one needs a human. You see those markers in the inspector and decide what to do. Better an explicit warning than a silent miscalculation that compounds across six dependent cells.

A few other things to know up front: named ranges don't carry across — you give row/column coordinates, not names. Merged cells are read top-left only (an openpyxl quirk we inherit). External workbook links aren't pulled in; if your model depends on a separate file, you import that one separately. The size ceiling on a single xlsx is 10 MB.

What you get on the other side#

The import commits to git the moment it completes. This matters more than it sounds. When your colleague updates the same xlsx next week and sends it over, re-running deepcell import on the new version produces a semantic diff — not a blob-level "this file changed," but "COGS added in FY2026E, Gross_Margin formula changed from Revenue - COGS to Revenue - COGS - Other_Cost, 14 values updated in the actuals column." Run deepcell diff and you see exactly that.

This is what versioning a model looks like when the format is the source of truth.

Coexistence, not replacement#

The import is non-destructive. Your dcf_model.xlsx is untouched on disk. The .deepcell file lives alongside it, references it, can be re-exported back to xlsx via deepcell to-excel for anyone on your team who still prefers the grid (more on that in round-tripping with Excel).

If the migration doesn't take — if you decide DeepCell isn't the right home for this particular model — you've spent the cost of running one CLI command and you still have your original workbook.

That's the deal. Try it on a model. Worst case you've learned what yours looks like when it's pulled apart and inspected. Best case you've just versioned the thing properly for the first time.

See it for yourself — open a sample .deepcell in the playground. Edit a value, watch the dependents recalculate, inspect the reasoning behind any number.