A Big WIN in the Medical Field: Migrating SQL Server to Amazon RDS

It’s always awesome when I get to share about successes that benefit our clients, and this one knocks it out of the park. This is the start of a multi-post series that dives into a recent success I had with one of our clients in the medical industry where we took steps for migrating SQL Server to Amazon RDS. This was a project that brought not only technical challenges but also a great opportunity for us to make a meaningful impact. I always enjoy working on these kinds of projects and welcome the challenge. So, let’s kick off the first part of this multi-post series.

Migrating SQL Server to Amazon RDS for Our Client

The Start to Migrating SQL Server to Amazon RDS: The Client’s Need for Change

Our client was already working with Amazon Web Services (AWS), running SQL Server on EC2 instances across their infrastructure. They had 800+ SQL Server databases spread across six EC2 instances. The client’s main goal was to reduce the complexity and overhead of managing their infrastructure while ensuring high availability through Multi-Availability Zone Database Mirroring (DBM) on Amazon Relational Database Service (Amazon RDS). In short, they wanted to move their SQL Server environment to Amazon RDS to take advantage of less manual management and more robust uptime.

Initially, the client brought in a vendor specializing in Amazon migrations, and while they made some good progress, they ran into trouble using Amazon Database Migration Service (DMS) for the database migration. The vendor faced some technical errors that would require complex workarounds—things like removing and re-adding features or toggling items off and on in the databases during the migration. This wasn’t ideal, and that’s when Fortified Data was brought into the picture.

A Better Solution: Backup/Restore vs. AWS DMS

After reviewing the errors and discussing the situation with the vendor, we made the call to ditch AWS DMS. We recommended a more straightforward and less disruptive approach: using a backup/restore process to migrate the databases to Amazon RDS. Our thinking was simple: by keeping the database architecture intact during the migration, we could avoid introducing additional risks and minimize the chances of post-migration issues. It was a cleaner, safer route.

So, Fortified Data took over the responsibility for migrating the data, while the vendor and client continued handling the environment architecture and setting up the RDS instances. As we started to get a better understanding of the project, we discovered a critical limitation with the RDS Standard instance that would have a significant impact on cost.

The Discovery: Amazon RDS Standard’s Limitation

One of the big surprises during our planning phase of migrating the data was that the largest RDS Standard instance could only support a maximum of 50 databases per instance—this was with Multi-AZ enabled. With 800+ databases across six SQL Server instances, that meant the client would need to deploy 16 or more RDS Standard instances just to accommodate their existing database count. And when we factored in the cost of running these instances, the numbers weren’t looking great. In fact, we estimated that running 20 RDS Standard instances (just for the production environment) would cost roughly $118,000 per month—and over $1.4 million per year.

We knew there had to be a better solution, and that’s when we suggested RDS Custom, which supports up to 1,000 databases per instance. We ran the numbers again, and this time, the estimate for six RDS Custom instances came in at $44,400 per month—around $532,800 per year. That’s nearly a $883,200 savings annually.

The Decision: Moving to Amazon RDS Custom

After reviewing the numbers and understanding the long-term cost implications, the client agreed to move forward with RDS Custom. Our client also decided to decommission about 200 databases, which slightly changed the estimate, but the savings remained significant. Even after including non-production environments in the estimate, the cost difference was clear: 20 RDS Standard instances would still cost more than 9 RDS Custom instances.

To summarize the cost savings, running 9 RDS Custom instances (including non-production environments) was estimated at $66,600 per month—about $799,200 per year. That’s still a $616,800 per year savings over RDS Standard instances.

An Upgrade and a Win for the Future

While we were sorting out the RDS instance types, we ran into another challenge: RDS Custom doesn’t support the built-in stored procedures for backing up directly to AWS S3, which is a feature available in RDS Standard. The client was on SQL Server 2017, and while they hadn’t planned on upgrading SQL Server just yet, this limitation led to an important decision. We recommended upgrading to SQL Server 2022, the first version to support backups directly to AWS S3.

This upgrade gave the client a chance to do more than just migrate—they could also improve the performance and capabilities of their environment. In addition to the version upgrade, we recommended updating the compatibility level of all databases to SQL Server 2022 (compatibility level 160), moving away from the outdated SQL Server 2008 compatibility level (100) they were running. It was the perfect opportunity to test these upgrades during the migration process.

The Takeaway: A Big WIN

When all was said and done, this was a huge win for the client. By bringing Fortified Data into the mix, we were able to recommend a migration process that avoided the pitfalls of DMS and saved them a significant amount in infrastructure costs. The client also took advantage of the SQL Server upgrade, ensuring they wouldn’t have to worry about future downtime for version upgrades.

In my next post, I’ll dive deeper into the migration process itself—specifically, how we managed to move over 600 databases from Amazon EC2 to Amazon RDS Custom smoothly. Keep an eye out for next post!

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *