Moving from Excel to a business application: steps and a practical example

1. Check what justifies an application

A spreadsheet remains useful for exploring figures, producing a one-off analysis or managing a simple activity. The requirement changes when people have different responsibilities, a reliable history becomes essential or repeated data entry causes recurring mistakes.

Record actual incidents: a lost request, an outdated copy or information changed without approval. Measure how often they occur and the time spent correcting them. These observations help define the intended outcome and later assess whether the application is useful.

• Who creates, completes, approves and reads the information?
• Which errors or repetitive tasks need to decrease?
• Which analyses must remain available as Excel exports?

2. Define one complete workflow

Choose a process that can be followed from beginning to end. For purchase requests, it starts with entering a need and ends with approval or rejection. Supplier management, accounting and advanced reporting can belong to a later phase.

Describe screens through the actions people need to perform, then classify features as essential, useful or deferrable. Include incomplete requests, an absent approver, cancellation and changes after a decision. These situations often reveal rules that the workbook leaves implicit.

3. A fictional purchase request example

In this illustrative scenario, an employee enters the reason for a purchase, its estimated amount and an attachment. Their manager can request clarification, approve or reject it. Purchasing sees approved requests and later adds a purchase order reference.

Each request has a stable identifier, a status and a history. An example rule requires a second approval above EUR 2,000; the threshold must match the business. Changing the amount after approval triggers another review instead of silently changing an approved record.

• Draft: the requester can still edit the record.
• Awaiting approval: the manager decides or asks for more information.
• Approved or rejected: the decision and its author are retained.
• Ordered: a reference links the request to the purchase.

4. Prepare the workbook data migration

Inventory worksheets, columns, formulas, macros and linked files. A formula may represent a business rule to preserve; a colour may indicate an exception that needs its own field. Identify duplicate records, free-text cells and inconsistent formats.

Map source columns to application fields. Test an import from a copy, retain rejected rows with a reason and have the business check totals and representative records. Agree when the source workbook becomes read-only and how to handle changes made during the transition.

5. Plan permissions and connections

Create a role-based permissions matrix covering reading, creation, editing, approval and exports. Enforce permissions on the server, including direct attempts to access somebody else’s record. Define the events to log and retention periods suited to the intended use.

List the connections you actually need: identity directory, ERP, notifications or documents. For each exchange, specify the system of record, transferred data and failure handling. A controlled export may be sufficient initially if automatic synchronisation is not yet justified.

6. Run a pilot and decide on the transition

Have users from each role try representative scenarios. Check creation, approval, rejection, permissions and imported data. Set observable acceptance criteria: no records lost in the test dataset, no approval of your own request and an accessible audit history.

Plan training, support and ownership of the application. After launch, keep the historical workbook read-only if needed to avoid competing sources of truth. Compare lead times, duplicate entry and incidents against the baseline rather than promising gains before they are measured.