Turning Excel into a web app is not a matter of uploading a workbook and pressing Convert.
The useful parts of the spreadsheet need to be separated from the spreadsheet mechanics.
A mature operational workbook may contain data, formulas, macros, approvals, reports and years of workarounds. The goal is to preserve the business process while giving users a clearer way to operate it.
Here is a practical seven-step route.
1. Decide whether the spreadsheet is really an operational process
Start with what the workbook does.
Good candidates include spreadsheets used repeatedly for:
- job tracking
- orders
- production planning
- quotations
- stock
- approvals
- inspections
- maintenance
- compliance
- recurring reporting
A spreadsheet used mainly for modelling, forecasting or ad-hoc analysis may still belong in Excel.
A small workbook can still be worth replacing if it runs an important repetitive workflow. Size is not the test.
The first question is:
Is the business repeatedly following a process through this workbook?
If yes, continue.
2. Map the workflow outside the cells
Write down what actually happens.
For each stage, identify:
- who starts it;
- what information they enter;
- what rules apply;
- who checks or approves it;
- what happens next;
- what documents or reports are produced;
- what exceptions occur.
This exposes the real application hidden behind the tabs.
A job tracker might become:
Create job → schedule → update work → record costs → complete → report
That is much easier to design than "rebuild Sheet1 through Sheet12".
3. Separate records from calculations
Identify the core business records.
For example:
- customers
- jobs
- products
- orders
- quotes
- inspections
- users
- approvals
Then identify the calculations and rules that act on those records.
A formula that calculates a selling price may become application logic. A formula that only exists to format a spreadsheet report may disappear entirely.
The new app should not preserve spreadsheet complexity unless the business genuinely needs it.
4. Design screens around user tasks
Users should not need to understand the data model.
A production planner may need a schedule and job detail screen. A manager may need exceptions and approvals. An administrator may need configuration.
Each user should see the information and actions relevant to their role.
This is one of the biggest differences between a spreadsheet and an application. Everyone no longer needs access to the same grid.
5. Build the rules and workflow explicitly
Replace informal instructions such as:
"Change column H to Approved and then email finance"
with application behaviour.
For example:
Approve → store approver and time → lock approved fields → notify finance → update dashboard
Rules should be clear enough to test.
If a workbook contains VBA, see the dedicated guide to converting a VBA spreadsheet to a web app.
6. Test with real scenarios and migrate the data
Use realistic examples from the existing process.
Check:
- calculations;
- permissions;
- required fields;
- approvals;
- reports;
- documents;
- unusual cases;
- imported data.
For migration, clean the spreadsheet before treating every row as permanent application data.
Remove duplicates, explain exceptions and reconcile key totals.
The data migration best practices guide covers this in more detail.
7. Launch with a controlled transition
Avoid keeping two editable systems alive indefinitely.
The original workbook can be retained as a read-only reference while the new application becomes the live process.
Train users around tasks rather than technical architecture.
They should know how to:
- create work;
- update it;
- find it;
- approve it;
- correct mistakes;
- run the reports they need.
The finished system should feel simpler than the workbook it replaces.
How this differs from a custom software development guide
This article is about the decision path from an existing spreadsheet to a working app.
If you want the deeper development view, including data modelling, business rules, UX and testing, read Custom Spreadsheet Software Development.
The two topics overlap, but the intent is different. One helps you understand the journey. The other explains how the software is engineered.
The Spreadsheet Upgrade route
The standard journey is:
Free Fit Check → £295 Spreadsheet Assessment → recommended managed plan and scope
The free fit check helps establish whether the spreadsheet is a sensible candidate before you pay for detailed analysis.
For eligible managed plans, the agreed first build is included subject to the current published terms. Hosting, backups, maintenance, security fixes and support are handled as part of the service.
You can compare the current plans on the pricing page.
If your workbook has already become a repeatable business process, start with the free fit check rather than trying to specify the new app yourself.