The Customer

• Founded: 2017
• Headquarters: Christchurch, New Zealand
• Industry: Consulting, DevOps and database modernization
• Clients: USA, Canada, UK and Australia

Morph iT helps organizations improve their application and database lifecycle management so they can see positive business value from DevOps. Managing Director Hamish Watson has over 20 years of IT experience running large-scale SQL Server estates, and has managed SQL Server since version 2000.

Database modernization and cloud migration are now a core focus for the business. Migrations are often triggered by a data center exit or a hardware refresh, but Hamish sees clients chasing wider benefits too: more predictable IT spend, resilient performance, less infrastructure to manage, and access to managed services. His most recent clients were driven by “an expiring data-center contract, poor SQL performance and a need to modernize the database engine and reduce infrastructure management overhead”.

The Challenge

Morph iT built a scenario which carried the most common challenges they encounter in client migrations:

• A fixed-deadline, for exiting a data center
• Sub-par SQL Server performance pre-migration
• Legacy SQL Server version requiring modernization
• A need to reduce infrastructure management
• No consolidated, auditable evidence to size the target

Moving a business-critical, complex and long-standing SQL Server workload to the cloud is a complex project. Teams need to understand what queries and demands are hitting a database workload, spot anything that might not run well in Amazon RDS, pick the right instance and check that everything is running as it should before and after any cutover.

Without that level of detail and scrutiny, the same problems keep appearing, risking outcomes that don’t live up to expectations: baselines don’t line up, dependencies found late, sizing based on guesswork and expensive tuning after go-live.

Redgate Monitor’s new cloud migration advice feature is designed to bring that level of detail and scrutiny to the planning stage. Available to all customers on version 14.33 or later, it uses the historical usage data Monitor collects to help you plan a move of SQL Server instances on virtual machines to Amazon RDS. Before offering it to clients, Hamish wanted to know whether it could address those risks, so he tested it on a representative migration of his own.

In Hamish’s words, the new capability to solve the biggest challenge of planning a migration: “Translating actual workload behavior into defensible target capacity, identifying expensive queries before moving them, and giving stakeholders an auditable baseline. Without consolidated evidence, teams can over-size for safety, or under-size and discover bottlenecks after they go live, subsequently failing to achieve their initial goals.”

Sizing a target accurately is a balancing act. Over-provisioning adds cost that doesn’t need to be there, while under-provisioning puts performance at risk during a client’s cutover.

Goals

For the test migration, Morph iT set goals it would expect from a client project:

Business goals:

• Exit the data center on schedule
• Make cloud spend predictable
• Defensible to stakeholders
• Cut the time consultants spend on assessment.

Technical goals:

• Upgrade to SQL Server 2022 Standard
• Land on a right-sized Multi-AZ Amazon RDS instance
• Confirm after cutover that performance and data integrity held.

Historically Morph iT relied on native DMVs, Query Store, PerfMon, custom scripts, infrastructure metrics and cloud tools. These all remain useful, but collecting and correlating comparable evidence across an estate is slow and manual for a consultant. Hamish therefore chose to deploy the newly released cloud migration advice in Redgate Monitor himself, using a SQL Server 2019 Standard workload on an Azure VM and an Amazon RDS target. The aim was to see whether it could automate an evidence-based AWS target, expose migration dependencies and keep performance visibility throughout.

The Solution

• Cloud migration analysis for readiness, target sizing and indicative cost
• Pre-migration performance baselining, post-migration monitoring of source and target
• A dependency review for areas the tool does not inspect

Morph iT assessed each environment separately, then standardized infrastructure and configuration through automation. Production sizing used representative observed demand, high availability needs, licensing and expected growth, while non-production environments were given different availability and capacity assumptions.

Assessment and sizing

The cloud migration analysis in Redgate Monitor assessed a seven-day lookback at p95 utilization with 20% headroom, taking in SQL Server edition, licensing, region and high availability. It reported the source as “Ready to migrate” and recommended a Multi-AZ Amazon RDS db.m7i.large (2 vCPU, 8 GB), with an indicative on-demand instance cost of US$8.54 per day.

Redgate Monitor also lists the areas its assessment cannot inspect. Morph iT used that list to drive a manual review of Windows logins, Agent jobs, linked servers, log shipping, tempdb and FILESTREAM. Query-level and host metrics had also flagged a CPU-bound report and bursts of CPU saturation on the source, so those were reviewed before the move rather than carried across.

Architecture and deployment

Redgate Monitor observed the source SQL Server 2019 workload on an Azure VM and, after onboarding, the Amazon RDS target, so both appeared together in a single estate view. Hamish sums up the value of keeping this one view across the move, “The single estate view in Redgate Monitor makes it easier to see source and target status throughout transition, compare historical and current behavior, and retain oversight while workloads move in waves.”

For resilience, the RDS target runs Multi-AZ, so a standby in a second Availability Zone takes over automatically if the primary fails. RDS instance size is changed by modifying the instance class, so scaling is a planned vertical step rather than auto-scaling, which suits a steady transactional workload.

• Amazon RDS for SQL Server (Multi-AZ): a managed engine removes patching and host management, and Multi-AZ provides failover without MorphiT operating a cluster.
• Amazon S3 with native backup and restore: used to seed the RDS instance with the initial data set.
• AWS Database Migration Service (DMS): applied the changes made after the initial seed, to keep the cutover window short.

Amazon CloudWatch and native SQL Server tooling were already part of MorphiT’s toolkit. Redgate Monitor complements them with the SQL Server detail needed to choose an Amazon RDS instance and check performance after cutover. As Hamish puts it, “Yes, you can use CloudWatch for most things, but if you actually want to improve what your database is doing, Redgate Monitor gives you all of the right things. It’s not just around the monitoring, it’s actually that ongoing performance tuning aspect of it.”

Migration and validation

Morph iT seeded RDS from a native backup restored through S3, then used DMS to apply subsequent changes. The controlled migration also exposed a data-movement risk. DMS reported no errors, yet around 8,000 orders were missing after the first seed. Comparing row counts found the gap, which came from a replication sequencing issue and not from Redgate Monitor. After correction, 176,054 orders and the matching order-line and inventory-history counts were identical on both sides.

As Hamish explains, “Having access to historical performance data, query execution statistics and resource utilization allowed us to identify potential issues earlier and validate whether the migrated workloads were performing as expected”

The Results

Key performance indicators

The first measure was the consultant effort needed to assess each SQL Server instance. Analyzing CPU, memory, I/O, queries, instance sizing and running cost by hand takes about 4 to 8 hours. With Redgate Monitor, the same work took about 30 to 60 minutes, with the analysis group created in minutes, saving roughly 3 to 7 hours per instance. . The figures come from Morph iT’s comparison of its manual approach with the time it observed in Redgate Monitor.

The second measure was peak CPU under a repeated workload. Morph iT ran the same workload against both the source server and the Amazon RDS target, and observed the results in Redgate Monitor. On the source, CPU peaked near 100%. On the RDS target, it peaked near 60%.

Business benefits

• Evidence-based sizing: a named RDS instance, readiness status and daily cost estimate.
• Clearer conversations: assumptions and limits that non-specialists can follow.
• Faster assessment: an estimated 30 to 60 minutes per instance, down from 4 to 8 hours.

Technical benefits

• More CPU headroom: peak CPU of approximately 100% on the source against 60% on RDS.
• Verified cutover: row counts caught 8,000 missing orders, and 176,054 matched after correction.
• Engine upgrade: SQL Server 2019 to 2022 on Multi-AZ Amazon RDS.

The test gave Morph iT what it set out to find: confidence that Redgate Monitor can turn existing workload data into a defensible AWS plan before anything moves. The results back that up: in a controlled test, peak CPU fell from near 100% on the source to around 60% on a right-sized Multi-AZ Amazon RDS instance, and each assessment took minutes instead of hours. The test also showed where judgment still matters. DMS reported no errors while 8,000 orders were missing, and a manual dependency review remains essential. Morph iT has taken both lessons on board, building the capability into its migration approach, from discovery and baselining through sizing, migration and validation, and plans to tailor it to each client’s estate.

As Hamish concluded, “A migration is a kind of life cycle where we go through the various phases, but having continued visibility with Redgate Monitor right throughout those phases is impressive.” Those phases are the start of a cloud journey, and Redgate Monitor supports customers throughout. Morph iT’s test covered the first two stages: planning the move, where cloud migration advice produced a right-sized Amazon RDS recommendation, and watching source and target together after cutover. The third is ongoing management, where sizing decisions can go out of date as workloads change. Redgate Monitor’s cloud cost visibility shows what virtual machines in AWS and Azure cost against what they use, so right sizing continues after the migration project closes. The evidence that justified the move carries on working after cutover, helping teams keep their cloud estate right sized, and their spend defensible, for as long as it runs.