Migrating Excel Workflows to Python: What to Move, What to Keep, and Where the Code Should Run
“Move this spreadsheet to Python” sounds like a technical task, but the difficult decision is architectural: which parts of the workflow should move at all?
A mature workbook can contain formulas, Power Query steps, VBA, manual procedures, external data connections, review controls, and business rules that users understand precisely because they are visible in Excel. Replacing all of that with Python can make the result less maintainable.
A better migration starts by separating the workflow into responsibilities.
Do not migrate the workbook line by line
Start with a map of the existing system:
Inputs
│
├── worksheet assumptions
├── imported tables
├── files / APIs / databases
└── manual adjustments
│
▼
Business logic
│
├── formulas
├── Power Query
├── VBA
└── external scripts
│
▼
Outputs
│
├── calculations
├── reports
├── charts
├── reconciliations
└── files / emails / system updates
Then classify each responsibility by what environment is best at it.
What should usually stay in Excel
Keep logic in Excel when its transparency is a feature.
Good examples include:
- simple formulas that business users can audit directly;
- visible assumptions and overrides;
- reconciliations and control totals;
- presentation tables stakeholders modify frequently;
- normal PivotTables or charts when native Excel editing matters;
- Power Query steps that are already clear and reliably maintained by the owning team.
Moving a transparent SUMIFS or a straightforward Power Query import into Python just because Python is available usually creates more code without creating more value.
What is a good candidate for Python
Python becomes more attractive when the existing workbook contains software-like logic that is difficult to express or maintain in spreadsheet primitives:
- repeated helper-sheet transformations;
- simulation or optimization;
- statistical models;
- numerical algorithms;
- complex text processing;
- reusable domain calculations;
- duplicated business logic;
- logic that would benefit from unit tests;
- interactive application behavior that is currently held together by macros and manual steps.
The migration target should be a clearer boundary, not “more Python.”
What should remain external
Some work should not be pulled into the workbook runtime at all.
Keep external Python, services, or other automation for tasks such as:
- traversing local folders;
- processing hundreds of independent files;
- scheduled jobs;
- PDF/email/document ingestion;
- database pipelines;
- unrestricted API integrations;
- desktop automation;
- native packages that do not fit the workbook runtime.
A strong architecture can use external Python for ingestion and still use Excel as the interactive decision and review layer.
Migrating VBA
VBA is not one thing. A macro can contain calculation logic, workbook manipulation, event handlers, formatting, file-system work, Outlook automation, and UI code in the same procedure.
Classify it before translating it.
| VBA responsibility | Likely destination |
|---|---|
| Analytical calculation | Python model or function |
| User assumptions | Excel cells/tables |
| Reusable worksheet calculation | Python custom function or retained Excel formula |
| Model controls | Workbook UI or notebook application controls |
| File/folder/Outlook automation | VBA or external Python |
| Formatting and sheet manipulation | Often keep in Excel/VBA-specific layer |
| Validation and reconciliations | Excel and/or deterministic Python checks |
A line-by-line VBA-to-Python translation often preserves the worst part of the original design: hidden mutable state and procedural dependencies.
Instead, try to replace the macro with explicit inputs, a testable calculation, and explicit outputs.
Migrating formula-heavy models
Long formulas and helper sheets are good migration candidates only when they have become difficult to reason about.
Look for:
- the same formula logic copied across many places;
- nested formulas implementing a real domain algorithm;
- large helper-sheet chains used only as intermediate state;
- calculations that need simulation, optimization, or statistics;
- formulas that cannot be tested independently of the workbook.
Then migrate incrementally:
- freeze a representative test workbook;
- document the current inputs and outputs;
- calculate the same result in Python;
- reconcile both implementations over multiple scenarios;
- move only the proven section;
- retain visible control totals in Excel.
The result should be easier to understand than the original model, not merely shorter on the worksheet.
Migrating a Jupyter notebook
A Jupyter notebook is often written for its author. A workbook application is written for an operator.
That difference matters more than the notebook technology.
A migration should answer:
- Which values should the operator control?
- Which workbook ranges are application inputs?
- Which code cells are really reusable model functions?
- Which outputs belong in the notebook UI?
- Which results must return to worksheet formulas?
- How should invalid inputs be shown?
- What happens when a package or external service is unavailable?
- Can someone other than the author operate the saved artifact?
With Boardflare, the target pattern is:
Workbook inputs
│
▼
bf.inputs(...)
│
▼
Reactive marimo model
│
├── validation
├── calculations
├── controls
└── visualizations
│
▼
bf.publish(...)
│
├── BF.OUTPUT(...)
└── BF.FUNCTION(...)
The important migration is therefore author notebook → operator application, not Jupyter syntax → marimo syntax.
Migrating external Python into Excel
The right answer may be to move only part of the application.
For example:
External Python / SQL
│
├── ingestion
├── file processing
├── scheduled jobs
└── governed preparation
│
▼
Excel workbook
│
├── assumptions
├── review
└── stakeholder interface
│
▼
Interactive Python layer
│
├── scenarios
├── model logic
└── application UI
This keeps system automation in the environment designed for it while moving the interactive decision layer closer to users.
A practical migration sequence
1. Document the current contract
Write down:
- inputs;
- outputs;
- business rules;
- manual steps;
- external dependencies;
- expected error conditions;
- users and maintainers.
If those cannot be described, the migration is not ready.
2. Preserve a known-good baseline
Keep representative workbooks and expected outputs. Important finance/accounting migrations should include reconciliations and independently checked examples.
3. Move one boundary at a time
Do not rewrite formulas, VBA, imports, UI, and reports simultaneously unless there is a compelling reason.
4. Add validation before adding features
Python makes it easier to create more sophisticated logic, but sophistication without input validation simply creates more sophisticated failures.
5. Test the second-user workflow
For a workbook application, the acceptance test is not “the author's notebook runs.” It is:
A second person can open the saved workbook, understand the controls, change inputs, get correct outputs, and recover from expected errors without maintaining the code.
When not to migrate
Do not move a workflow to Python because:
- Python is fashionable;
- AI can generate the code;
- a simple formula looks less impressive than a script;
- the current Power Query workflow is boring but reliable;
- the owning team cannot support the resulting runtime.
A successful migration reduces complexity at the system level.
Where Boardflare fits
Boardflare is designed for the slice of this problem where Excel should remain the user interface but the underlying model benefits from a reactive Python application layer.
It is not intended to replace external Python for arbitrary system automation, and it should not replace transparent spreadsheet logic that is already the clearest solution.
See the Python for Excel documentation for the current product contract and Examples and Templates for working application patterns.