Samsung serves 1.1 billion users. 80,000 database requests. Every second. And they left Oracle.
Not a startup. Not a scrappy fintech.
Samsung Electronics. One of the most infrastructure-conservative companies on the planet. They migrated three regions — EU, China, US — off an on-premises Oracle database and onto Amazon Aurora PostgreSQL
The outcome?
44% reduction in monthly operational costs.
Zero Oracle licensing fees.
Zero 22%-per-year maintenance contracts.
And 15 Aurora replicas scaling on demand — no per-core Oracle math required.
Source: AWS official case study.
I’ve been watching this pattern for months now.
Samsung. LATAM Airlines. Industrial Bank of Korea. Goldman Sachs. DNS Belgium.
They don’t make announcements.
They just quietly do the math — and leave.
The thing Oracle won’t publish is what the math actually looks like once you run it honestly:
Licensing. Maintenance. Audit risk. Lock-in premium. Talent cost.
Enterprise IT teams have been trained to see switching costs as a reason to stay.
The ones leaving are starting to see them as the cost of staying.
What’s keeping your Oracle environment in place right now — contractual necessity, or momentum?
Oracle Forms Premier Support ends December 2029. That’s 1,277 days from today. Most enterprises
need 18 to 36 months to complete a Forms modernization. 36 months from today is July 2029. You’re already inside the window.
The enterprises that finish on time start the assessment conversation now. Not when the support notice arrives.
Not after the next upgrade cycle. Now. One question: has your team run a scope analysis on your Forms codebase yet?
Most Oracle Forms modernization decisions are made under pressure, not strategy.
A browser breaks. A key developer retires. A licensing audit appears.
Suddenly, organizations are forced to “modernize” systems that have quietly powered the business for decades.
The problem is rarely Oracle Forms itself.
The real risk is choosing a path without understanding application complexity, business pressure, and long-term architectural consequences.
Upgrade, extend, or migrate are not competing opinions.
They are three legitimate paths, each valid in the right context.
In this article, I share a fact-based framework to help executives and architects decide when each option makes sense, including a practical self-assessment to remove guesswork from modernization decisions.
Modernization done right is not about replacing legacy.
It is about turning what already works into a sustainable competitive advantage
Application modernization is often treated as a technical exercise: migrate workloads to the cloud, replace legacy platforms, introduce APIs, or rebuild selected applications using modern architectures.
Modernization decisions affect operating cost, business agility, resilience, security, workforce requirements, vendor dependency, and the organization’s ability to adopt AI. They also determine whether a company simplifies its technology landscape or merely transfers existing complexity into a more expensive environment.
The most important modernization question is therefore not:
How should we modernize this application?
It is:
Should this application still exist, and if so, what role should it play in the future business architecture?
This is why successful application modernization begins with application rationalization, applies Lean principles throughout the transformation, and makes explicit choices between Greenfield and Brownfield approaches as well as Make, Buy, and increasingly Compose.
Modernization without rationalization preserves the wrong things
Many organizations begin modernization programs by assessing technical obsolescence. They analyze programming languages, infrastructure age, support contracts, cloud compatibility, security vulnerabilities, and the availability of technical skills.
These are important factors, but they are not sufficient.
An application can be technically outdated and still highly valuable. Another application can run on modern technology while duplicating capabilities that already exist elsewhere. A third may be stable, inexpensive, and operationally adequate, but no longer support a relevant business process.
Modernization therefore requires a broader portfolio perspective.
Application rationalization should assess each application across several dimensions:
Business criticality and strategic relevance
Functional uniqueness and process fit
Total cost of ownership
Technical health and maintainability
Security, compliance, and operational risk
Data value and integration dependencies
User experience and business satisfaction
Future change demand
Vendor viability and market alternatives
Contribution to business differentiation
The purpose is not simply to score applications. It is to make deliberate portfolio decisions.