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
When a CTO says "we need to replace our SaaS stack," the conversation usually starts in the wrong place: which vendor, what price, which integrations. That framing assumes the thing being replaced is itself a SaaS product with a comparable substitute sitting in a G2 category page.
Most of the time, that's not what's actually running the business. Enterprises replace spreadsheets holding pricing logic. They replace Microsoft Access applications a single employee built a decade ago. They replace SharePoint workflows, low-code apps that graduated past what their platform can handle, and internal portals that quietly became mission-critical. None of these have a direct SaaS competitor to switch to, because none of them started as purchased software. They started as workarounds, and the workaround became the system of record.
SaaS replacement, treated correctly, is a software architecture and business-process question: what does this system actually do, who depends on it, and what does it need to become to keep doing that safely at the scale the business is growing into. The vendor question only makes sense once those are answered.
Before scoping any replacement, it helps to know which category you're dealing with, because each one fails in a different way.
The rest of this guide walks through what actually justifies a rebuild in each category, using a real engagement to show what the hardest version of this problem looks like end to end.
If you already know which system on this list is yours, the temptation is to jump straight to writing requirements. See what a scoped system-mapping assessment actually covers before you write the first one.
Excel earns its place in every enterprise because it does almost anything. That's also why it becomes the hardest thing to replace. A pricing model, a scheduling tool, or an estimation engine that started as a spreadsheet accumulates formula logic for years, and that logic eventually becomes the company's actual intellectual property, sitting in a file format with no access control, no audit trail, and no way to stop someone from copying it onto a USB drive on their way out the door.
This is a real client engagement, where a US-based commercial glazing contractor, ran its entire bidding operation through a single Excel workbook the founder had built and refined over 40 years. The workbook had close to 50 sheets. It captured project takeoffs from architectural drawings, calculated fabrication and installation labor down to the number of anchor points and shear blocks in a curtain wall system, applied 40 years of accumulated labor-time estimates for tasks as specific as cutting a single horizontal face cover, and rolled all of it into a final bid price and a client-ready proposal.
Five to six estimators used the file. None of them, including the founder's own son, had ever been allowed to see the backend calculation logic. That logic was the company's entire competitive advantage, and it had no protection at all. Anyone with the file could copy it, export it, or hand it to a competitor.
The first move was a full dependency map of the workbook, built before any interface design began: which calculation chains were sequential, which ran in parallel, which cells needed to stay open for an estimator's manual judgment, and which parameters varied per job. That map became the spec for everything that followed. The estimation logic moved into a backend Node.js computation service that estimators could never see inside. A React frontend replaced the fifty-sheet interface with role-based access separating estimators from administrators. Automated proposal generation replaced the manual process of assembling a bid document by hand across dozens of sheets.
The mechanism that made this work is the same one that applies to almost every spreadsheet replacement: the value isn't in giving the spreadsheet a nicer interface. It's in moving the logic behind a boundary the user can't see past, so the system produces answers without exposing how it produces them. A spreadsheet can't do that. A backend service can.
A deeper walkthrough of this exact pattern, replacing a decades-old estimation workbook without losing a single business rule, is coveredin this full case study: How a US-Based Commercial Contractor Locked 40 Years of Proprietary Estimation Logic Inside a Governed Web Platform.
If you're carrying a Microsoft Access application, it tends to follow a similar arc to a spreadsheet, but with an added failure mode: the person who built it often left the company years ago, and the VBA logic inside it is now effectively unmaintainable. Nobody wants to touch it because nobody fully understands what breaks if they do.
The fix isn't a lift-and-shift into a newer desktop tool. It's the same dependency-mapping discipline used on the Glacing contractor workbook, applied to forms, macros, and table relationships instead of spreadsheet cells, followed by a rebuild as a governed web application that a team can actually maintain going forward.
If you're staring at a SharePoint workflow, an InfoPath form, or a Nintex process and the plan on the table is "give it a new interface," that plan fixes nothing. The workflow logic underneath, the approval chains, the conditional routing, the data model, was usually built years ago against constraints that no longer apply. A redesign that keeps the old workflow intact just recreates the same bottlenecks in a newer shell.
The workflow itself needs redesigning alongside the interface: what actually needs to route to whom, what data actually needs to persist, and which steps only exist because the old platform couldn't do something better.
If your team has built employee portals, vendor portals, or partner-facing applications in-house, they tend to drift the same way external SaaS sprawl does. Each one was built to solve one team's problem quickly, and over time you end up with several internally-owned applications that don't share a data model, don't share an authentication system, and duplicate functionality that could live in one place.
The difference from external SaaS sprawl is ownership. These systems are already the company's IP, which means consolidating them is a build decision inside your own organization. That makes it a more direct problem to solve, even when it looks just as fragmented on the surface.
If HR, finance, procurement, and compliance in your organization each bought their own systems independently, you already have a specific kind of fragmentation: the same vendor or customer record exists in three systems, updated in one, and stale everywhere else. No single department feels enough pain to justify a rebuild on its own, which is exactly why this category tends to persist longer than it should.
Consolidation only makes sense here when the economics support it. A platform that unifies procurement and finance data has to save more in reconciliation time and error correction than it costs to build and maintain. That comparison has to be run explicitly, with real numbers, and it belongs in the decision framework further down this guide.
Power Apps, Airtable, and Bubble solve a real problem: someone needed something running in a week instead of a quarter. The failure mode isn't the tool. It's the moment the app becomes load-bearing for a process the business depends on, and the platform's licensing model, governance limits, or integration ceiling start constraining what the business can do next.
That moment is a graduation point. The logic already built in the low-code tool is a working specification. Rebuilding it as custom software means keeping what already works and removing the ceiling, rather than starting over from a blank page.
If shadow IT shows up in your environment, it usually gets framed as a security problem, and security is part of it, but the deeper issue is duplication. A team buys or builds a tool without your engineering group knowing, that tool starts holding data that should live in a system of record, and now you have two versions of the truth with no reconciliation process between them.
Fixing this requires more than an audit and a decommission notice. It requires understanding why the team went around the process in the first place, usually because the sanctioned system was too slow or too rigid for what they needed, and building a governed alternative that's actually as fast as the shadow tool was.
Sometimes there's no application to replace at all. The "system" is a sequence of emails, a shared spreadsheet, and an approval process that lives entirely in one person's inbox habits. This is often the strongest replacement candidate in the whole list, because there's no existing software constraining the design. The constraint is capturing a process that's never been written down anywhere except in the heads of the people who run it.
This is exactly the situation with the glazing contractorwas in in one respect even with its workbook: the estimation logic was documented in formulas, but the actual workflow, who reviews what, when a proposal is considered final, what happens if an estimator changes a locked assumption, existed only as informal practice. Part of the engagement's value came from making that workflow explicit for the first time. Automating the spreadsheet alone would have missed it.
This is where replacement stops being about internal efficiency and starts touching revenue directly. Operations and customer-operations software failures slow down a team and also affect service delivery, contract fulfillment, and the customer relationship itself. The bar for a replacement here is higher, because the cost of getting the migration wrong is measured in lost business rather than lost time.
You may not have one broken system. You may have fifteen adequate ones, each doing its job individually, each licensed and maintained separately, each holding a fragment of the same customer or operational data. Replacing them one at a time treats the symptom. The actual cost, duplicated licensing, integration overhead, and data that never fully reconciles across tools, only goes away with a platform engineering approach that consolidates multiple workflows into a single business-owned application.
Retiring a system doesn't automatically mean building custom software. There are four real paths, and the right one depends entirely on the system in front of you.
None of these wins by default. The decision depends on how business-critical the process is, how differentiated it needs to be, how complex the integrations are, and what the system needs to look like at twice today's scale.
The decision comes down to four questions, applied in order.
Run your candidate system through those four questions before you write a single requirement. If you've done that and landed on custom software, you're probably sitting with a system nobody has fully mapped, and a requirements document someone on your team is already drafting from memory instead of from a traced record of what the system actually does. That gap is exactly where replacement projects go over budget: a business rule surfaces mid-build that nobody wrote down anywhere.
Ideas2IT runs a scoped mapping session that traces your candidate system's real dependencies and business rules before anyone writes a requirement. You walk away with a dependency map and a clear read on whether the system belongs in a SaaS product, an automation layer, or a custom build.
Book a scoping session with Ideas2IT
Sometimes the honest answer isn't "replace the tool." It's "the operating system underneath this business process needs to change, and the tool is just the visible part of it." Recent engagement wasn't only replacing a spreadsheet. It was formalizing an approval process that had never existed, building role-based access where none existed before, and creating a version-controlled methodology where five estimators previously worked from five independently drifting copies of the same file.
That's the difference between a SaaS migration and a transformation engagement. A migration moves the same process to new software. A transformation changes what the process actually is, because the old process was never fully defined in the first place.
AI changes the economics of certain replacement decisions, but not in the way the "AI will replace SaaS" headlines suggest. What changes is the cost of doing things that used to require either a large engineering team or an expensive vendor contract: generating documentation for undocumented legacy systems, translating calculation logic between formats, and building governed interfaces faster than a traditional build cycle allowed.
That doesn't mean every spreadsheet or legacy app should wait for an AI-native rebuild. It means the calculus on custom software, previously "too expensive to justify for an internal tool used by five people," is shifting for teams that can apply AI-assisted engineering to the modernization work itself.
If you're carrying more than one candidate from the list above, prioritize using four factors:
A system that scores high on all four, business-critical, widely used, fragmented, and differentiated, is your highest-value replacement candidate. That was true for glacing contractor's estimation workbook. It's usually true for whatever spreadsheet or legacy tool in your own stack makes you nervous every time someone asks what happens if the person who built it leaves.
The execution path that worked for glazing contractor generalizes to most replacement candidates in this guide:
Skipping the first step is the most common failure mode in replacement projects, and it's the one this guide keeps returning to for a reason: every later step depends on it being done right.
Most software replacement engagements fail for a reason that has nothing to do with the technology chosen. They fail because the team writing the specification never fully understood what the system they're replacing actually does, and they find out mid-build when a business rule surfaces that nobody documented.
Ideas2IT's delivery model starts with hands-on architects doing the dependency mapping themselves before scoping or pricing ever happens, well before a single line of production code gets written. That's what happened with the glazing contractor: a full structural analysis of the workbook came first, and the computation service was designed against it. The same discipline applies whether the system being replaced is a spreadsheet, an Access database, or a decade of SharePoint workflows.
For legacy applications specifically, where the undocumented-logic problem is often worse than a spreadsheet because the code itself has no comments and no departed author to ask, Ideas2IT's Legacyleap platform accelerates the comprehension phase: ingesting existing code and dependencies, generating business and technical documentation where none exists, and producing a target architecture recommendation before a rebuild begins.
If your team is carrying a spreadsheet, an Access database, or a legacy workflow that everyone quietly depends on and nobody wants to be the one to touch, the risk is the day the one person who understands it leaves, or the day a competitor gets a copy of it.
Ideas2IT's discovery process maps that system in full before a single requirement gets written, the same process used in every engagement referenced throughout this guide. You get a real dependency map and a scoped recommendation on what replaces it.
Talk to Ideas2IT about a replacement assessment
This piece is part of Ideas2IT's ongoing series on enterprise software replacement. The next piece in this series, How to Replace Excel With Custom Software, walks through the Glazing contractor engagement referenced above in full technical depth.
