The hidden cost of one-size-fits-all enterprise SaaS for high-impact industries

The long story, long.

A custom-built vehicle manufacturer. Mid-to-large in revenue. Their product is genuinely complex: every vehicle is built to order, no two configurations identical, and even the raw metal is ordered in batches based on which vehicles are queued for production that month.

The numbers are big. About 170 base configurations. 20 floorplan schematics. 16 sizes. Effectively infinite customizations from there. The catalog holds about 157,000 parts. Any single vehicle uses about 5,000 of them. Lead times are all over the map. Some parts arrive in a week from a domestic supplier. Some take a month from a cross-country one. Some take three months on a slow boat from China. Miss the lead time on one part and the vehicle doesn't ship.

Here's how the company ran when we walked in. Customer wants and configurations lived in Salesforce. Inventory and production scheduling lived in Microsoft Dynamics. Vendor data lived in email threads and Excel files on a shared drive. Financials lived in NetSuite. The four systems did not match. Ever.

The humans were the integration layer. Joe in sales talked to Tom in production. Tom in production talked to Linda in purchasing. Linda emailed a vendor. The vendor replied. Linda updated the spreadsheet. Tom updated Dynamics. Joe maybe updated Salesforce. Most days, the chain held. Some days it didn't. And when it didn't, a vehicle that was supposed to ship in March shipped in May, and the customer had been told March, and somebody had to explain.

Joe forgot to tell Tom that the customer had upgraded their order. Sometimes Tom forgot to tell Linda that the new batch needed three more steel orders. Sometimes Linda didn't know which vendor had the longest lead time on which part because the spreadsheet was last updated by someone who'd left the company. None of these are unusual. They're the everyday gravity of a business where four systems and a couple hundred humans are trying to act like one.

To make all of this work, the company had: Salesforce admins to bend Salesforce. Dynamics 365 developers (whatever they're properly called these days) to bend Dynamics. NetSuite consultants to bend NetSuite. And a couple of in-house software engineers writing custom integrations between all four. Plus the consultancies they brought in whenever any of those systems needed a real project. Nuts.

This shape repeats. Not just in custom vehicles. We see it in defense contractors with classified and unclassified data living in incompatible ERPs. In energy companies where operational data, regulatory data, and financial data live in three different vendors. In regulated finance where compliance, trading, and ops each have their own truth. Different industries, same shape: a stack of generic SaaS, an army of platform-specific developers bending each one, a handful of integration engineers gluing it together, and the people on the floor running the actual business through emails and excels.

What the hidden cost actually looks like

Five places, all visible in the manufacturer's story above.

One developer team per system

Salesforce admins, Dynamics devs, NetSuite consultants, plus the integration team. None of those headcounts is wrong on its own. Together they're a tax that doesn't show up as a single line item on a CFO report because it's split across four cost centers and twelve vendor invoices.

The bending isn't wasted work. It's necessary because none of those systems fits the actual shape of a custom vehicle manufacturer (or a defense contractor, or a regulated bank). The problem is that the bending is forever. Every upgrade re-triggers it. Every vendor change tries to undo it. Every dev who leaves takes a piece of the bending with them.

The integration tax

Custom code between Salesforce and Dynamics. Custom code between Dynamics and NetSuite. Custom code from the vendor spreadsheets to anywhere they need to land. An iPaaS subscription somewhere. Nightly reconciliation jobs that almost always work, except the mornings they don't. A list of "things to check after the Dynamics update" that someone has to remember.

This is the plumbing layer that exists only because the systems disagree about the shape of the business. Pull the plumbing out and the systems can't pretend to be one anymore.

Shadow systems

The vendor data lived in email. Lead times lived in Excel. Tribal knowledge lived in Slack threads and the heads of the senior buyers. The official inventory system showed one number; the actual inventory was what Linda wrote in the spreadsheet that morning.

Shadow systems exist because the real shape of the work isn't in the official systems. The operators know it. The official systems are, in a sense, the marketing version of how the company runs. The shadow systems are the documentary version.

Decision latency (two flavors)

The first flavor is the IT-ticket kind. The team wants to add a new field to track which customer requested which color trim. In Salesforce, that's a custom field plus a Dynamics integration update plus a NetSuite mapping change. Three teams, three queues. Six to eight weeks.

The second flavor is the human-relay kind. Joe to Tom to Linda to the vendor and back. Each hop adds a day, a missed Slack message, a forgotten followup. The vehicle that was supposed to ship March 15 ships May 3 because four humans had to relay seven facts to each other across four systems, and one of the facts dropped.

Both are decision latency. Both cost real money. Neither shows up on the SaaS invoice.

Customization decay

The company's Salesforce instance had been customized for nine years. Their last major upgrade was a seven-month project. They postponed the next one. The Dynamics integration had a quirk nobody could explain because the engineer who wrote it had left in 2021. NetSuite changed an API and three integrations broke before anyone noticed.

This is the deepest part of the iceberg. Every customization is a debt that comes due at upgrade time. Eventually the debt is large enough that you stop upgrading. Then you're stuck on the vendor's old version, watching the rest of the world get features you can't have.

Why this happens (the short version)

Enterprise SaaS was designed for the median enterprise. The median was real enough in 2005, in the categories where it lived (sales operations, financial close, payroll, expense reports). It still is for those categories.

It is not real for high-impact, high-complexity, regulated, or operationally specific industries. A custom vehicle manufacturer's data model is not Salesforce's idea of a customer or Dynamics's idea of an item. A defense contractor's classification scheme is not anybody's idea of a column. Trying to make either work means bending the vendor's model and bending it forever, hiring people to do the bending, hiring more people to do the gluing between the bent vendors, and accepting that the humans on the floor will run the business through email because the official systems can't.

The hidden cost is the price of that mismatch, paid over and over, in headcount, in integration spend, in upgrade postponements, and in vehicles that ship six weeks late.

The wrong way to fix it

Don't do a big-bang migration. Don't try to replace Salesforce and Dynamics and NetSuite and the vendor portal in one go and switch everyone to a new system on a Monday morning. We've seen this attempted. We've also seen it fail. The org can't absorb that much change at once. The data migration alone takes nine months and the systems all keep running in parallel because nobody trusts the new one yet, and now you have five systems instead of four.

The migration that works is the slow one. Trickle-down, slice by slice. Replace one critical piece. Let it live alongside the legacy systems for a cycle. Prove it works. Make it the source of truth for that domain. Demote the legacy piece. Move to the next slice. Repeat.

For our automotive customer, we didn't move it all to Foundry in one shot. We're moving it slowly. One ontology slice at a time. Source systems get demoted to read-only as Foundry takes over for that domain. Eventually some of the source systems get fully retired, and the ones that handle commodity work (payroll, email, expense) keep running. Foundry becomes the single source of truth for the parts of the business that actually matter.

A five-step framework you can run yourself

This is the abbreviated version. The full version is in the cheatsheet linked below.

Step 1: Map your operational graph as it actually exists

Forget which system holds what today. Draw the actual flow of work in your business. What are the nouns (objects)? Customer, Vehicle, Part, Vendor, Purchase Order, Production Batch, Floorplan. What links them? A Vehicle has many Parts. A Part has one or many Vendors. A Production Batch contains many Vehicles. What actions change them? Order a part. Schedule a vehicle. Approve a vendor invoice.

Do this on a whiteboard. Two hours. The point is to see the shape of your business, undistorted by any vendor's data model.

Step 2: Find the most painful handoff

The handoff is where the work waits on a human relay. Joe-to-Tom-to-Linda. Sales-to-production. Production-to-purchasing. Compliance-to-trading. Whatever your version is.

Rank the handoffs by pain. Time lost. Customer impact. Revenue at risk. Pick the worst one. That's your candidate first slice.

Step 3: Model that slice in Foundry, alongside the legacy systems

Build the ontology objects, links, and actions for that one slice. Mirror data from the legacy systems into it. The legacy systems keep running. Nobody panics. The ontology slice is, for now, a read-only view of the truth as it could be.

One six-week cycle. End of the cycle, the slice is live and an operator team is using it for the painful handoff that started this whole conversation.

Step 4: Promote the ontology to source of truth for that slice

When the slice is proven (a few weeks of parallel running, no missed cases, audit trail intact), switch which one's authoritative. The legacy systems become read-only for that domain. Eventually they're deprecated for that domain. The integrations that used to feed them go away. The team that maintained those integrations gets reassigned to the next slice.

Step 5: Move to the next slice

Pick the next-most-painful handoff. Repeat. Each cycle compresses more of the operational graph into one place. The integration tax shrinks. The shadow systems retire. The Joes and Toms and Lindas stop being the integration layer and go back to doing the work they were hired for.

The whole transformation, slice by slice, takes one to four cycles per slice depending on complexity, and four to twelve total cycles for a real high-impact business. Six months to two years, depending on scope. Not nine months of a doomed big-bang.

What happens to the legacy systems

Some die. The ones that owned strategic data (the bent Salesforce, the bent Dynamics) get retired domain by domain until there's nothing left to retire. The license stops getting renewed. The platform-specific dev team gets redirected to higher-leverage work or, honestly, sized down.

Some live. The commodity ones. Payroll keeps running on whatever payroll system you've got. Email stays. Expense reports stay. Calendar stays. IT ticketing stays. The whole point of this approach is that you only retire the systems where your competitive advantage was being held back by them. Everything else is fine where it is.

The end state isn't "Foundry replaces everything." The end state is "Foundry is the source of truth for the operations that matter, and the commodity stuff stays commodity."

The cheatsheet

We packaged the five steps into a one-page cheatsheet with questions to answer at each step, a worksheet to draft your operational graph on, and a decision rubric for which slice to migrate first. It's built to be filled out by a small cross-functional team in a two-hour working session.

Download The Stack Migration Cheatsheet.

When you've filled it out, you can email it to us at ontology@akos.ai and we'll give you a real read based on the operational graphs we've built across manufacturing, defense, healthcare finance, energy, and government. No sales call required. We're more useful when we can see your actual shape.

What am I missing?

If you've shipped a big-bang SaaS-to-ontology migration and it worked, tell me. I want to know how. If you've tried trickle-down and it stalled, tell me where it stalled. The shapes we see rhyme more than they're identical, and we learn faster from the cases that don't fit our default playbook than from the ones that do.

If you've got a stack that looks like four logos and an army of platform-specific developers and a quiet feeling that the humans are doing too much of the work the software was supposed to do, that's the feeling this piece was written for. Pick the worst handoff. Spend an afternoon on the cheatsheet. Try the first slice. Six weeks gets you a real answer.

Talk to us if you want a working session on which slice to migrate first. The first conversation is free and the second one usually is too.