Excel Apps Must Die. They Won't.
Somewhere in your company right now, someone is building an application in Excel. They do not call it an application. They call it a tracker, a calculator, a reporting template, or "just a spreadsheet." But it has dropdown validation, conditional formatting that encodes business rules, a hidden sheet full of VLOOKUP formulas that nobody understands, and a macro that sends an email when you click a button someone labeled "Submit." It is an application, and it is running a business process that nobody in IT knows about.
Excel is the cockroach of corporate IT. For every one you find, ten more are lurking somewhere else, in a shared drive, in someone's OneDrive, attached to an email chain from 2019 with the subject line "FINAL_v3_USE_THIS_ONE.xlsx." You cannot kill them. You can only discover them after something breaks.
Why they exist
Excel apps exist because building a "real" application used to be hard. You needed a developer, a database, a server, a deployment pipeline, and six weeks of somebody's time. Meanwhile, Linda in Finance needed to track vendor rebates by Thursday. Linda does not have six weeks. Linda has Excel, and Excel will never tell her no.
This is the core of the problem: the gap between "I need a tool" and "IT can deliver a tool" has historically been measured in months. Excel fills that gap in minutes. It is ugly, fragile, unauditable, and completely ungoverned, but it ships on time every time.
Why 2026 is different
That gap between need and delivery has collapsed. Two things changed at once, and together they remove the original reason Excel apps exist. AI coding assistants collapsed the build time: I can describe a tracking application and have a working prototype in an afternoon, not six weeks, with real data persistence, validation rules, multi-user access, and a proper UI. Not a mockup, and not something disposable, but an application that can be maintained, audited, and governed. At the same time the low-code platforms matured. Oracle APEX and Visual Builder Studio both reached the point where a business analyst with moderate technical skills can build a legitimate application without writing code from scratch, and both work directly with Oracle Fusion Cloud.
The Fusion-specific answer
If your organization runs Oracle Fusion, you already have two application platforms sitting right there, and most companies are barely using either one.
Visual Builder Studio
VB Studio is not a separate product you need to license. It ships with Fusion. It is embedded directly in the platform, uses the same Redwood design system as Fusion itself, and has native access to Fusion's REST APIs and security model. When you build an extension in VB Studio, it looks and behaves like part of Fusion because it literally is part of Fusion.
This is worth distinguishing from standalone VBCS (Visual Builder Cloud Service), which is a separate OCI product with a broader feature set. VB Studio is more constrained, it is purpose-built for Fusion extensibility, not general-purpose app development, but that constraint is also its strength. You are building inside the Fusion sandbox with the same security, navigation, and design patterns your users already know. There is no "it looks like a different app" problem.
Oracle has been pushing VB Studio as the primary extensibility tool for Fusion, and for good reason. Need a custom page that shows data from multiple Fusion modules in one view? A simplified data entry form for a specific business process? A dashboard that combines Fusion data with external sources? VB Studio handles all of these without leaving the Fusion ecosystem. You can find sample applications and starter templates in the Oracle VBCS samples repository.
Oracle APEX with Fusion Quick Start
APEX 24.2 introduced the Fusion Integrated Starter App Wizard, which lets you spin up a new APEX application pre-wired to your Fusion instance. It handles the OAuth configuration, REST service connections, and basic page scaffolding so you can go from zero to a working Fusion-connected app in minutes rather than days of plumbing work.
APEX is the right choice when you need something that goes beyond Fusion extensibility, applications with complex business logic, heavy data processing, or integration with non-Fusion systems. It runs on Oracle Autonomous Database, so you get a full SQL engine behind your application, not just REST API calls. For data-intensive workflows like migration tools, reconciliation dashboards, or operational reporting, APEX with a Fusion connection is hard to beat.
The business case writes itself
Every Excel app in your organization is a liability. It has no access controls, whoever has the file can change anything. It has no audit trail, you cannot prove who changed what or when. It has no backup strategy beyond "I think I saved a copy somewhere." It breaks silently when someone accidentally deletes a formula or sorts a column without expanding the selection. And when the person who built it leaves the company, you inherit a spreadsheet that is indistinguishable from a puzzle box.
A proper application, even a simple one built in APEX or VB Studio in a single day, gives you authentication, audit trails, concurrent multi-user access, data validation that cannot be bypassed, and a deployment that does not depend on someone's laptop being turned on.
The cost of building that application dropped by an order of magnitude this year. The cost of maintaining the Excel app has not changed at all. The math has flipped.
Why they still will not die
And yet. Excel apps will survive 2026, 2027, and probably 2037. Here is why.
The first reason is discovery. You cannot replace what you cannot find, and shadow-IT spreadsheets are invisible to governance because they live in personal drives, email attachments, and Teams channels. Most organizations have no mechanism for finding them at all.
The second reason is that they work. Not well, not safely, not scalably, but Linda's rebate tracker does what Linda needs, and it has done it for four years. Asking her to learn a new tool and rebuild something that already works is a tough sell, no matter how much better the alternative is.
The third reason is priority. Even when the tools exist and the business case is obvious, replacing an Excel app takes someone deciding it matters more than the next deadline, and it never does. There is always a bigger project, a tighter deadline, a more visible initiative. Excel apps survive because nobody is specifically tasked with killing them.
The last reason is reach. Everyone already has Excel, everyone knows the basics, and there is no provisioning, training, or access request between the idea and a working sheet. The friction to start is zero, and every other platform, no matter how good, has more friction than zero.
What actually works
The organizations that successfully reduce their Excel app footprint do not try to eliminate all of them at once. They do two things:
First, they make the alternative easy. Pre-built APEX starter apps. VB Studio templates. AI-assisted prototyping sessions where a business analyst and a developer sit down and build a replacement in a single meeting. If the replacement takes longer to build than the Excel version took, you have already lost.
Second, they target the ones that hurt. The spreadsheet that feeds a journal entry. The tracker that determines who gets paid. The one that has compliance implications. You do not need to kill every Excel app, you need to kill the ones that can cause real damage when they break.
Come talk about this at Ascend
If this topic resonates with you, I will be presenting on Visual Builder Studio and Fusion extensibility at Ascend 2026 (June 8-11, Orlando). We will get into the practical details of replacing spreadsheet-driven processes with proper applications built on the tools Oracle already gives you. I would love to see you there.
Excel is not going anywhere. But the next time someone asks you to "just throw together a quick spreadsheet," remember that you have better options now, and the gap between quick-and-dirty and quick-and-proper has never been smaller.