Open the budget for a mature Oracle or SQL Server estate and the same pattern recurs: the proprietary database licence, plus its annual support and maintenance, is frequently the single largest line item, larger than the servers it runs on and, over a few years, larger than the people who run it. It compounds quietly. Cores get added, editions creep upward, true-ups arrive, and support renews at a percentage of a list price nobody renegotiated.
A migration to AWS is the one moment that cost becomes addressable rather than inevitable. Lifting and shifting a licensed database to a virtual machine in the cloud changes where it runs and almost nothing about what it costs. To capture the dividend you have to be deliberate about the licence, and there are exactly two levers. You can optimise the licence you keep, or you can escape the engine entirely. They are not mutually exclusive, and most estates use both across different workloads.
The premise: licence is the line item, migration is the moment
Commercial database engines license per core. That single fact drives most of the cost and most of the savings. Every core you run, whether the workload needs it or not, is a core you license, and on Enterprise editions the per-core figure is significant. On-premises, that number is largely fixed by the hardware you bought and the agreement you signed. In the cloud, the core count becomes a dial you can turn, the edition becomes a choice you can revisit, and the engine itself becomes optional. The migration is what unlocks all three. Skip the licensing question during the move and you have paid the cost of change without collecting the return.
Lever 1: optimise the licence you keep
Sometimes the right answer is to stay on the commercial engine, for a packaged application that only supports it, a feature with no equivalent, or simply a timeline that does not allow an engine change yet. You can still cut the cost materially. Three mechanisms do most of the work.
License-Included: stop buying licences outright
License-Included applies chiefly to SQL Server. You run SQL Server on Amazon RDS or Amazon EC2 and the Microsoft licence is bundled into the hourly rate. There is no upfront purchase, no separate licence agreement to manage, and you can scale the instance up or down, or switch it off, without a true-up conversation. For workloads that are variable, seasonal, or simply uncertain in their long-run size, paying for the licence by the hour alongside the compute is often both cheaper and far simpler than owning a perpetual entitlement you have to keep fully utilised to justify.
BYOL: bring the licences you already own
Bring Your Own Licence (BYOL) is the route for Oracle, and for SQL Server estates with existing agreements worth preserving. You bring your current entitlements to AWS, typically running on EC2, or on RDS Custom where you need operating-system and database-level access. The saving here is avoidance: you are not re-buying what you already paid for. The trap is eligibility. BYOL depends on your specific agreement and on licence mobility rights, and the rules for counting cores on virtualised infrastructure can be intricate. Confirm what your contract actually permits before you architect around it, rather than after.
Right-sizing: stop licensing cores and editions you don't use
This is where the unglamorous money lives. Because commercial engines license per core, every idle core is pure waste, and on-premises estates are routinely provisioned for a peak that arrives twice a year. Migrating is the chance to size the instance to the real workload and license only the cores you genuinely need. Be deliberate about vCPU and core counts: the commercial cost moves in lockstep with them.
The larger lever is often edition. A great deal of software runs on Enterprise edition out of habit rather than need. Where the actual feature set in use is covered by Standard edition, moving Enterprise to Standard can be one of the biggest single savings available, because the per-core gap between the two is wide. It demands honest homework: audit which Enterprise-only features the workload truly depends on before you assume you can drop down. But when the workload fits, the saving is structural and recurring.
| Lever | Mechanism | What it saves |
|---|---|---|
| License-Included | SQL Server on RDS / EC2, licence in the hourly rate | Upfront purchase and true-up risk on variable workloads |
| BYOL | Existing Oracle / SQL Server licences on EC2 or RDS Custom | Re-buying entitlements you already own |
| Right-size cores | Match vCPU/core count to the real workload | Per-core licensing on idle, over-provisioned capacity |
| Right-size edition | Enterprise to Standard where the feature set allows | The wide per-core gap between editions |
| Escape the engine | Move to Aurora PostgreSQL / MySQL | The per-core licence in full: it goes to zero |
Lever 2: escape the engine
The second lever is the larger dividend, and it is conceptually simple. Move the workload off SQL Server or Oracle and onto an open-source engine, Amazon Aurora PostgreSQL or Aurora MySQL. Open-source engines carry no per-core licence. The line item that dominated the budget does not shrink; it disappears. For a licence-heavy estate, nothing else on the table compares.
The cost on the other side of that trade is effort, not licensing. Changing the engine is a heterogeneous migration, which means the schema, the procedural code, and sometimes the application have to be translated to a new dialect. The AWS Schema Conversion Tool automates the structural majority of that work; the procedural logic, stored procedures, functions, triggers and packages, is the part that needs real engineering. We covered exactly what that tool does and what it leaves for you in an earlier post in this series, on heterogeneous migration with AWS SCT, and it is the right place to size the work honestly.
If the source is SQL Server, Babelfish for Aurora PostgreSQL changes the arithmetic again. Babelfish gives Aurora a T-SQL-compatible endpoint, so much of the application can keep talking to the database as though it were still SQL Server. That collapses a large slice of the application-rewrite effort, which is usually the most expensive and risky part of an engine change. It is not total coverage, so it has to be assessed, but where it fits it makes escaping the engine far more attractive.
Graviton on top
Once a workload is on an open-source engine, there is a further, compounding saving available in the hardware underneath it. AWS Graviton processors are ARM-based and typically deliver better price for performance than comparable x86 instances, and they are well supported across RDS and Aurora for PostgreSQL and MySQL. Because there is no per-core licence in play any more, you are free to choose the instance family purely on price and performance. The sensible sequence is to migrate first, observe the real workload on the new engine, then right-size onto Graviton, rather than guessing the target shape in advance. It is a smaller dividend than escaping the licence, but it stacks neatly on top of it.
Use the AWS programs to de-risk and fund the move
You do not have to make the commercial case on guesswork, and you do not have to fund the migration entirely yourself. Two AWS programs exist precisely for this.
The Optimization and Licensing Assessment (OLA) is an AWS-run review of your current licensing position against an optimal AWS footprint. It looks at your actual utilisation, editions, and entitlements and models what the estate should cost done well, separating the BYOL, License-Included, and engine-change options with your own numbers rather than illustrative ones. It is the antidote to assuming, and it is the document that turns “we think there is a saving” into a defensible plan.
The Migration Acceleration Program (MAP) addresses the other half: the cost of moving. MAP provides structured methodology and, for qualifying workloads, funding and credits that offset migration expense. Together the two programs de-risk the decision, OLA proves the destination is cheaper, MAP helps pay for the journey there.
Model it honestly
The comparison that matters is total cost of ownership before and after, over a realistic horizon. The shape of it is consistent even though the figures are workload-specific.
Before: the licence, plus annual support and maintenance on that licence, plus the underlying infrastructure. After: compute, plus storage, and on the engine-escape path no licence at all, plus the one-off cost of the migration itself. The recurring side of the ledger is where the dividend shows up; the migration is a single entry that amortises away.
For licence-heavy estates, payback frequently lands inside a year, because the annual support cost alone, the percentage you pay every year just to keep the entitlement current, can rival the cost of the move. But that is a tendency, not a promise. A workload that is light on licence and heavy on engineering complexity behaves differently. Any number you see at this stage, including any you might model yourself, is illustrative until an OLA grounds it in your real position. Treat early figures as direction, not commitment.
The caveat that governs all of it
Everything above is a map of where the savings tend to be, not a quote. Licensing is contract-specific, the rules change, and the details have teeth. BYOL mobility rights are not universal. Core-factor and core-counting rules on virtualised infrastructure can move the maths in either direction. The line between editions is about the specific features your workload uses, not a general rule. None of this is a reason to leave the dividend uncollected; it is the reason to get it assessed rather than estimated. Run an OLA, validate the entitlements against the actual agreement, and let the structure follow the contract instead of the other way round.
The headline holds regardless: for a licence-heavy estate, the database migration to AWS is the moment to turn the largest line item into the largest saving. Optimise the licence you keep, or escape the engine and remove it. Do the move without doing the licensing, and you will have changed where the cost sits without changing how big it is.
This is the commercial case inside a larger method
Cutting licence cost is one outcome of a database migration done well. The target engine, the data-movement approach, the security and data-residency controls, and the funding programs all sit in the same method. The full picture is in our guide.
Read: The IT leader’s guide to database migration on AWS
