Migrating Excel Workflows to Python: What to Move, What to Keep, and Where the Code Should Run

Excel
Python
Migration
A practical framework for deciding which spreadsheet responsibilities should stay in Excel, move into Python, or remain in an external automation layer.
Published

June 3, 2026

“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. Microsoft’s Power Query documentation describes Power Query as a refreshable way to connect, shape, combine, and load data, while Office Scripts cover repeatable workbook automation. 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. This is an architectural recommendation, not a claim that Python is inherently better:

  • 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.” Runtime constraints should be checked before any rewrite. Microsoft’s native option runs Python in a managed cloud container with workbook and Power Query inputs, while browser runtimes such as Pyodide have their own WebAssembly and browser-environment limitations. Those are different boundaries, but both are reasons to keep file- and system-heavy work outside an in-workbook runtime when the workflow depends on unrestricted operating-system access.

Worked example: migrate the model, keep the workbook contract

Consider a revenue-planning workbook that has evolved into a chain of copied formulas and helper sheets. Users still like entering assumptions in Excel and reviewing the final forecast there, but the model now includes scenario adjustments, uncertainty, simulation, and a reusable projection calculation.

The least useful migration would translate every helper-cell formula into one long Python script. A better migration changes the boundary.

Before

flowchart LR
    A[Drivers sheet] --> B[Copied formulas]
    B --> C[Helper sheets]
    C --> D[Scenario macros]
    D --> E[Forecast sheet]
    E --> F[Management review]

After

flowchart LR
    A[Drivers sheet] --> B[bf.inputs]
    B --> C[Reactive Python model]
    C --> D[Scenario controls + validation]
    D --> E[bf.publish]
    E --> F[BF.OUTPUT forecast]
    E --> G[BF.FUNCTION project_arr]
    F --> H[Management review]
    G --> H

The workbook keeps the assumptions and review surface. Python takes ownership of the software-like model. The public contract can remain small:

import boardflare as bf

inputs = bf.inputs(
    assumptions=bf.ref("Drivers!A4:B12", headers=True),
    historical=bf.ref("Drivers!A15:B27", headers=True),
)
inputs

A later cell validates and calculates the forecast. The publication cell then makes only the intended results callable from the workbook:

def project_arr(months: int, growth_rate: float = 0.08):
    # Domain calculation omitted here; this function is independently testable.
    ...

publication = bf.publish(
    outputs={"kpis": kpis, "forecast": forecast},
    functions={"project_arr": project_arr},
)
publication

Excel consumes the explicit contract:

=BF.OUTPUT("forecast")
=BF.FUNCTION("project_arr", 12, C6)

A safe migration would run the old and new models side by side over representative scenarios, reconcile outputs within an agreed tolerance, and keep visible workbook control totals after the Python version becomes primary. The current Sales Scenario Analysis demonstrates this target architecture; it is not evidence that every formula-heavy forecast should be migrated.

What should remain external

Some work should not be pulled into the workbook runtime at all. Microsoft’s Python in Excel security documentation explicitly describes the native runtime’s restricted access to the user’s computer, network, and workbook features, so these boundaries should be checked before choosing an in-workbook design.

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:

  1. freeze a representative test workbook;
  2. document the current inputs and outputs;
  3. calculate the same result in Python;
  4. reconcile both implementations over multiple scenarios;
  5. move only the proven section;
  6. 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 migration does not need to turn every notebook into an application. First decide which responsibilities belong in Excel and which substantial logic belongs in the Python notebook. A reactive notebook such as marimo changes the execution model compared with a conventional Jupyter workflow, but it does not change the architectural question.

That boundary matters more than the notebook technology.

A migration should answer:

  • Which values should remain workbook inputs or notebook controls?
  • Which workbook ranges should be explicit notebook 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?
  • If someone else will use it, do they need the full Edit surface or a simpler App presentation?

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 spreadsheet logic → clear Excel/notebook responsibilities, not Jupyter syntax → marimo syntax. If the finished notebook later becomes a repeatable tool, Open as: App can provide a simplified presentation of that same source.

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-connected notebook, the acceptance test is not merely “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 part of the workflow but substantial Python logic benefits from a coherent reactive notebook.

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 the Python in Excel template library for runnable workbooks, interactive demos, and worked notebook patterns.