Just In
Ideas2IT is now an OpenAI Select Partner - recognized to help enterprises build, deploy, and scale AI with GPT-5, responsibly and at speed.
Read the announcement
Excel is still the operating system for a large share of enterprise decision-making, and so are Google Sheets, Airtable bases, and Smartsheet trackers doing the same job under a different logo. Excel itself has been in continuous use since 1985, long enough for entire departments to grow up around workbooks nobody ever intended to become permanent infrastructure. Replacing any of them with custom software is a specific, sequenced decision.
This piece walks through when that decision is warranted, what the replacement work actually involves, what it costs to delay in a regulated industry, and how to make the move without stopping the business it currently runs.
Ask a finance director what system runs quarterly forecasting and the honest answer, in a large share of mid-size enterprises, is a workbook with a name like "Master_Forecast_v14_FINAL." The IIA Foundation's 2025 research into enterprise risk management programs found that 59% of organizations still rely on spreadsheets to manage their ERM programs, with only 21% running a dedicated governance, risk, and compliance platform. It is the default state of a majority of enterprise risk functions.
The same pattern shows up outside Excel specifically. A regional operations team standardizes on Google Sheets because it is free and everyone already has a Google account. A marketing team builds its campaign calendar in Airtable because it looked like a lightweight database. A PMO tracks vendor contracts in Smartsheet because someone needed Gantt charts fast. None of these tools were rejected for being spreadsheets. They were adopted because they were the fastest way to get a process running, and none of them were built to be the system of record for a process that will still be running five years later.
A spreadsheet stays a spreadsheet as long as one person uses it to organize their own work. It becomes an application the moment other people depend on it to do theirs, and that transition rarely gets a formal decision point.
The signals are consistent across industries. A workbook grows a macro that only one former employee ever fully understood, and everyone else treats it as a black box they are afraid to touch. A file gets emailed between departments because the underlying data has no single owner, and three people are now editing slightly different versions of the same numbers. An approval step happens by someone typing "approved" in a comment thread because the sheet has no concept of a workflow state. Version conflicts get resolved by whoever saved last, not by whoever had the correct number.
None of this means the underlying process is broken. It means the tool holding the process was never designed to enforce the rules that process now depends on. Excel, Google Sheets, and their peers are calculation surfaces. Row-level permissions were never part of the design. Neither was a workflow engine, or an audit trail that can survive a compliance review. Asking a calculation surface to behave like an application is where the operational strain starts.
The inconvenience of a clunky spreadsheet is visible immediately. The cost of depending on one is visible only when someone tries to add it up.
Start with the labor. Every reconciliation cycle that requires manually pulling numbers from four source systems into one workbook is paid for in analyst hours that never show up on a project budget, because the workbook is not a project. It is just how the report gets made. Add the error rate: a single broken formula reference, copied down a thousand rows before anyone notices, does not announce itself. It shows up as a board deck with a number that turns out to be wrong three weeks later. Add the dependency risk: when the one person who understands the macro logic leaves the company, the process does not fail cleanly. It degrades slowly, as everyone else works around logic they cannot fully explain.
There is a fourth cost that rarely makes it into the budget conversation until something forces the issue: exposure. A workbook with no formula protection is fragile and portable at the same time. Anyone with the file can copy it, and every estimator or analyst who leaves with a laptop takes the methodology with them. That risk sits underneath the labor and error costs above, and it is the one that turns a spreadsheet replacement from a productivity project into a governance decision.
Gartner has forecast that by 2026, more than 70% of finance organizations will have moved away from spreadsheets as their primary planning tool, a shift driven less by technology preference than by how badly manual reconciliation holds up under volatile, fast-changing business conditions.
If your organization has not yet put a number on that cost, a working session on what your current workflow is actually costing in hours, errors, and risk is a reasonable place to start before committing to any specific fix.
The cost above is generic. It gets sharper and more specific once a spreadsheet sits inside a regulated process or holds proprietary methodology, because the failure mode stops being "the numbers were wrong" and becomes "the auditor asked a question the file cannot answer" or "the file walked out the door with the person who built it."
Financial services: Sarbanes-Oxley Section 404 requires documented, auditable controls over financial reporting. A spreadsheet, as a plain file rather than a managed system, cannot produce an immutable record of who changed which cell and when, which is exactly the standard a SOX audit expects a financial control to meet. That gap does not surface during a quiet quarter. It surfaces the first time an auditor asks for a change history and the answer is a shared drive full of file names ending in "v2" and "FINAL."
Life sciences and regulated manufacturing: Excel is not automatically compliant with FDA 21 CFR Part 11 just because it is a commercial product from a reputable vendor. Once a spreadsheet used in a GxP process gains a macro or custom function, it moves into a validation category that requires the same rigor as purpose-built software. The FDA issued 303 drug warning letters in fiscal year 2025, a 59% increase over the prior year, and more than a quarter of the letters aimed at regulated laboratories cited failures in method or process validation.
Healthcare operations: HIPAA's Security Rule expects access controls and audit logging around anything touching patient or workforce data. A spreadsheet passed between HR, finance, and clinical operations by email does not meet that bar by design, regardless of how carefully the people using it behave.
Manufacturing and specialized trades: The risk here is a competitor rather than a regulator. A pricing or estimation workbook with no formula protection is fragile and exportable at the same time. A completed Ideas2IT engagement for a US-based commercial glazing contractor illustrates exactly this pattern: the client had run its entire estimating operation on the same Excel workbook for 40 years, with five estimators holding five independent copies and no governance over any of them. Read the case study.
If any of the four patterns above describes a workflow your organization runs today, the risk is not hypothetical. It is a matter of which audit, resignation, or competitor bid surfaces it.
Running a process in a regulated or IP-sensitive part of the business through Excel, Google Sheets, Airtable, or Smartsheet?
Talk to a Custom Software Specialist
Not every Excel-dependent process needs to become custom software. The signal to act is a change in who depends on the sheet and what happens when it is wrong. Watch for these conditions together, not in isolation:
One or two of these showing up occasionally is normal operational friction. Several showing up together, on a process the business actually depends on, is the point where the spreadsheet has become a liability rather than a tool.
That a spreadsheet has become an unofficial application does not automatically mean the answer is custom software. Four paths are usually on the table, and each one earns its place under different conditions.
The decision should follow the shape of the workflow, not a default assumption that anything outgrowing Excel needs a from-scratch build. A team that starts by evaluating the workflow itself, rather than pitching a build before understanding what the process actually requires, is more likely to land on the option that fits, even when that option is "clean up the spreadsheet and revisit this in a year."
Once a build is the right call, the work is not "make Excel look like a website." It is a translation exercise: taking business rules that currently live inside formulas, tab structures, and one person's institutional memory, and re-expressing them as a proper application.
That translation runs through a consistent sequence. The formulas and conditional logic buried in the workbook become explicit business rules, documented and testable instead of implicit and fragile. Those rules get organized into workflows with real states: draft, submitted, approved, closed, each with defined transitions instead of a comment saying "approved." The flat rows and columns become a proper data model, with relationships between entities that a spreadsheet can only fake with VLOOKUPs. Access that used to mean "whoever has the file" becomes role-based permissions. Integrations replace the copy-paste that used to move data between the spreadsheet and every adjacent system. Dashboards replace the manual chart-building that ate an afternoon before every leadership meeting. And every change gets logged, producing the audit trail the spreadsheet never could.
The manufacturing engagement referenced earlier in this piece ran through this exact sequence. The client's estimation workbook had grown to fifty sheets over 40 years, with cross-sheet dependencies that were invisible until something downstream stopped calculating correctly. Before any code was written, Ideas2IT traced every formula dependency across the takeoff, fabrication, installation, and profitability layers of the workbook, producing a dependency map that identified which calculations were sequential, which were parallel, and which needed a manual override zone for estimator judgment.
That map became the specification for a Node.js computation engine built so that estimators see inputs and outputs only, with no visibility into the coefficients or formulas producing them. A React frontend replicated the estimation workflow with role-based access separating estimator, reviewer, and administrator permissions, and a template renderer replaced the manual document assembly that used to consolidate outputs from fifty sheets into a proposal by hand. The whole platform was deployed to the client's own on-premises infrastructure, with no cloud dependency and no external path for the estimation logic to leave the building. Read the case study.
Talking through what this sequence looks like against your specific workflow, before any code gets written, is what a scoping conversation with a custom software development team is for.
The goal of this translation is not to recreate Excel with nicer buttons. A system that just digitizes the existing spreadsheet inherits the same rigidity in a new shell, and misses the actual opportunity the migration creates.
A properly modeled application, with explicit business rules, a real data model, and clean role separation, is also the only kind of system that automation and AI agents can act on safely. An agent cannot reliably parse a spreadsheet's implicit logic to flag an anomaly or draft a recommendation, because the logic was never written down anywhere a machine, or a new hire, could read it directly. It can act on a documented workflow with defined states, a data model with clear relationships, and an audit trail that shows exactly what happened and why.
The same structure that makes the new system auditable for compliance is what makes it usable for automation later. That is the actual argument for building custom software now rather than automating around the spreadsheet indefinitely: the replacement solves today's reconciliation problem and builds the foundation the business will need the next time it wants to add analytics, agents, or automation on top.
The most common reason this kind of replacement stalls is not disagreement about its value. It is fear that the business cannot afford to stop the process while the new system gets built.
A properly sequenced migration does not ask for that trade-off. The existing model gets studied and reverse-engineered first, capturing every formula and dependency rather than guessing at intent. The new system runs in parallel with the existing spreadsheet, producing outputs that get checked line by line against what the workbook already produces, so any discrepancy surfaces before it matters rather than after. Migration happens in phases, tied to natural process boundaries, rather than a single cutover date that puts the whole operation at risk at once. Only after the parallel run validates cleanly does the spreadsheet get retired, and even then it is archived rather than deleted, so historical figures remain traceable.
This is the difference between replacing Excel as an engineering project and replacing it as an operational risk to the business that depends on it.
Here's why Ideas2IT replaces excel with custom software
Ideas2IT staffs Excel replacement projects with Forward Deployed Engineers who work inside the client's existing environment from day one rather than handing over a specification and disappearing. FDEs sit in the client's standups and work against the client's OKRs. They stay embedded through the parallel-run and cutover phases described above, which is precisely where migrations without an embedded team tend to go quiet on the client and slip.
The hardest part of this work is that business rules live inside formulas and one person's institutional memory rather than anywhere written down. Ideas2IT's LegacyLeap platform was built for exactly this comprehension problem: it ingests the existing workbooks and generates structured documentation of the business rules and dependencies buried inside them before a single line of the replacement gets written. That cuts the assessment and documentation work that normally consumes weeks of manual formula tracing, and it produces the audit trail regulated teams need before they can retire the original file.
Anticlock applies a consistent, AI-driven development discipline across the engineering team building the replacement, so decisions on workflow states, data modeling, and permissions get made to one auditable standard instead of depending on whichever developer happens to be assigned that sprint.
Ideas2IT holds SOC 2 Type II certification and is an AWS Partner, and delivers on-premises deployments with no cloud dependency when that is what the engagement requires, as it was for the manufacturing client referenced throughout this piece. Those credentials matter directly here because the audit trail, access control, and IP exposure gaps in the original spreadsheet are usually part of why the replacement got approved in the first place.
The numbers below are from the same manufacturing engagement described earlier in this piece — a completed, live case study rather than a projection.
If an Excel, Google Sheets, Airtable, or Smartsheet workflow your business depends on has reached the point described in this article, Ideas2IT's custom software development team can scope what replacing it would actually take, starting with mapping the business logic your current workbook is quietly holding together.
Ready to see what replacing your Excel, Google Sheets, Airtable, or Smartsheet workflow would actually take?
Talk to an Ideas2IT Custom Software Specialist.
Didn't find what you were looking for?
