SQL Server to AWS — managed lift-and-shift, or delete the license bill with Babelfish.
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 the complimentary OLA and MAP migration funding work.
- Three destinations, three different projects. Amazon RDS for SQL Server is a homogeneous lift-and-shift — same engine, managed by AWS, BYOL or license-included, live in weeks, near-zero application rewrite, but you keep the SQL Server license bill. Aurora PostgreSQL with Babelfish is the re-platform that deletes SQL Server licensing entirely while your existing T-SQL and TDS-protocol apps keep connecting — the real prize, with conversion effort scoped by how much your code uses SQL Server-only features. SQL Server on EC2 is the full-control option: any edition, custom configuration, full Always On Availability Groups, when RDS’s managed boundaries are too restrictive.
- The decision is driven by the Optimization & Licensing Assessment (OLA), a complimentary AWS analysis that inventories your actual SQL Server core usage and Software Assurance position, models BYOL vs license-included vs Babelfish, and right-sizes so you stop paying for cores you do not use. For the Babelfish path, the toolchain is the Babelfish Compass assessment plus AWS Schema Conversion Tool (SCT) for what Babelfish does not cover natively, and AWS Database Migration Service (DMS) for the data: full load then change-data-capture (CDC) so the cutover is minutes, not a weekend.
- The motivation is licensing cost and Windows/SQL lock-in. SQL Server Enterprise lists around $15,000+ per two-core pack, Standard around $3,900, plus Software Assurance, and running it under a hypervisor or in the cloud raises licensing-mobility questions that grow with every core. Right-sizing on RDS already trims the bill; Babelfish can remove the SQL Server license line item entirely. CloudRoute can match you with a vetted AWS partner who runs the OLA and the migration. If the move is onto AWS and qualifies, the partner files MAP (Migration Acceleration Program) funding for it. AWS approves.
IWhy teams move SQL Server to AWS — licensing, Windows tax, and operational toil
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.
IIThe three real paths: RDS for SQL Server, Aurora + Babelfish, or EC2
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.
Path A — Amazon RDS for SQL Server (managed lift-and-shift)
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.
Path B — Aurora PostgreSQL + Babelfish (the license-killer re-platform)
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.
Path C — SQL Server on Amazon EC2 (full control)
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.
IIIBabelfish Compass + SCT: the assessment that sizes the re-platform
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.
- SQL Server Agent jobs. No Agent in Aurora. Scheduled jobs are re-implemented with pg_cron, or with Amazon EventBridge Scheduler + AWS Lambda / Step Functions for anything beyond simple SQL.
- SSIS / SSRS / SSAS. Integration, Reporting, and Analysis Services are separate SQL Server products with no Babelfish equivalent. ETL moves to AWS Glue / Step Functions; reporting to QuickSight or a third-party tool; analysis-services cubes are the heaviest re-architecture.
- CLR assemblies. .NET code running inside SQL Server has no PostgreSQL equivalent and must be rewritten (often as application-tier logic or PL/pgSQL).
- Linked servers + distributed queries. Cross-server queries via linked servers need redesign — typically postgres_fdw, application-tier joins, or a data-integration layer. System stored procedures and DBCC commands also map to different Aurora mechanisms (many become unnecessary under managed Aurora).
- Advanced / niche T-SQL + cross-database queries. Some windowing edge cases, MERGE patterns, hints, and SQL Server-only built-ins surface as rewrite items in Compass — as does three-part naming across databases on one instance, which maps differently in Babelfish’s single-database model.
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.
The SQL Server features that fall outside Babelfish
These are the constructs Babelfish Compass will flag, and the ones every SQL Server→Aurora migration spends its engineering hours on:
IVAWS DMS: full load, then CDC to a near-zero-downtime cutover
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.
VAlways On, high availability, and a rehearsed cutover
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.
- Pre-cutover (days before): Target live under DMS CDC, trailing by seconds. Regression suite green against the target, DMS validation clean, performance tested at production load — PostgreSQL’s planner (Babelfish path) differs from SQL Server’s, so plans and indexing are tuned in advance, not discovered in production.
- Cutover window (the minutes that matter): Short maintenance window. Stop writes to SQL Server, let DMS apply the final change backlog until the target is caught up, run reconciliation checks, repoint connection strings to the target.
- Smoke test on the target: Run the critical-path transactions (login, core write paths, heaviest reports) before reopening to users. A scripted smoke test takes minutes and catches the connection-string-typo class of failure.
- Go / no-go decision: If smoke tests pass, reopen traffic and monitor. If anything is wrong, roll back: repoint to SQL Server, reopen, debug the target offline. Because SQL Server was never demoted, rollback costs minutes, not data.
- Post-cutover stabilization: Keep SQL Server read-only as a safety net for a defined window — commonly one to four weeks — then decommission and stop the license/SA renewal. That decommission date is the day the savings start.
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.
A typical mission-critical cutover sequence
The discipline below converts an unbounded risk into a bounded, rehearsed, reversible event:
VIThe OLA: a complimentary AWS check on the licensing decision
The AWS Optimization & Licensing Assessment (OLA) is the program 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, and AWS calls it complimentary.
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 also feeds the AWS Migration Acceleration Program’s Assess phase: it produces the business case a partner uses when it files 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. AWS offers the OLA as a complimentary program.
VIIMAP and the OLA: a vetted partner runs it and files the funding
You do not have to assemble an internal Babelfish, SCT and DMS team from scratch. CloudRoute matches you with a vetted AWS partner who has migrated SQL Server before. If the move is onto AWS and qualifies, that partner files MAP funding for it.
The vehicle is the AWS Migration Acceleration Program (MAP), which has three phases: Assess (the OLA and Babelfish Compass produce the right-sizing data, the per-database path recommendation and the cost model), Mobilize (landing zone and pilot) and Migrate & Modernize (production migration and cutover). AWS runs a MAP track for Microsoft workloads, including SQL Server. Your matched partner files the MAP request when the migration qualifies. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves.
The honest framing matters: MAP is for workloads moving onto AWS, AWS decides what qualifies, and the amount is scoped during Assess. If your SQL Server already runs on EC2 or RDS, a move to Babelfish stays inside AWS and is not a MAP migration. Where funding does not apply, the value is still real: a vetted partner who has done SQL Server to RDS and SQL Server to Babelfish migrations de-risks the cutover, instead of your team learning Babelfish’s coverage gaps and SCT’s edge cases live on production.
CloudRoute’s role is the match. 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 with a partner that has a SQL Server migration track record and can run the OLA and file MAP. The partner runs the assessment, scopes the funding and executes. CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
For the funding side, see how much funding a partner can file and how AWS POC funding works. 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 what a CloudRoute match includes.
RDS for SQL Server vs Aurora + Babelfish vs EC2 — cost, effort, control
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 |
| Funding route | Complimentary OLA; MAP if the move onto AWS qualifies | Complimentary OLA; MAP if the move onto AWS qualifies | Complimentary OLA; MAP if the move onto AWS qualifies |
| Best for | Feature-dependent DBs; speed; minimal change | High-license-cost, Babelfish-tractable apps | Full Always On, OS access, RDS too restrictive |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
Should I lift-and-shift SQL Server to RDS, re-platform to Aurora with Babelfish, or run it on EC2?
What is Babelfish and does it really let my T-SQL apps run on PostgreSQL unchanged?
What is the OLA and why does it matter so much for SQL Server?
How much does moving SQL Server to AWS actually save?
What is the SCT + DMS workflow for the SQL Server to Aurora path?
Can I run SQL Server Always On Availability Groups on AWS?
How long does a SQL Server-to-AWS migration take, and can AWS fund it?
Get your SQL Server migration to AWS run by a vetted partner
A vetted AWS partner runs the complimentary OLA, executes the migration (RDS lift-and-shift, Aurora + Babelfish re-platform, or EC2 with full Always On) with a de-risked cutover, and checks whether the move qualifies for MAP funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.