Migrating 12 sets of x12large-class, 5-replica SQL Server environments to AWS RDS

Case summary

The scale figures on this page are based on GIIP’s hands-on experience. Customer names and system-specific information are not disclosed for confidentiality and security reasons.

What this case study establishes

• GIIP has migrated on-premises SQL Server environments to AWS RDS for SQL Server.
• The target instances were x12large class, with 5 replicas per set.
• A total of 12 sets of that configuration were deployed.
• GIIP can continue to monitor and operate the AWS environment after the migration.

The environment before migration

The scope was SQL Server running on-premises — not one database server, but sets of instances including replicas, repeated across the estate.

In that shape, deciding server by server multiplies both effort and the chance of missing something. The procedure has to be fixed at the level of a set, then made repeatable.

Scale of the migration

• Target: AWS RDS for SQL Server.
• Instance scale: x12large class.
• Each set consists of 5 replicas.
• A total of 12 sets of the same class of configuration were deployed.

This page deliberately does not state which kind of replication the "5 replicas" refer to (read replicas, multiple instances, or an application-level replication design), nor a specific AWS instance family name, because those details are not confirmed.

What becomes the real issue at this scale

The more sets there are, the more every per-set check multiplies into total effort.

• Whether the same procedure can be reproduced across 12 sets. Whatever stays manual becomes drift between sets, and drift becomes incidents.
• RDS gives you no OS layer, so any operation that assumed on-premises (resident agents, local file integration) must be triaged before the move.
• With replicas in the picture, you cannot define a rollback path until you have decided which node is the reference at cutover.
• If nobody has been assigned to monitor the target, the migration completes into an operational vacuum.

Monitoring and operations after the migration

GIIP does not stop at cutover. The same team continues to monitor and operate the AWS environment afterwards. Multiple cloud databases including AWS RDS for SQL Server are under continuous monitoring by AI agents and human experts today.

AI agents handle metric collection, anomaly detection, log and performance analysis, periodic reporting, routine work along approved runbooks, and escalation. Work that is hard to reverse — schema changes, recovery decisions — is judged and approved by human experts.

Representative items to verify in a large SQL Server migration

• 01Accounts and logins (orphaned users caused by SID mismatches)
• 02SQL Server Agent jobs and schedules
• 03Linked servers and external connection dependencies
• 04How replication configuration is handled
• 05Backup method and restore procedure, redefined for the target
• 06Statistics and index rebuild policy
• 07Differences in collation and compatibility level
• 08Impact of character set and data type differences
• 09Application-side connection strings and timeout settings
• 10Cutover procedure and rollback procedure

This list is a general technical explanation. The items that actually apply differ by environment, and this is not a full account of what was performed in this engagement.

Frequently asked questions

Other migration case studies

Related database migration & operations pages

• Large-scale database migration
• Oracle 120k-table migration case study
• TiDB 3 TB migration case study
• AI database monitoring
• AWS managed operations
• 24/7 server monitoring
• Talk to us about a database migration