From Spreadsheets to Software: What to Keep, Change and Leave Behind

01

The spreadsheet has already done useful product discovery

Imagine a field services business that manages enquiries, jobs and completed visits through one workbook. There is a customer tab, a job list, a pricing sheet and a weekly report. Formulas calculate charges. Colours show which work is urgent. A macro produces an export for finance. Supporting photographs and documents live in folders named after the job number.

It may look untidy to an outsider, but the workbook has helped the team learn. New columns appeared when customers asked for different information. Statuses changed when the original process proved too simple. A separate tab grew around one awkward exception. The spreadsheet became a cheap, editable prototype of how the operation works.

That knowledge is valuable. Throwing the workbook away and starting from a blank requirements document would lose the language, rules and examples the team has developed through real work. The spreadsheet deserves to be studied before it is replaced.

It should not, however, be treated as a perfect specification. A workbook records both the useful process and every compromise made because the tool had limits. Hidden columns, copied formulas and colour codes may represent genuine needs. They may also be habits that no longer make sense. The first job is to tell the difference.

02

Converting a spreadsheet is not a file conversion

The phrase convert this spreadsheet into an app sounds reassuringly mechanical. Import the columns, create a form for each tab and reproduce the formulas in code. The business receives a familiar interface and development appears easier to estimate.

That approach can produce a smarter looking spreadsheet with the same weaknesses underneath. If the original workbook repeats customer details across five tabs, the new application may repeat them across five screens. If nobody agrees what complete means, adding a dropdown will not settle the decision. If a red cell tells an experienced coordinator to make a phone call, moving the colour into a dashboard does not capture the judgement behind it.

The better mental model is translation. The workbook is evidence written in the language of rows, cells, formulas and tabs. The software needs to express the same operation through records, relationships, permissions, actions and history. Some details survive unchanged. Others need to be made explicit. A few should be left behind on purpose.

This is also why the first answer should not automatically be bespoke software. Once the real need is understood, an established product, a small integration or a better controlled spreadsheet may be enough. Discovery protects the business from spending money on a faithful copy of the wrong thing.

03

Read the workbook like an operational document

Start with an inventory. List the workbooks, tabs, local copies, exports, macros, folder structures and inboxes that support the process. Ask which file is trusted when two versions disagree. Record who creates information, who checks it, who changes it and who depends on the result.

Then inspect the workbook for clues. Column headings reveal the facts the team believes it needs. Formulas reveal calculations and dependencies. Validation lists reveal allowed choices. Colours often reveal urgency, ownership or an exception. Hidden sheets may support lookups or reports. Free text fields reveal where the formal process runs out and people need to explain what really happened.

A formula should be translated into an agreed business rule, not merely copied into another programming language. Ask what it calculates, when it should run, who can override the result and what evidence needs keeping when the inputs change. The answer may expose a rule that has been applied inconsistently for years.

Do the same with reports and exports. A weekly summary may exist because a manager needs visibility, because finance requires a file, or simply because the workbook has always produced one. The underlying need could be a live queue, an automatic integration or a clearer handover rather than another report button.

04

Follow one real case from arrival to outcome

Screens are easier to discuss than workflows, so projects often jump to dashboards too early. A better starting point is one representative piece of work. Follow a real enquiry from arrival through validation, assignment, evidence collection, review, approval, invoicing and reporting.

Observe the people doing the work instead of relying only on a manager describing the official process. Ask what information they look for, which decisions need judgement, where they copy data, who they chase and what makes a case unusual. Include the people who support the process, not only the person who originally created the workbook.

GOV.UK service guidance recommends understanding the full context and the problem users are trying to solve before focusing on a particular solution. That principle applies just as well to an internal business system. The important outcome is not that somebody updates a row. It may be that a valid job reaches the right engineer with the evidence needed to complete it.

Write the journey in plain business language. Request received. Required information checked. Job assigned. Visit completed. Evidence reviewed. Charge approved. Customer updated. Each step should have an owner, a clear outcome and an explanation of what happens when the normal route fails.

05

Separate data, rules, actions and views

A spreadsheet places many different concerns on one surface. A customer name is data. A formula is a rule. Changing a status is an action. A filtered tab is a view. Cell protection is a limited permission control. The move to software is a chance to separate those responsibilities properly.

For the field services example, the main records might be customers, sites, jobs, visits, documents, tasks, approvals and charges. Their relationships matter more than the old tab boundaries. One customer can have several sites. A job belongs to a site. A visit belongs to a job and can produce several documents. An approval records who accepted a result and when.

Rules describe what must be true. A visit cannot be approved without required evidence. A charge may need a manager when it exceeds an agreed threshold. Actions describe what a person can do. A coordinator assigns work, an engineer submits evidence and a reviewer approves or returns it. Views show each role the information needed for its next decision.

Permissions need the same clarity. Microsoft explicitly notes that worksheet protection is not intended as a security feature. A business application can apply access at the action and record level, but only after the business defines who should see, change, approve and administer each part of the process.

History also deserves its own design. Important changes should record who acted, when they acted and what changed. That does not mean logging every mouse movement. It means preserving enough evidence to investigate a mistake, answer a customer question or understand why a decision was made.

06

Choose the smallest sensible next move

Once the operation is visible, compare the available routes. The right answer depends on how unusual the process is, how much risk the current arrangement carries and how much responsibility the business wants to own.

The table below is a decision aid rather than a rigid scoring system. A short discovery should test the strongest option using representative users and data before the business commits to a full implementation.

07

Build one complete slice instead of every feature

A sensible first release should complete one useful journey from beginning to end. For the field services business, that might be receiving a job, checking the required information, assigning the visit, collecting evidence and approving the result. It is narrow enough to build and test, but complete enough to prove that the new system helps the operation.

A collection of disconnected screens is not a smaller release. A dashboard, customer list and document area may look impressive while leaving the real handover in email. Vertical scope means choosing one outcome and including the records, rules, permissions and integrations needed to achieve it properly.

Prototype the journey before building production software. A clickable design can help staff react to labels, order, missing information and awkward decisions while changes are still cheap. GOV.UK guidance describes prototypes as a way to explore and test designs before committing to the live service. The prototype is evidence for the build, not the live system itself.

The first slice should also define what is deliberately excluded. Perhaps finance continues receiving a controlled export during phase one. Perhaps historical jobs remain read only. Those boundaries stop the project quietly expanding into every possible workflow before the core route has been proved.

08

Migrate information without importing old confusion

The workbook may contain years of history, but not every row deserves to become a live record. Decide which information is operationally useful, which must be retained for a legal or commercial reason and which can remain in a protected archive.

Profile the source before designing the import. Look for duplicate customers, missing identifiers, inconsistent dates, several spellings of the same status, formulas replaced with typed values and documents that no longer match their reference. Record the rules used to clean each problem so the migration can be explained and repeated.

Map spreadsheet columns to the new records and relationships. A repeated address may become one site record referenced by many jobs. Several status columns may become an ordered history. A free text notes cell may need separating into comments, decisions and evidence rather than being copied into one enormous field.

Run a rehearsal import with representative data. Check known customers, live jobs, totals, documents and edge cases against the original source. Rejected records should be visible with a reason. A successful import means the team can use and trust the information, not simply that a script reached the final row.

09

Plan the change of habit as carefully as the code

A new application changes who does what, when they do it and where the trusted answer lives. That is an operational change, not only a technical release.

Start with a small group handling real work. Watch for labels they do not understand, information they still keep elsewhere and steps that take longer than the old route. Fix those problems before asking the entire business to change at once. The people closest to the process will usually find gaps that no requirements workshop could predict.

Parallel running can reduce cutover risk for a short period, but it needs a clear purpose and end date. If staff keep updating both systems indefinitely, disagreements become inevitable and nobody knows which answer is current. Decide when the new application becomes the source of truth, what remains available as read only and how the team will handle work that started before the change.

Training should use familiar cases rather than a tour of every button. Show each role how to complete its normal work, what to do when the route is unusual and where to ask for help. The interface should still be understandable without a manual. Training supports the transition; it should not compensate for confusing software.

10

Software replaces workbook risk with owned responsibility

Moving to software can provide clearer permissions, tested calculations, dependable history, integrations and simpler views. It also creates an application that needs operating. Hosting, monitoring, backups, security updates, support and future changes require an owner and a budget.

This is an important boundary. A well governed spreadsheet may be the better choice for a small, low risk process. An established product may be better when the workflow is standard. Bespoke software earns its cost when the process is important, the fit genuinely matters and the business is ready to own the result.

Incremental replacement is often safer than a dramatic switch. Martin Fowler describes gradual legacy displacement as a way to introduce value without waiting for a complete rewrite, provided the organisation understands the outcomes and can divide the problem into useful parts. A spreadsheet process can be treated in the same calm way. Move one bounded capability, learn from live use and continue when the evidence supports it.

The workbook was not a mistake. It helped the business discover what mattered. The move from spreadsheets to software succeeds when that knowledge is kept, the accidental complexity is removed and the new system gives people a clearer way to complete the work.

I help established businesses map important spreadsheet processes, test the options and turn the right workflow into software the team can use and support. Bring one representative workbook and one complete piece of work. That is usually enough to start finding the real system inside the cells.