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 — Map it yourself (precise 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 DeepCell exactly where each line item lives and which columns map to which periods, and it does the rest.

You give it a simple map of your model. For example: Revenue lives on row 5 of the P&L tab; COGS on row 6; Gross Margin on row 7. FY2024A is column B and holds actuals; FY2025E is column C and holds projections. That's the whole instruction — line items to rows, periods to columns — and DeepCell builds the file from there.

This precise path is for people comfortable with a bit of setup — if that's not you, skip to Path 2.

What that does, in order: opens the xlsx, reads the calculated values from each row-and-column intersection — not the stale copy Excel keeps on disk, the live result — extracts the underlying formulas, translates the formulas into DeepCell's own formula language wherever it can, and records where every cell came from, so six months from now you can trace the Revenue actual back to cell B5 on the P&L tab.

Line items can target different sheets (some on a Drivers tab, others on the P&L tab) — multi-tab workbooks are the common case, not the exception. You can also declare roll-ups (SUM, AVERAGE, MIN, MAX, COUNT) and the engine will recompute parents from children instead of importing them as flat values.

The tool 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 one of DeepCell's specialists for reading spreadsheets. 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. Claude and the extractor talk back and forth until the structure makes sense, then run the same underlying import the precise 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 DeepCell equivalents and round-trip without drama.

Some don't. INDIRECT is the usual culprit — it builds its reference on the fly, which the system can't trace ahead of time, because the reference only exists once the sheet runs. 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 (a quirk of the underlying Excel reader). 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 is saved as a versioned snapshot the moment it completes. This matters more than it sounds. When your colleague updates the same xlsx next week and sends it over, re-importing the new version gives you a meaningful, line-by-line comparison — not a useless "this file changed," but "COGS was added in FY2026E, the Gross Margin formula changed from Revenue − COGS to Revenue − COGS − Other Cost, 14 actuals updated." 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, and can be exported back to xlsx 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 import 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.