My first job in IT, 1996/1997, was at ITS, a Tertiary Education Software company. Still my best time in IT. It was the time when CHUI went to GUI, literally. Oracle Forms 3 was replaced by Forms 4.5 — we skipped 4 — but all our reports and menus were in Pro*C. We did not use Oracle Reports.
So for the conversion of Forms, Oracle provided something. But for the reports and menus, we had a guy called "Hippy". Hippy was the guy you went to when you tried Mukesh and you tried Ina. He was sitting and thinking in his office, you walked in there with respect. You were taking up time from the guy playing with the core. It was Hippy. But he had time for you.
He wrote the software to convert the C reports to Oracle Reports. It took him months — at least 3, to be honest. I don't have the exact details for that.
This will take Claude minutes today. No joke.
You can let Claude loose on any expensive SaaS product today and you can cut your seats to fractions of what you think you need. Don't save money by reducing your workforce. Save money by reducing expensive SaaS deployments. This will happen now.
I am not in principle talking about agents and LLMs installed in your domain. I don't think we are there, or even that we will get there. Leave that to automation and bots. I am talking about re-designing, re-developing your complete system from scratch.
(Waiting for the laughter to die down.)
But the keys are these:
- You need to believe that AI can do it. It needs conviction and commitment. When you've been working with the same software and code for 10 years, you know it. Now you will be venturing into something different. Completely different. Without that belief, without your job relying on it, you will probably quit. Because you might still doubt that this is even the future, you will start and when it gets tough you will doubt, and you will quit. If that is the case, don't start. Do what you like until... not.
- Your devs will need to leave their egos at the door.
- If you treat AI dev as simply an extension to how you currently work, you will fail. The shift is real, and it is huge, and different. You don't just start and it works. You fail until it works.
- There is a ramp-up, and a real expertise to be learnt on a very intense curve. You won't skip that. But now you can buy that expertise. It is starting to pay off for those who dug in.
- Don't half-ass it. Full-ass it, or view from the sidelines how others build the future.
The rest is me giving AI my ideas and it rewrote it in decent English. How I see what happens next.
Every enterprise is paying a tax they don't need to pay anymore.
Oracle seats. SAP licenses. Salesforce contracts that renew before you've even figured out what half the modules do. These aren't technology decisions anymore — they're hostage situations. And the ransom keeps going up.
The lock-in was never really about the technology. It was about the risk. Nobody wanted to be the CTO who blew up the production database trying to migrate off Oracle. Nobody had the time, the team, or the confidence to untangle decades of stored procedures, triggers, and dependencies that nobody fully understood.
That equation has changed. Dramatically.
Kill the Licensing Cost
Postgres and MySQL aren't new. They've been enterprise-ready for years. What's new is that the migration path — the part that used to take 18 months and a team of 12 — can now be done in a fraction of the time.
Schema translation. Query rewriting. Data type mapping. Stored procedure conversion. These used to be the hard, expensive, human-intensive parts. Now they're solvable problems. Not trivially — but solvable in weeks, not years.
The performance gap? Gone. Postgres handles workloads today that would have required Oracle RAC a decade ago. And you're not paying per-CPU licensing to do it.
If your Oracle bill is seven figures, you should be running a proof of concept on Postgres right now. Not next quarter. Now.
Break the Monolith Database Into Modules
This is where most people get stuck. You've got one massive database serving 47 different business functions. Patient records sitting next to billing sitting next to inventory sitting next to reporting. All tangled together with foreign keys, views, and procedures that nobody wants to touch.
The old approach was to leave it alone because the dependency graph was unknowable. You'd pull one thread and the whole thing would unravel.
The new approach: map every dependency. Every table relationship. Every procedure call chain. Every view that joins across domains. Build the complete picture first, then draw the boundaries.
Once you can see the map, the decisions become obvious:
- What needs speed? Transaction processing, real-time lookups — those stay close to the application, optimised for performance.
- What needs connectivity? Shared reference data, cross-module lookups — cloud-hosted, accessible everywhere.
- What stays local? Sensitive data, compliance-heavy records — kept where governance requires it.
- What can be eventually consistent? Reporting, analytics, audit logs — these don't need real-time sync and can live in cheaper, slower storage.
You're not doing this in one big bang. You're extracting one domain at a time. Billing first, maybe. Or inventory. Pick the one with the clearest boundaries and prove the pattern works.
Rip Out the Frontend — But Use It as a Spec
Here's the move most people miss.
That bloated frontend — the one with 200 React components, 47 modal dialogs, and a design system that three different teams interpreted three different ways — it's not waste. It's documentation.
Every screen, every form, every validation rule, every edge case that some developer handled five years ago and nobody remembers why — it's all encoded in that frontend. It's the most complete specification of what the business actually needs, written in code instead of documents.
Don't try to refactor it. Don't try to modernise it incrementally. Use it as the brief.
Walk every screen. Document every workflow. Capture every business rule. Then build the new frontend from that spec — clean, modern, purpose-built. You'll end up with something that does what the business actually needs in half the code, because you're not carrying the weight of six years of feature creep and abandoned experiments.
The old frontend did the hard work of figuring out what the business requires. Let the new one do the easy work of implementing it cleanly.
The Bigger Picture
What I'm describing isn't a technology project. It's an unbundling.
Big SaaS sold you a bundle: database, application logic, frontend, hosting, support — all wrapped in one contract with one vendor. That bundle made sense when the integration cost was high and the alternatives were immature.
The integration cost just dropped through the floor. The alternatives aren't immature anymore.
You can run Postgres for a fraction of Oracle's cost. You can decompose your data layer into purpose-built modules. You can rebuild your frontend in weeks instead of months. And you can stitch it all together with lightweight services that do exactly what you need — nothing more, nothing less.
The companies that move on this now won't just save money. They'll move faster than their competitors who are still waiting for their SAP consultant to return their call.
The unbundling of Big SaaS isn't coming. It's here. The only question is whether you're the one doing the ripping, or the one getting ripped apart.
← Back to Blog