How to migrate SQL Server to AWS, and what to check first
There is more than one way to move on-premises SQL Server to AWS. Choosing between RDS for SQL Server and SQL Server on EC2 changes what can and cannot come with you.
This page is for teams that want to move an in-house SQL Server to AWS but do not know where to start. GIIP has migrated on-premises SQL Server to x12large-class, 5-replica AWS RDS for SQL Server environments, and deployed 12 sets of that configuration.
You cannot choose between RDS and EC2
Everyone says managed is better, but you have no basis for judging whether your current operations survive on RDS.
You fear what will stop working
SQL Server Agent jobs, linked servers, file integrations — a lot of machinery lives outside the database itself.
The downtime window is small
The business can only tolerate a short outage, and you do not know whether the migration fits inside it.
RDS has no OS layer
You cannot log into the server. Anything that assumed the OS scheduler, a resident agent or local files does not survive unchanged.
Logins are not users
Copying databases does not bring instance-level logins. SID mismatches produce orphaned users — the classic failure.
A missed check multiplies per environment
Across many sets, one oversight repeats as many times as there are sets. Unless the procedure is reproducible, incidents scale with it.
Assemble the facts needed to decide first, then prepare both the cutover and the way back.
Inventory configuration and dependencies
Version, instance and replica configuration, jobs, linked servers and integrations enumerated, then split into what RDS supports and what must be replaced.
Design method against downtime
Fix tolerable downtime as a business constraint and choose a method that fits. Whether zero downtime is a workable premise is answered after checking, not before.
Keep operating it afterwards
Not a hand-off: the same team continues monitoring, performance analysis and incident response on the AWS environment.
What you can check yourself first
- SQL Server version and edition (Standard / Enterprise)
- Number of instances and the configuration including replicas
- Data volume and rough daily write volume
- The list of jobs running under SQL Server Agent
- Linked servers and integrations with other systems
- Processing that depends on the OS, such as file export/import
- How many hours the business can be down
What we can evidence
Customer names and system-specific information are withheld for confidentiality and security. Migration duration, downtime and performance change are not stated because they are not confirmed as measured values.
Frequently asked questions
RDS for SQL Server or SQL Server on EC2?
It depends on how much your current operations depend on the OS layer. If jobs and file integrations can all be replaced, RDS is easier to run; if some processing cannot be replaced, EC2 can be the realistic choice.
How much downtime is needed?
It depends on data volume, write rate and the method chosen. We do not quote generic figures that are not backed by measurement. Share your configuration and we will estimate with assumptions stated.
What happens to licensing?
RDS offers license-included options; on EC2, bring-your-own depends on edition and contract terms. We advise after reviewing your current licensing.
Can you operate it after the migration?
Yes. GIIP currently monitors and operates cloud databases including multiple AWS RDS for SQL Server instances with AI agents and human experts.
How to migrate Oracle to AWS, and how to choose the target
Check for free whether your database can be migrated Migration checklistLarge-scale database migration checklist — what to settle before you start
Check for free whether your database can be migrated Database migration costWhat actually determines the cost of a database migration
Check for free whether your database can be migratedCheck whether your SQL Server can move to AWS
Tell us your version, configuration and downtime tolerance. We never ask for passwords or connection strings.