Turning an Excel File into an App: The 4 Steps

You have an Excel file that runs part of the business. Order tracking, the team schedule, purchase requests. It has grown over the years, several people edit it, and every week someone asks for "the right version". You suspect it is time to turn it into a real application. Good instinct. The question is how to do it without breaking what works.

Turning an Excel file into an app is not copying columns into another tool. It means rebuilding the process the file ended up carrying, with rules, permissions and guided data entry. Here are the four steps we follow, in order, and what is at stake in each one.

Before you start, one idea to keep in mind: the file is not the process. A ten-year-old Excel file holds three things: useful data, dead columns, and rules that are written nowhere. "If the cell is orange, it means Martine approved it." Nobody documented it, everyone knows it. Migrate the file as is and you migrate the dead columns too, while losing the unwritten rules.

The right reflex is to map the process, not the file. Who enters what, when, who approves, what triggers the next step. If you are still wondering whether to make the move at all, our article on when Excel stops being enough gives you three questions to settle it.

Step 1: scoping and mockup

We start with a workshop with the people who use the file every day. Not just the manager: the person who enters data, the one who checks it, the one who pulls the numbers at month end. Together we sketch the screens, on paper or as a clickable mockup. We list the rules: what is mandatory, what is calculated, what blocks.

The deliverable of this step is a frozen, written scope. That list of what the app does, and what it does not do, protects everyone. It is what the fixed price is based on. Ideas that come later go into a "version 2" list: they are not lost, and they do not derail version 1.

• Output: validated mockup, written scope, list of business rules.
• What you bring: two or three users available for a workshop, and the current file, flaws included.

Step 2: building the core

We build the database and the main screens. Depending on the need, the data goes into a SharePoint list (included in your Microsoft 365) or into Dataverse (premium licensing, sturdier as soon as data is related or voluminous). That choice is made in step 1, never midway.

This is where Excel habits become application mechanics: a dropdown instead of a "roughly right" column, a status instead of a cell colour, a required field instead of a verbal reminder. You see real screens early, and you correct while it is still cheap to change.

Step 3: connecting your data

An isolated app does not replace a shared file. We plug it into what already exists: Outlook for notifications, Teams for alerts, SharePoint for documents, your customer base or your ERP if needed. This is also when we load your real data, once it has been cleaned.

Cleaning deserves a sentence. Duplicates, dates typed as text, customer names spelled four ways: all of that lives in your file, and the app will not accept it. We fix it once and for all, often with Power Automate for the repetitive part.

Step 4: testing and go-live

Testing happens with real users on real cases, not with the vendor alone in front of a screen. We watch where they get stuck, adjust the ergonomics, train the team. Then we put the app into service inside your Microsoft 365, and a 30-day warranty covers fixes.

What makes this step succeed is the testers' availability. The most common slip is not technical: it is users who have no time to test at the right moment. Book their slot as early as scoping.

What changes, in practice

A single source of truth nobody can overwrite by mistake. Guided data entry that stops errors at the source. Role-based permissions: the salesperson sees their deals, management sees everything. A history of who did what. And data that is ready for a Power BI dashboard, with no reprocessing.

If you want to see how these steps chain together on a project, our method details each one with its deliverables. And if your file is already identified, the Build offer turns a scoped process into an application at a fixed price, set at scoping.