Moving SQL Server to AWS is not one decision — it is three. You can lift-and-shift to Amazon RDS for SQL Server (managed, fast, BYOL or license-included), re-platform to Aurora PostgreSQL with Babelfish to keep your T-SQL apps running while the SQL Server license disappears, or run SQL Server on EC2 for full instance control and Always On. The Windows/SQL Optimization & Licensing Assessment (OLA) tells you — with data — which path each workload belongs in and what it saves. This page walks the SCT + DMS workflow honestly, the Babelfish coverage gaps, Always On / HA on each option, the cutover, and how AWS MAP and OLA funding cover most of the cost.
SQL Server is a strong database; performance is rarely the reason teams leave. The reasons are the cost structure (per-core licensing plus Software Assurance), the Windows tax that often rides alongside it, and the operational burden of patching, HA, and DR on your own metal.
SQL Server is licensed per physical core, in two-core packs, with a four-core minimum per instance. Enterprise Edition lists around $15,000+ per two-core pack and Standard around $3,900, and on top of the license most enterprises carry Software Assurance for upgrade rights and License Mobility. The features teams quietly depend on — Always On Availability Groups, Transparent Data Encryption, online index rebuilds, partitioning, advanced compression — are Enterprise-only, pushing the per-core bill toward the high end precisely where the workload matters most. Run it on your own hardware and you add the server refresh cycle, the Windows Server licenses underneath, DBA headcount, and a passive DR replica that may itself need licensing.
AWS changes the structure along three axes — which is why the SQL Server-to-AWS decision is really three decisions. First, keep SQL Server but stop running the metal: Amazon RDS for SQL Server gives you managed SQL Server on infrastructure you rent by the hour, BYOL or license-included. Second, keep full control of the instance on Amazon EC2 when RDS’s managed boundaries are too tight — any edition, any configuration, full Always On. Third — the path that actually moves the license needle — re-platform to Aurora PostgreSQL with Babelfish, and the SQL Server license disappears entirely while your T-SQL applications keep talking to the database over the same wire protocol.
There is a fourth force specific to SQL Server that does not exist for, say, Oracle: the Windows operating system underneath. A large share of SQL Server estates run on Windows Server, and moving to Linux-based Aurora PostgreSQL or Linux SQL Server on EC2 can shed Windows Server licensing too. AWS has a dedicated funding mechanism — the Optimization & Licensing Assessment (OLA) — built around exactly this Windows-and-SQL right-sizing question (Section VI). Knowing which workload deserves which of the three paths, with the OLA data in hand, is the entire game.
In the language of the AWS 7 Rs, lift-and-shift to RDS or EC2 is Rehost/Relocate (homogeneous — same engine), and moving to Aurora PostgreSQL with Babelfish is Replatform/Refactor (heterogeneous — different engine, compatibility layer in front). The effort, the risk, and the payoff differ by an order of magnitude across the three.
Be deliberate about which database goes which way, per workload, not per company. The instinct to "just move everything to Babelfish and delete the license bill" runs into databases that lean on Agent jobs, SSIS, CLR, or T-SQL Babelfish does not yet cover — where conversion costs more than the license it saves. Conversely, defaulting everything to RDS because it is easy means you carry the SQL Server (and Windows) bill into AWS and never capture the prize. The OLA assessment in Section VI turns this from instinct into a costed, per-database decision.
What it is: the same SQL Server engine, managed by AWS — automated patching, backups, point-in-time restore, and synchronous Multi-AZ failover. Pick an instance class, attach storage, choose an edition (Express through Enterprise), and you have managed SQL Server in hours.
How you migrate: homogeneous SQL Server→SQL Server is straightforward — native backup/restore via .bak files in S3, or AWS DMS for low-downtime cutovers. The engine is identical, so application code, T-SQL, and stored procedures are unchanged.
Licensing: license-included (AWS bundles the license into the hourly rate — no Software Assurance needed) or BYOL via License Mobility under active SA. You still pay for SQL Server either way; right-sizing the instance is where RDS trims the bill.
HA / DR + timeline: Multi-AZ gives a synchronous standby with automatic failover, plus Always On Availability Groups in supported configurations (the managed model limits some AG flexibility — full read-scale topologies are a signal toward EC2). Typically 2–8 weeks per database. This is the de-risking step, not always the destination.
What it is: Amazon Aurora PostgreSQL with Babelfish — a compatibility layer that speaks SQL Server’s wire protocol (TDS) and a large subset of T-SQL. Your application keeps connecting on port 1433 and issuing T-SQL; behind it sits PostgreSQL with no SQL Server license and no Software Assurance, on Aurora’s cloud-native storage (the HA model is covered in Section V).
How you migrate: start with the free Babelfish Compass tool, which reports exactly which T-SQL features are supported and which are not — your go/no-go number. For the unsupported remainder, AWS SCT converts schema and code to native PostgreSQL and AWS DMS moves the data (full load + CDC). Sections III–IV detail this workflow.
Licensing: none for the engine, and often none for the OS (PostgreSQL runs on Linux) — the line item that drives the savings, potentially eliminating the SQL Server license entirely.
The honest caveat: Babelfish covers a large, growing subset of T-SQL — but not all of it. Agent jobs, SSIS/SSRS/SSAS, CLR, linked servers, and some advanced T-SQL are not covered and must be re-architected (Compass quantifies the gap before you commit). Timeline: typically 4–9 months for a substantial application, dominated by the non-covered features and testing, not data movement.
What it is: SQL Server on an EC2 instance you fully control — any edition, any version, OS-level access, custom configuration. License-included AMIs, or BYOL onto EC2 (including Dedicated Hosts for license models that need physical-core visibility).
How you migrate: the most flexible target — native backup/restore, log shipping, AWS DMS, or AWS Application Migration Service (MGN) for a block-level lift of the whole server. Because you own the OS and instance, anything that runs on-prem runs here, including the complete Enterprise HA feature set — full Always On Availability Groups across AZs, multi-subnet failover clustering, read-scale replicas.
Licensing: license-included or BYOL under Software Assurance. You keep the SQL Server (and Windows) bill, so EC2 alone does not capture license savings — but right-sizing from the OLA still cuts cost versus over-provisioned on-prem hardware.
This is the right path when you need features RDS does not expose, full Always On topologies, OS-level agents, or a vendor support matrix that mandates a specific self-managed setup — the "RDS is too restrictive, but we are not ready to re-platform" answer.
Most successful SQL Server-to-AWS programs use all three: lift-and-shift the feature-dependent databases to RDS (or EC2 where RDS is too restrictive) to get off the metal fast, then re-platform the high-license-cost, Babelfish-tractable applications to Aurora + Babelfish to capture the savings. Sequencing the easy managed wins first frees the budget to fund the harder conversions. The OLA tells you, per database, which column it belongs in.
The Aurora + Babelfish path succeeds or stalls on one number: how much of your T-SQL Babelfish actually supports. Babelfish Compass produces that number for free, before you commit, and SCT converts the remainder. Together they are your project plan.
Babelfish Compass is a free, downloadable assessment tool. You point it at DDL and T-SQL extracted from your SQL Server databases — schema, stored procedures, functions, triggers, views — and it produces a compatibility report classifying every construct as supported, not-yet-supported, or requiring rewrite. The headline number is the percentage of your code that runs on Babelfish unchanged, and the spread is almost entirely about how SQL Server-specific your application is. A modern app using standard T-SQL, stored procedures, and ordinary data types often lands very high; an estate leaning on SQL Server Agent, SSIS packages, CLR, and linked servers lands lower and needs more re-architecture.
What Babelfish handles natively is substantial: the TDS protocol (so the app connects on 1433 with the SQL Server driver unchanged), T-SQL syntax, the SQL Server dialect of procedures and functions, common data types, and SQL Server-style semantics. That is the magic — the application layer often needs little to no change because Babelfish speaks its language. The places it cannot cover are predictable, and naming them up front keeps them from surprising you mid-project.
For everything Babelfish does not cover, AWS SCT is the conversion tool: pointed at SQL Server and Aurora PostgreSQL, it converts the remaining schema and procedural code to native PostgreSQL and assesses the manual action items by complexity. So the Babelfish path is a layered decision — keep on Babelfish what runs unchanged (most of the OLTP application), convert with SCT what Babelfish cannot run but PostgreSQL can, and re-architect outside the database the things that were never really database features (Agent scheduling, SSIS pipelines, reporting). The most valuable output of this phase is the Compass number plus the SCT action-item count: together they tell you whether this application is a quick Babelfish win or a real engineering program — and, occasionally, that it belongs on Path A (RDS for SQL Server) instead. You make that call with data, not optimism.
These are the constructs Babelfish Compass will flag, and the ones every SQL Server→Aurora migration spends its engineering hours on:
Once the target schema exists on Aurora (or on RDS / EC2 for the homogeneous paths), the Database Migration Service moves the data — and, more importantly, keeps it moving. DMS’s change-data-capture mode is what turns a terrifying weekend-long cutover into a controlled switch measured in minutes.
A DMS migration task runs in up to three modes. The full load copies existing table data from SQL Server into the target; CDC then captures every change on the live database — reading the transaction log — and applies it to the target continuously. Run "full load plus CDC" and DMS bulk-copies the data, then enters a steady state where the target trails production by seconds, with the source fully online the entire time. That replication window is the heart of low-downtime migration: you keep the target in sync for days or weeks while you validate, performance-test, and run the application against it in staging. When you are confident, the cutover is simply stopping writes to SQL Server, letting DMS drain the last few seconds, and repointing — user-visible downtime measured in minutes, and for the Babelfish path the connection-string change is minimal because the app still speaks TDS on 1433.
DMS is not magic on what cannot be expressed as row changes. CDC replicates inserts, updates, and deletes; it does not migrate procedural code (SCT and Babelfish handle that), secondary indexes are typically created after the full load for speed, and large-object (LOB) columns need explicit LOB-handling settings. For very large or high-change-rate databases you size the replication instance accordingly and parallelize across tasks — standard care a seasoned partner has done many times. Crucially, DMS includes data validation that compares source and target row-by-row after load and during CDC, reporting mismatches rather than asking you to trust the pipe — non-negotiable for a database the business runs on.
Two concerns decide whether a SQL Server migration is production-grade: your high-availability story on the new platform, and what happens if the switch goes wrong. SQL Server shops care deeply about Always On — so the HA answer is part of the path decision, not an afterthought.
High availability maps differently across the three paths, and this often drives the choice as much as licensing does. On RDS for SQL Server, Multi-AZ gives a synchronous standby with AWS-managed automatic failover, plus Always On Availability Groups in supported configurations — enterprise-grade HA without managing the cluster, at the cost of some AG flexibility (read-scale topologies are constrained by the managed model). On EC2, you build full Always On Availability Groups across Availability Zones exactly as on-prem — multi-subnet failover clustering, multiple secondary replicas, read-scale — because you own the instances; the answer when RDS’s managed HA is not enough. On Aurora + Babelfish, you inherit Aurora’s native HA instead of Always On: six-way storage replication across three AZs, failover in seconds, and up to fifteen read replicas — a different, arguably stronger model your team operates as Aurora, not SQL Server.
The cutover itself is risk management, and for a database the business runs on the plan is judged on one question: what happens if the switch goes wrong? The answer is a rehearsed runbook with a rollback path you do not have to invent under pressure. The key design choice is to leave the source SQL Server database authoritative until the cutover succeeds — because DMS CDC keeps the target in sync from SQL Server (not the reverse), rollback during the window is simply repointing the application back to SQL Server, which never stopped being correct. You only burn that bridge once you are certain.
None of this removes risk entirely — a heterogeneous migration of a system the business depends on is genuinely hard — but migrating non-critical databases first, rehearsing the cutover in staging, and keeping the rollback explicit is exactly the experience you are paying a vetted migration partner for, and exactly what AWS MAP funds them to do well.
The discipline below converts an unbounded risk into a bounded, rehearsed, reversible event:
The Windows/SQL Optimization & Licensing Assessment (OLA) is the funding mechanism most teams have never heard of, and the one that makes a SQL Server migration honest. It answers the licensing question with data — your actual core usage, your real Software Assurance position — before you commit a dollar, and AWS funds it.
An OLA is an AWS-run (partner-delivered) analysis built specifically around Windows and SQL Server workloads. It inventories your environment — physical and virtual cores, SQL Server editions, actual CPU and memory utilization, your Software Assurance and License Mobility status — and models each destination side by side: BYOL on RDS, license-included on RDS, SQL Server on EC2, and re-platforming to Aurora + Babelfish (which removes the SQL Server license entirely). Crucially, it right-sizes: most on-prem SQL Server runs on hardware provisioned for peak years ago, so you are licensing cores you do not use.
The reason the OLA matters more for SQL Server than for any other engine is the dual license (SQL Server and Windows Server) and the way per-core licensing punishes over-provisioned hardware. A workload that looks expensive to migrate often turns out to be running on 32 licensed cores while using eight; the OLA surfaces that, and the right-sized AWS target costs a fraction of the renewal you were about to sign — before any re-platform is even considered. For Babelfish-tractable applications it quantifies the full prize: SQL Server license eliminated, Windows often eliminated, hardware retired. The OLA is also the bridge into the larger funding vehicle — typically delivered within the AWS Migration Acceleration Program’s Assess phase, producing the business case that justifies MAP funding for the migration itself.
The most common OLA finding for SQL Server estates is over-licensing: hardware bought for peak, licensed per-core, running at a fraction of capacity. Right-sizing cuts the core count — and the bill — before any re-platform. Layer Babelfish on the tractable workloads and the SQL Server license can go to zero. The OLA is AWS-funded, so the analysis costs you nothing.
A funded, done-for-you SQL Server migration is the CloudRoute mechanism. You do not assemble an internal Babelfish/SCT/DMS team from scratch and absorb the cost — you get matched to a vetted AWS partner who has migrated SQL Server before, and AWS funding covers most or all of the engagement.
The vehicle is the AWS Migration Acceleration Program (MAP), run through the AWS Partner Network in three phases: Assess (the AWS-funded OLA and Babelfish Compass produce the right-sizing data, the per-database path recommendation, and the cost model), Mobilize (landing zone + pilot), and Migrate & Modernize (production migration and cutover). AWS provides credits and funding scaled to the migration’s size across these phases, and the Windows/SQL angle is exactly the kind of workload AWS prioritizes.
The honest framing matters: MAP funding applies to qualifying migrations — typically those with a meaningful committed AWS spend after migration — and the exact amount is scoped during Assess. A substantial SQL Server estate (especially one carrying Enterprise Edition and Software Assurance) easily clears the bar and can be largely or entirely AWS-funded. For smaller workloads that don’t qualify for full funding, the value is still real: a vetted partner who has done SQL Server→RDS and SQL Server→Babelfish migrations and de-risks the cutover, rather than your team learning Babelfish’s coverage gaps and SCT’s edge cases live on production.
CloudRoute’s role is the routing. You tell us the shape of the estate — how much SQL Server, which editions, your Software Assurance position, what the databases do, your timeline — and we match you to a partner with a genuine SQL Server-migration track record and the AWS tier to file MAP and run the OLA. The partner runs the assessment, scopes the funding, and executes. AWS funds the engagement; the partner is paid through MAP; CloudRoute is paid a commission by the partner. You see no invoice from us.
The funding side ties directly into the AWS credits cluster — see $100K AWS credits and how AWS POC funding works for the mechanics of partner-filed AWS funding. For the platform you land on, AWS landing zone is the secure multi-account foundation a migration should target. And the migration offer page lays out exactly what a CloudRoute-routed, MAP-funded migration includes.
This is the table the whole project turns on. RDS for SQL Server is fast, managed, and low-risk but keeps the license bill. Aurora + Babelfish is the harder re-platform that deletes SQL Server licensing while your T-SQL apps keep running. EC2 gives full control and full Always On but keeps the most license cost. Pick per database, not per company — and let the OLA decide.
| Dimension | RDS for SQL Server (lift-and-shift) | Aurora PostgreSQL + Babelfish (re-platform) | SQL Server on EC2 (full control) |
|---|---|---|---|
| Migration type | Homogeneous (same engine) | Heterogeneous (Babelfish + SCT + DMS) | Homogeneous (same engine, self-managed) |
| Application / code rewrite | None — T-SQL & app unchanged | Most T-SQL runs unchanged via Babelfish; non-covered features re-architected | None — identical to on-prem |
| SQL Server license cost | You keep it (BYOL or license-included) | Eliminated — no SQL Server license | You keep it (BYOL or license-included) |
| Windows license | Managed by RDS (folded into pricing) | Often eliminated (PostgreSQL on Linux) | You manage it (Windows or Linux SQL Server) |
| Management model | Fully managed by AWS | Fully managed (Aurora) | Self-managed (you own the OS + instance) |
| High availability | Multi-AZ; Always On AGs in supported configs | Aurora 6-way replication, 3 AZs, up to 15 replicas | Full Always On AGs, any topology |
| Typical timeline | 2–8 weeks per database | 4–9 months for a substantial app | 2–8 weeks per server |
| Engineering risk | Low — proven, mechanical | Higher — conversion + coverage gaps + cutover | Low–medium — you own all operations |
| Database TCO | Lower than on-prem; license remains | Lowest — license deleted | Lower than on-prem; license + ops remain |
| MAP / OLA funding fit | Qualifies (rehost); OLA right-sizes | Strong fit (modernization — the funded prize) | Qualifies (rehost); OLA right-sizes |
| Best for | Feature-dependent DBs; speed; minimal change | High-license-cost, Babelfish-tractable apps | Full Always On, OS access, RDS too restrictive |
Situation: Software Assurance renewal due in nine months and a hardware refresh looming on aging Windows clusters. Engineering wanted off the Windows tax; the CFO wanted the license savings; nobody on staff had run a SQL Server→PostgreSQL re-platform on databases this central. The core scheduling application was modern T-SQL and stored procedures; three databases leaned heavily on SQL Server Agent jobs and two SSIS pipelines; two databases were tied to a third-party reporting product that required SQL Server.
What CloudRoute did: Routed within 24 hours to an AWS Premier partner with a SQL Server-modernization specialization and a documented Babelfish track record. The MAP Assess phase (AWS-funded) ran an OLA across all 18 databases plus Babelfish Compass on the code. The OLA found the clusters licensed for 640 cores were using closer to 280 at peak — immediate right-sizing. Compass returned 91% T-SQL coverage on the core scheduling app and two others (Babelfish path; Agent jobs re-implemented on EventBridge + Lambda, SSIS on AWS Glue). Six feature-dependent / vendor-locked databases went to RDS for SQL Server (license-included, right-sized), and two latency-sensitive ones needing custom Always On went to EC2 with an Availability Group across two AZs. The core scheduling database used Babelfish + DMS full-load + CDC, ran 4 weeks in sync under regression and load testing, and cut over in an 18-minute window with a tested rollback that was never needed.
Outcome: All 18 databases migrated over ~7 months; 3 fully off SQL Server on Aurora + Babelfish, 13 on managed RDS for SQL Server (right-sized), 2 on EC2 with full Always On. Combined right-sizing plus the Babelfish de-licensing cut annual SQL Server + Windows TCO ~58% (from ~$1.1M to ~$460K). The migration engagement was MAP-funded against the post-migration AWS commitment, with the OLA delivered AWS-funded in Assess; CloudRoute’s commission was paid by the partner. The customer paid $0 for the assessment and migration itself.
estate: 18 DBs · timeline: ~7 months · license + Windows TCO cut: ~58% · core-app downtime: 18 min · migration cost to customer: $0 (MAP/OLA-funded)
CloudRoute routes you to a vetted AWS partner who runs the AWS-funded OLA, scopes MAP funding, and executes the migration — RDS lift-and-shift, Aurora + Babelfish re-platform, or EC2 with full Always On — with a de-risked cutover. AWS funds qualifying migrations. No DIY Babelfish learning curve on your production database.