Excel to Python: A Migration Playbook for UK SMEs

Most UK SMEs run on Excel. Pricing, inventory, reporting, customer lists, dispatch schedules — all in spreadsheets that grew organically over years. At some point the spreadsheets become the bottleneck: too slow, too error-prone, too tied to one person who knows the formulas. This is the playbook for migrating to Python without disrupting the business.

When to migrate

Stay on Excel as long as: the spreadsheet works, only one or two people edit it, and it doesn't need to integrate with other systems. Migrate when any of these become true:

• The spreadsheet has crashed Excel more than twice in the last month.
• You have multiple people editing the same file and dealing with merge conflicts.
• You're manually re-typing data into the spreadsheet from emails or other systems.
• A formula error caused real cost (wrong customer charged, wrong inventory order).
• The person who built the spreadsheet is the only one who understands it.
• You need data from the spreadsheet visible in another system (dashboard, CRM, API).

What to migrate first

Don't migrate everything at once. Pick the one process where Excel is causing real pain — usually one of: pricing/quoting, customer reporting, inventory/stock, or a manual data-entry workflow. Get that one working in Python, learn the pattern, then expand.

The migration steps

1. Document what the spreadsheet actually does. Not the formulas — the business logic. “If the customer is in the gold tier and the order is over £500, apply a 12% discount, unless it's the first order of the month, in which case 15%.” Write it in plain English first.
2. Identify the inputs. Where does the data come from? Manual entry? Another system? A CSV export? The migration replaces the manual-entry parts with direct integration.
3. Identify the outputs. Who needs to see the result, in what format, and where? The migration replaces these with API calls, scheduled reports, or live dashboards.
4. Build the Python version of just the logic. Plain functions, well-tested. Run it alongside the Excel version for a week or two on the same inputs, compare outputs, fix discrepancies.
5. Replace the inputs. Now the data flows in automatically: API pulls, webhook ingest, scheduled fetches.
6. Replace the outputs. The Python version writes to where the data needs to go (database, dashboard, email, API).
7. Retire the spreadsheet. Keep a snapshot for reference. Don't delete the original — but stop maintaining it.

The interface trap

A common mistake: trying to replicate the Excel UI in Python. Don't. The reason your team likes Excel is its grid view, formulas, sorting, filtering. A bad Python web UI will lose to Excel every time. Instead: keep Excel as a read-only output destination if you must, but make the source of truth the database. Export to .xlsx files for people who want to manipulate them locally; the Python system is the system of record.

What to keep in Excel

After migration, Excel still has a role: ad-hoc analysis, financial modeling, prototyping the next thing you'll eventually migrate, and as a viewing tool for non-technical users. The goal isn't to eliminate Excel; it's to stop Excel being the production system for processes that have outgrown it.

See our five Python libraries post for the toolkit, or the invoice automation case study for a worked example of an Excel-replacement project.

Sree Jagatab is an AI automation engineer based in Wisbech, Cambridgeshire. He builds custom Python and AI automation for UK SMEs across Cambridge, Peterborough, and the surrounding region. More about Sree →