SQL Server to AWS Migration Readiness

Most SQL Server to AWS migration plans start too late in the stack. The conversation jumps straight to target services: Amazon RDS for SQL Server, Aurora PostgreSQL, DMS, SCT, EC2, or "modernize it while we are moving anyway." Those are real choices, but they are not the first choices.

The first question is simpler: what hidden SQL Server surface area is the application actually using today? If you answer that well, the target platform becomes obvious. If you answer it poorly, the migration looks green in a spreadsheet and red in production.

Three Migration Paths, Three Different Risk Profiles

RDS for SQL Server is the lowest-change path. The engine stays SQL Server, application queries mostly stay the same, and the migration focuses on backup/restore, DMS, logins, jobs, networking, monitoring, and operational runbooks. The trade-off is that licensing, edition constraints, and feature boundaries remain part of the cost model.

SQL Server on EC2 preserves the most control. It is useful when the workload depends on unsupported RDS features, custom file layouts, OS-level agents, cross-instance tooling, or legacy operational patterns. The trade-off is that the team still owns patching, HA design, backup validation, and the exact operational discipline that managed services were supposed to reduce.

Aurora PostgreSQL is the modernization path. It can reduce licensing exposure and improve managed-service economics, but it is an engine conversion, not a lift-and-shift. T-SQL, SQL Agent jobs, CLR, linked servers, SSIS packages, table hints, cross-database queries, and SQL Server-specific isolation behavior all need review before anyone can estimate timeline safely.

The Inventory That Decides the Target

A useful readiness review starts with an inventory that separates database objects from operational dependencies. Tables and indexes are only the visible part. The hidden migration blockers usually sit in scheduled jobs, integration packages, permissions, monitoring scripts, vendor connectors, and reporting workloads.

-- SQL Server migration readiness inventory starter
-- Run in each source instance and review results before choosing the target path.

-- SQL Agent jobs and schedules
SELECT
  j.name AS job_name,
  j.enabled,
  s.name AS schedule_name,
  js.next_run_date,
  js.next_run_time
FROM msdb.dbo.sysjobs j
LEFT JOIN msdb.dbo.sysjobschedules js ON js.job_id = j.job_id
LEFT JOIN msdb.dbo.sysschedules s ON s.schedule_id = js.schedule_id
ORDER BY j.name;

-- Linked servers
SELECT
  name,
  product,
  provider,
  data_source,
  is_linked
FROM sys.servers
WHERE is_linked = 1;

-- CLR usage
SELECT
  name,
  permission_set_desc,
  create_date,
  modify_date
FROM sys.assemblies
WHERE is_user_defined = 1;

-- Cross-database references in module definitions
SELECT
  DB_NAME() AS database_name,
  OBJECT_SCHEMA_NAME(object_id) AS schema_name,
  OBJECT_NAME(object_id) AS object_name
FROM sys.sql_modules
WHERE definition LIKE '%].[%'
   OR definition LIKE '%USE [%'
   OR definition LIKE '%EXEC %.%.%';

None of these checks are complicated. The failure mode is that teams do them after the migration tool has already produced a confidence score. The tooling score can look good while the operational inventory tells a different story.

RDS for SQL Server Is Not "Just SQL Server"

RDS removes a lot of administrative work, but it also changes what you can touch. You do not get full OS access. Some server-level features and third-party agents are constrained. SQL Agent exists, but job ownership, file paths, proxies, credentials, and external commands may need redesign. Backups are managed differently. High availability is Multi-AZ, not the exact Always On topology many teams run on-prem.

That is not a reason to avoid RDS. It is a reason to test the operational model before cutover. If the current system depends on a local file drop, a command-line job step, a share-mounted ETL process, or a server-level permission pattern, the migration needs a replacement workflow. Otherwise the database moves and the business process does not.

Aurora PostgreSQL Requires T-SQL Triage

SQL Server to Aurora PostgreSQL is attractive when licensing pressure is real and the application is already being modernized. But the hard work is in behavior, not syntax. Stored procedures can be rewritten. The risky parts are the places where SQL Server behavior is implied rather than obvious.

Examples include DATETIME rounding behavior, IDENTITY insert workflows, case-insensitive collations, MERGE semantics, TOP with ordering assumptions, table variables, temp table scope, transaction isolation, and error handling. AWS SCT can identify many conversion items, but the readiness question is not "can this be converted?" It is "can we prove the converted behavior matches production?"

For heavy procedure estates, build a conversion backlog before choosing dates. Categorize procedures into four buckets: auto-convert, rewrite mechanically, redesign because the pattern is SQL Server-specific, and retire because the job/report/integration is no longer needed.

DMS Helps With Data Movement, Not Application Confidence

AWS DMS is useful for full load and change data capture. It does not validate business behavior. It does not rewrite SQL Agent jobs. It does not prove that a reporting workload behaves the same under PostgreSQL's optimizer. It does not solve the application cutover sequence.

For SQL Server sources, the DMS readiness review should include CDC or transaction log access, source load during full load, LOB/text column handling, identity handling, primary key coverage, and the target apply rate. A successful DMS task can still produce a bad cutover if validation is shallow.

The Validation Plan Should Be Built Before the Migration Window

Validation is where migration plans become real. Row counts are a starting point, not an acceptance test. For finance, healthcare, insurance, logistics, and SaaS workloads, the checks need to prove recent writes, calculated totals, operational reports, and critical business workflows.

A practical validation pack includes:

• Table row counts and checksums for high-value tables
• Recent-record sampling for the last 24 to 72 hours of writes
• Known business totals: invoice balances, shipment counts, policy counts, member counts, order totals
• Stored procedure output comparison for critical workflows
• Top reporting queries with runtime and result-set comparison
• Backup/restore proof on the target, not just backup configuration
• Rollback decision criteria: exactly what failure means "go back"

The Cutover Runbook Is the Real Deliverable

A SQL Server to AWS migration readiness review should end with a runbook, not a slide. The runbook should say what happens before freeze, during final sync, at application stop, at validation, at DNS or connection-string flip, during smoke tests, and during rollback. Each step needs an owner, command, expected output, and go/no-go rule.

The target service choice matters, but the runbook is what protects the weekend. RDS for SQL Server, EC2, and Aurora PostgreSQL all work when the dependencies are understood. They fail when the team treats "database migrated" as the same thing as "system ready."