How to replace Excel with a web app

An Excel file serves as a database when your team keeps a shared record in it, such as its customers or orders. Microsoft explains the difference using its own database, Access. Users of an Access database collaborate on a set of data, while users of an Excel workbook collaborate on a document (Microsoft on Access or Excel (external site)).

Why: Each of these signs costs working time or puts your data at risk.

Sources for the table, all from Microsoft except the last row: co-authoring (external site), locked files (external site), protection and security (external site), Document Inspector (external site), Show Changes (external site) and help with Show Changes (external site), leading zeros (external site), data validation (external site); BSI, module APP.1.1 (external site) (in German).

Research in genomics shows how common automatic conversion errors are. In 30.9% of 11,117 articles with gene lists in Excel supplements, gene names had been converted, for example into dates (Abeysooriya et al., 2021 (external site)).

How to do it:

1. Go through the five signs with the people who work with the file every day. For each sign, note an example from recent weeks.
2. Check where the file is stored and which version of Excel everyone uses. Support for Excel 2016 and 2019 ended on October 14, 2025, and for Excel 2021 on October 13, 2026 (end of support in 2025 (external site), end of support in 2026 (external site)).
3. Estimate how many hours a week go into waiting, cross-checking and corrections. Our how-to Digitizing business processes shows how to measure that.

Example: Say a company with 15 employees keeps its orders in a file on a shared network drive. The office team and the technicians wait several times a day for the file to become free. Anyone can unhide the prices on the hidden sheet, and only one colleague understands the macro that assigns order numbers.

Common mistake: The team judges the limit by the number of rows. According to Microsoft, a worksheet holds 1,048,576 rows (Excel specifications and limits (external site)). Problems with simultaneous access, permissions and data quality start much sooner.

Done when you know for each sign whether it applies, with an example and an estimate of the hours it costs per week.

For admin panels and back-office tools on your existing data, see our page on internal tools.

For keeping track of items in a simple list with limited collaboration, Microsoft still recommends Excel. Version history works only for files stored in OneDrive or SharePoint (Microsoft on previous versions (external site)). You can also combine options: Microsoft itself suggests storing data in a database such as Access and analyzing it in Excel.

How to do it:

1. Write down your must-have requirements: data, roles and their permissions, rules and the programs the new system has to connect to. Our how-to on writing a software requirements specification includes a template.
2. Check first whether the first option is enough. For a list that two or three people maintain, it may be.
3. Test off-the-shelf products with a copy of your data that has names and contact details removed, and ask how you can export all of your data. Our comparison Build or buy software? shows when buying pays off and when building does. Our comparison CRM vs. ERP for small businesses shows which kind of product fits: a CRM, an ERP or industry-specific software.
4. For a platform, add up the license costs over the planned lifetime. Our comparison Low-code vs. custom development shows where low-code is enough.
5. For a custom web app, agree up front that the source code, documentation and access credentials stay with you. Our how-to Avoiding developer lock-in shows how.

In a process check, we map your process with you and first assess whether off-the-shelf software fits. Our custom business software page explains what’s in a process check.

Example: In the example company, the office team should be able to change prices, while the technicians should see only their own assignments. Two industry-specific products it tests can’t handle the technicians’ inspection reports. The company decides on a web app that exchanges data with its invoicing software.

Common mistake: The product gets chosen before the must-have requirements are settled. If it fits poorly, users may turn to other programs, for example back to a list of their own. The BSI describes this risk in its module APP.6 (external site) (in German).

Done when your must-have requirements are in writing and you’ve noted for each option whether it meets them.

Why: Anything missing from the inventory will be missing from the new app later. The V-Modell XT Bund is the German federal administration’s reference model for systems development projects. When a legacy system is replaced, the model calls for a legacy system analysis. It identifies the data model and assesses the quality of the data (V-Modell XT Bund, version 2.3 (external site), in German).

How to do it:

1. Gather every file the process uses, including copies on desktops and lists that individual people keep on the side.
2. For each sheet and column, note what it contains, who maintains the values and who needs them.
3. Look for anything hidden: the Document Inspector (File › Info › Check for Issues › Inspect Document) finds hidden rows, columns and worksheets. Don’t remove anything there, because Microsoft warns that this can change the results of formulas.
4. Check whether the workbook pulls values from other files. The Workbook Links pane (Data › Queries and Connections › Workbook Links) lists these links (Microsoft on workbook links (external site)).
5. Have someone explain each macro to you, and write down what it does. The BSI advises documenting homegrown tools like these in Office programs.
6. Ask your tax advisor which data in the file matters for tax purposes, and how long and in what form to keep the old file. Bring your inventory along.

Example: In the example company, the inventory covers the file OrderList.xlsx with an Orders sheet of 17 columns. Add to that a hidden sheet with prices, a link to the file Customers.xlsx and a macro that assigns order numbers. The technicians also keep their own list of assignments.

Common mistake: Only the main file gets inventoried. Then the separate lists are missing, and so is the rule the macro uses to assign numbers.

Done when every column has a purpose and an owner, every formula, macro and link is described, and the retention question is with your tax advisor.

Why: In a list that has grown over time, the customer appears in every order row. If the customer’s address changes, every one of those rows has to be updated, and a row that gets missed contradicts the others. According to Microsoft, duplicate information increases the likelihood of errors and inconsistencies (Database design basics (external site)).

How to do it:

1. Create a separate table for each kind of thing. If you keep typing the same information again and again, it belongs in a second table that’s linked to the first.
2. Break up numbered columns such as “Item 1” to “Item 5.” According to Microsoft, they force an upper limit and make sorting harder. Line items get a table of their own.
3. Break each piece of information into its smallest useful parts, such as street, postal code and city.
4. Give every row a unique number that never changes. Names don’t work for this, because two customers can have the same name.
5. For each field, define its type, whether it’s required and which values are allowed. Set up postal codes and numbers with a leading zero as text, because Excel automatically removes leading zeros from numbers.
6. Decide which role may view and change which table. The BSI recommends granting permissions only as far as a task actually requires (BSI, module ORP.4 (external site), in German).
7. Decide which changes the app logs: who made the change, when, and what the value was before. Protect the log itself against later changes. Roles, permissions and backups are part of that.
8. Walk through the model with a few real cases before any coding starts. Microsoft also advises testing a design with sample data.

Common mistake: The columns get copied over one to one. Then customers are duplicated in the new app just as they were in the file, and the “Item 1” to “Item 5” columns still impose an upper limit.

Done when every column in the inventory has a target or has been dropped on purpose, every row in every table has a unique number, and you’ve walked through the model with real cases.

Why: Errors carried over in the import often surface only much later. According to the BSI, input errors can lead to unwanted transactions that often go unnoticed for a long time (BSI, elementary threats (external site), in German).

How to do it:

1. Work only with a copy, and label it clearly as a working copy, for example in the file name. The original stays unchanged and read-only until the retention question is settled. Read-only status alone isn’t always enough: data you have to retain must stay readable and analyzable for the entire retention period. If a service provider migrates the data for you, check with your data protection advisor which contracts you need.
2. Check the copy with the formulas under From our work.
3. For each duplicate, decide which record is correct and merge the details. According to Microsoft, the command for removing duplicates deletes them permanently and keeps only the first occurrence (Microsoft on removing duplicate values (external site)). That isn’t always the up-to-date record. Keep a change list of every cleanup that changes the content.
4. For each field, note which column it comes from and how it gets converted, so you can trace the migrated data back to the original. The V-Modell plans a data migration in this much detail, too.
5. Export each sheet separately, because Excel saves only the current worksheet to a CSV file (Microsoft on exporting to CSV (external site)).
6. Before the trial run, note the row count and totals for each table, and compare them with the new app afterward. The people who work with the data also check a sample field by field, such as 50 randomly selected records.
7. Define how you’ll know to abort and how you’ll restore the previous state. The V-Modell calls for this kind of rollback plan, too.

Example: The example copy holds 1,240 orders and 418 customers. After 27 duplicates are merged, 391 customers remain. After the trial run, the new app shows 1,240 orders and 391 customers, and the total matches to the cent. The sample turns up two dates stored as text. The team corrects them in the copy and repeats the trial run.

Common mistake: The cleanup happens in the original. Afterward, nobody knows what the file contained before.

Done when the row counts and totals match before and after the trial run, the sample shows no discrepancies and the rollback plan is in place.

Why: If both systems are kept up to date, their data soon stops matching. The V-Modell XT Bund calls running the old and new systems in parallel problematic because the data has to stay consistent. In general, it considers a phased rollout less risky than switching over in a single step.

How to do it:

1. Choose how to switch: everyone on one cutover date, team by team, or one process first and then the next.
2. For each type of data, decide where it’s entered and from what date. From that day on, the Excel file is read-only, for example through the folder permissions or a password to modify the file.
3. Set the end date and the criteria for aborting, for example: the new app is unavailable two days in a row.
4. On cutover day, migrate the changes made since the trial run and repeat the comparison.
5. After that, keep the old file read-only, in the way you agreed with your tax advisor. Check that it stays readable and analyzable for the entire retention period, including its links and the software it needs.

Example: In the example company, the office team switches first. For two weeks, it enters orders only in the new app, and the technicians read them there. During that time, the technicians keep logging their assignments in their own list. Then the technicians switch too, and the old file is available read-only.

Common mistake: Everyone enters everything twice, in Excel and in the new app, and there’s no end date. After a few weeks, nobody knows which version is current.

Done when the switch is complete, everyone knows where to enter data, and the old file can only be read.

Why: According to the German federal government’s organization manual, process improvements often fail because the people involved don’t accept the new process. The more involved they were in developing it, the greater their acceptance usually is (organization manual on introducing new processes (external site), in German).

How to do it:

1. Involve the people who maintain the file today as early as the data model. They know the special cases.
2. Train role by role in a test environment with a copy of your data, using cases from the past week.
3. Give each role one page of instructions: What’s new, where is everything, and who do you ask?
4. Name a go-to person on the team, and collect questions and bugs in one place.
5. After two weeks and again after four, check whether everyone is working in the new app. The manual recommends this check so that nobody gradually slips back into old routines.

Example: In the example company, the office team practices for an hour with five orders from the previous week, and the technicians practice with three assignments on a tablet. After two weeks, it turns out that the technicians are still collecting photos in a folder. So the app gets a field for attachments.

Common mistake: Training happens weeks before launch, with made-up data. By the time of the switch, most of it is forgotten, and the everyday special cases never came up.

Done when everyone has done their usual tasks in the new app and, four weeks after the switch, nobody keeps a separate list anymore.

Microsoft calls Access a relational database management system (Database design basics (external site)). When an Access database is stored in a shared network folder, it locks only the individual records that someone is editing (Microsoft on Access or Excel (external site)). Microsoft lists the support dates on its lifecycle pages for the end of support in 2025 (external site) and the end of support in 2026 (external site). Our how-to Replacing Microsoft Access covers what Access adds.