If you run Oracle or SQL Server at any real scale, two dates are probably on your calendar already. One is the next license renewal or true-up. The other is a support deadline, since SQL Server 2016 left extended support on July 14, 2026, SQL Server 2017 follows on October 12, 2027, and Oracle Database 19c Premier Support ends in December 2029. Audit teams tend to start asking about unsupported versions well before those dates arrive.
We've been building on AWS since 2008, and in that time we've seen plenty of database programs get scoped, staffed, and diagrammed, then stall somewhere between the assessment and the cutover while the license bill is renewed on schedule. This guide is for the CIO, CTO, or CFO who has already decided the database layer has to move and now needs to decide how, at what cost, on what date, and with whom.
Mostly a set of choices rather than a single move. There are four paths, each with a different license outcome, effort profile, and risk posture, and most estates end up using two or three of them at once, which is why a single "lift and shift" estimate rarely survives contact with the code.
Take a typical estate at a mid-size insurer. The policy administration system runs on Oracle 19c Enterprise Edition with a few hundred PL/SQL packages, some of which calculate premiums. Claims reporting sits on SQL Server 2016, fed by SSIS jobs and a couple of linked servers that nobody has documented since the original DBA left. Those two systems almost never belong on the same path.
For that insurer, we'd probably refactor the policy system to Aurora PostgreSQL and put claims reporting on Babelfish first, because the reporting team can't rewrite hundreds of T-SQL procedures before the SQL Server renewal. Rehost isn't a failure either. A rehost that buys you twelve months of runway, while the refactor ships on a committed date, beats a refactor that drifts for two years, since the goal is retired legacy on a date and not architectural purity.
Because the renewal date, not the architecture review, sets your real deadline. Most of a migration plan can move around, but the invoice arrives when the contract says it will, which is why we scope our application and database modernization work against the renewal calendar first.
The licensing math on AWS cuts against staying put. Oracle's cloud licensing policy tells customers to "count two vCPUs as equivalent to one Oracle Processor license if multi-threading of processor cores is enabled," so every right-sizing decision you make on AWS still runs through Oracle's meter. On the Microsoft side, licenses bought without Software Assurance and mobility rights after October 1, 2019, can't be deployed on dedicated hosts at Listed Providers, and Amazon is one of them.
Then there's the support clock:
We'd work backward from the nearest of those dates. If a credible program needs a scoping phase, a build, a parallel run, and a rehearsed cutover, it doesn't take long to see whether you're early, on time, or already negotiating from a weak position.
This is also where the CFO conversation changes. We'd argue that a good part of the AI budget most enterprises think they need is already sitting inside existing IT spend, in the database renewal that comes up every year.
Synaptics is a good example. Its Oracle database was, as our case study puts it, "one of those systems everyone agreed should be modernized," but the engineering team was always needed elsewhere. We shipped the Oracle migration to Amazon RDS on a fixed date, and "the license renewal that was inevitable became the budget that funded the next initiative." That's the pattern worth copying, where the exit pays for whatever comes after it.
Pick the target by workload behavior rather than team preference, so the engine follows the code. For an Oracle to Aurora PostgreSQL migration, PostgreSQL is the usual landing zone because PL/SQL concepts map most closely to PL/pgSQL. Aurora MySQL fits simpler, read-heavy web schemas. For SQL Server, the real fork is whether you convert T-SQL or run it through Babelfish.
Babelfish lets Aurora PostgreSQL understand T-SQL and the SQL Server TDS wire protocol, so client applications can connect to it much as they would to SQL Server. The open-source Babelfish Compass tool reads your T-SQL and reports how much of it is supported before you sign anything. We'd run Compass early on any SQL Server to PostgreSQL migration, because a 90% compatibility score is a lot less comforting once you learn the other 10% is the claims reserve calculation.
This is a heterogeneous database migration, so the tooling matters. AWS Database Migration Service (DMS) handles the full load and the change data capture that keeps the target in sync. DMS Schema Conversion and the AWS Schema Conversion Tool convert schema and code, and since December 2024 DMS Schema Conversion has offered generative AI-assisted conversion for PostgreSQL targets, now covering Oracle, SQL Server, SAP ASE, and Db2 sources.
What none of these tools decide is which logic should stay in the database at all. In the insurer's case, whether the premium rules belong in PL/pgSQL or in an application service is an engineering judgment, and that's where most of the risk lives.
We'd sort every database object into three buckets before anyone quotes a timeline, because it's the quickest way to tell a twelve-week program from a twelve-month one.
If nobody can tell you how many objects sit in the red bucket, what you're holding is a guess, however polished the proposal looks. For the insurer, the forty or so packages that calculate premiums and run the month-end close would go straight into red, and they'd decide the date long before data volume did.
There's no honest single number, and anyone who gives you one before seeing your schema is guessing. What we can give you is the cost structure, so you can pressure-test any proposal against your own renewal quote.
Two levers matter more than people expect. The first is Aurora I/O-Optimized, and AWS says that "if your I/O spend exceeds 25% of your total Aurora database spend," switching can save up to 40%, so we'd check the I/O pattern during design instead of after the first bill. The second is the AWS Migration Acceleration Program (MAP), which pairs a migration methodology with AWS financial investment to "offset initial migration costs" for eligible programs. We'd raise MAP eligibility in the first scoping call, since it can change how the whole business case reads.
Flexera's 2026 State of the Cloud Report adds a useful caution here. Wasted cloud spend rose to 29%, the first increase in five years, which suggests that moving a workload and moving it efficiently are two different results. That's why we'd make right-sizing part of the design gate.
For a scoped workload, weeks rather than quarters, as long as discovery doesn't eat the calendar. Across Mactores engagements, our median time to production is 12 weeks. What stretches a timeline is rarely data volume. It's usually what nobody knew about the dependencies.
The same Flexera survey of 753 cloud decision-makers backs this up, with understanding application dependencies named the top migration challenge by 54% of respondents. In the insurer's case, that might be an SSIS job that feeds the actuarial team every Monday, or a linked server a regulatory report reads from, and each one found in week ten moves the date.
The structure moves risk discovery to the front. As our delivery method puts it, "automation carries the repetitive bulk of the engagement, forward-deployed engineers carry every judgment call, and the ship date is written into the statement of work before build begins." Gate two is the one a CFO should watch most closely, because that's where the date and the fee stop moving.
Treat compliance evidence as a deliverable of the migration, not a review after it. When auditors have to piece together what happened over the cutover weekend from chat logs and screenshots, the review tends to drag on for months.
The stakes are real. IBM's 2026 Cost of a Data Breach report puts the global average at a record USD 4.99 million, up 12% on the year before, and the US average at USD 11.5 million. A database migration is when sensitive data is most in motion, so it's also when your controls get tested hardest.
A few specifics are worth knowing. Both editions of Aurora are HIPAA-eligible, and Aurora MySQL and Aurora PostgreSQL are in scope for FedRAMP at the Moderate and High baselines, which AWS now labels Class C and Class D. The 51 future-dated PCI DSS v4.x requirements became mandatory on March 31, 2025. In Europe, DORA has applied since January 17, 2025 and the EU Data Act since September 12, 2025, and the AWS European Sovereign Cloud, generally available since January 2026 with its first Region in Brandenburg, Germany, gives regulated workloads a sovereignty option inside the EU. Gartner expects 80% of sovereign cloud IaaS spending to come from "net new digital solutions or legacy workloads waiting to be migrated to a cloud environment," and forecasts Europe to pass North America in that spending in 2027.
We treat compliance as a foundation rather than a tax. Lineage, access control, and audit evidence get built into the platform, so every new analytical capability inherits them instead of triggering a fresh review. Our financial services data modernization work follows that principle, and so does our healthcare data platform approach for HIPAA workloads.
Usually on sequencing rather than technology. The budget goes to discovery, the cutover gets underfunded, and the program either stalls or ships something the auditor won't sign.
We saw this pattern firsthand with a branded-payments leader whose two earlier modernization attempts had stalled before cutover. Our case study sums up the trap: "Discovery eats the budget; cutover gets de-funded; the program stalls or ships at a quality the regulator does not approve." On the third attempt, agents took on code analysis, dependency mapping, and test generation, which left engineers free for risk-weighted cutover sequencing, and the PCI DSS-aligned payments platform went live with no audit incident during cutover.
For a near-zero-downtime Oracle to Aurora migration, the playbook is well understood. You run a full load, then continuous CDC replication, then a parallel run long enough to cover month-end or peak behavior, and finally a short, rehearsed switchover. For the insurer, that means the parallel run has to include at least one month-end close, because that's when the premium packages do their heaviest work.
After cutover, Aurora Global Database adds cross-Region recovery, and AWS says a secondary Region "can be promoted to read and write capabilities in less than 1 minute." Zero-ETL integration with Amazon Redshift, available for both Aurora MySQL and Aurora PostgreSQL, lets analytics move with you instead of lagging behind. If the warehouse is next in line, the same gates apply to data warehouse modernization.
We'd ask questions that force a commitment, because the commercial model says more about delivery risk than any capabilities deck or case study slide.
Use these questions in your RFP or first call:
If a partner hedges on questions two and five, that tells you most of what you need to know about who will carry the risk. You can see how we answer both on our delivery commitment page, which also reports that 94% of our engagements were delivered on or ahead of date.
You don't need a perfect inventory, just enough to size the red bucket and find the real deadline. Bring what you have:
With that list, a good partner should be able to tell you within the first phase which path each workload takes, where the critical path runs, and whether your renewal date is realistic. If you'd like that read from us, book 30 minutes with the engineer who'd own the work and bring the renewal quote.