John Q. Martin

4 September 2025

10 Mistakes I’ve Made When Migrating Databases to the Cloud

You can also register now for John’s upcoming webinar ‘Lessons from the Cloud: Database Migrations Done Right’ (September 23rd 2025).

You’re Not Just Moving a Workload 

Over the past 20 years, I’ve helped organizations move on-premises and data center databases into the cloud. Sometimes this is a straight ‘lift-and-shift’. Other times, it also involves a transition to a different database platform, such as from Oracle and SQL Server to Snowflake, PostgreSQL, and Redshift. I’ve worked inside hyperscalers like Microsoft and AWS, and now, at Redgate, I support the data professional community in navigating the complexities of cloud migration. And I’m going to hold my hands up now and tell you: they’ve not all been perfect. 

Databases are the hardest part of cloud migration. They’re stateful, sensitive to performance shifts, and often contain sensitive or regulated data. As I often say: “You’re not just moving a workload, you’re moving a capability”. 

Rehosting vs. Replatforming or Refactoring 

Databases are inherently stateful systems. Unlike stateless applications, they maintain persistent data, complex relationships, and transactional integrity. Whichever migration strategy you choose, preserving the integrity and consistency of your data must be the primary concern. 

A rehosting or “lift-and-shift” migration typically uses backup and restore. This ensures data and schema consistency, but it can carry over scalability limitations from the old environment and miss opportunities to optimize for the cloud. By contrast, replatforming is usually done using schema-based migrations with separate data transfer. You migrate the schema objects first, making any necessary adjustments for compatibility with the new cloud platform, and with a new RDBMS if refactoring, before copying the data. This gives you the flexibility to optimize the workload for the cloud environment but makes it harder to maintain relational consistency compared to a full backup and restore.

Maintaining Performance 

Database workloads are highly sensitive to latency, I/O throughput, and CPU performance. Even small changes in infrastructure can cause significant performance degradation. Cloud performance isn’t entirely predictable, because cloud providers manage, and sometimes throttle, resources like CPU or I/O to ensure consistent service levels across multi-tenant infrastructure. 

Ensuring Data Governance 

Finally, databases often store sensitive data such as PII, financial records, or healthcare information. Migrating to the cloud introduces new governance challenges around access control, encryption, auditing, and regulatory compliance. In short, the database isn’t just a container of data; it’s the beating heart of many applications. 

10 Mistakes to Avoid in Cloud Database Migrations 

There are ten things I always watch out for—and advise others to consider—when migrating SQL Server and PostgreSQL workloads to the cloud, although the principles remain the same for all relational database engines.  

These ten lessons are grouped into five key areas – Strategy, Mindset, Process, Tooling, and Governance – each reflecting a different kind of challenge you’ll face during a migration. 

Strategy

1. Misunderstanding the Migration Models

There’s a lot of talk about the “7 Rs” of cloud migration: Retire, Retain, Relocate, Repurchase, Rehost, Replatform, Refactor (or Rearchitect). Most people focus on the last three, but all seven are relevant. I have been part of teams and repeatedly seen projects default to lift-and-shift because it’s familiar, but what people don’t always consider is how that often leads to higher costs and missed opportunities. 

Advice: Instead, start by mapping each database workload to the right migration strategy. Don’t assume lift-and-shift is the easiest or best. Use cloud migration frameworks from AWS or Azure to guide your decision-making and align with long-term business goals. If you’re replatforming or refactoring, tools like Redgate Flyway Enterprise can help you scope which schema objects to migrate, and handle the migration in a structured, testable way.

2. Underestimating Infrastructure Complexity

DBAs of all different backgrounds and skillsets are united in their ability to underestimate the added complexity of cloud infrastructure. 

SQL Server DBAs bring the discipline of tightly integrated, well-documented Windows environments. PostgreSQL administrators, more accustomed to the ‘untrodden’, community-driven tooling of open-source and Linux-based systems, bring sharp hands-on problem-solving skills. 

Both are valuable assets, but neither fully prepares you for the extra complexity of the cloud. Cloud platforms introduce new layers—like VPCs, IAM roles, and security groups—that challenge even seasoned professionals. There was a time when admitting what I didn’t know, and what I needed to learn, was a bitter pill to swallow. 

Advice: Invest in cloud training for your DBAs. Pair them with cloud engineers to bridge knowledge gaps. Tools like Redgate Flyway Enterprise help reduce risk by standardizing deployments and ensuring consistency across migration stages, which is particularly important when schema and data are migrated separately. 

Mindset

3. Treating the Cloud Like On-Premises

One of the biggest mindset shifts is realizing that in the cloud, you don’t buy infrastructure, you rent it by the hour (or the second). In the cloud, you’re paying for the capacity you allocate or reserve, even if those resources are mainly sitting idle. On-premises, we would typically size systems for three-or five-year lifecycles. I was part of a cloud migration project earlier in my career, where this ‘overprovisioning’ habit just resulted in the business burning through cash. As a result, I now tell teams: run hot, not bloated. 

Advice: Understand your baseline and peak workloads. Size for your peak usage now (with a healthy 10% buffer), not what you might need in five years. Observe usage for a whole business cycle, however long that may be for you. Redgate Monitor helps you track this in real time.

4. Operating Without a FinOps Mindset

You want the moon on a stick, but you’ve got the budget for a candy apple. That’s how I describe the disconnect between performance expectations and budget realities. Cloud success requires balancing both.  

FinOps brings financial accountability to the variable spend model of cloud. I once thought of it as a post-migration checkbox on a project checklist, something that naturally fell to the Finance team. In reality, keeping cloud costs in check is an ongoing process of adjusting performance, capacity, and cost decisions in response to changes in usage patterns, priorities and pricing models. 

Advice: A FinOps mindset means that everyone can take ownership of their cloud usage. Empower DBAs with cost visibility. Layer database performance insights from Redgate Monitor alongside application observability tools such as AWS CloudWatch or Azure Monitor to align database performance with business KPIs and budget constraints. 

Process

5. Skipping Right-Sizing Exercises

Right-sizing is one of the most overlooked parts of cloud migration. Oversizing (see mistake 3) is one of the easiest ways to waste money and get a nasty surprise when the first cloud bill lands. Conversely, I’ve also witnessed how under-sizing can cause mounting frustration when the cloud investment fails to deliver the anticipated performance optimizations. Regardless of whether a team is pre or post migration, I always ask, “How much are you willing to pay for acceptable performance?”  

Right-sizing is the practical application of a FinOps mindset. We use real workload metrics to predict resource needs, then continuously adjust capacity to balance cost and performance. 

Advice: Firstly, be strategic and selective about what you want to migrate, so you’re only moving what is required and not creating future technical debt. Secondly, baseline your workloads before migration, ensuring that you capture CPU, memory, I/O, and network usage over a full business cycle.  Post-migration, adjust resources incrementally, up or down, based on real usage and performance. When trimming capacity, adjust in small increments: reduce by 20%, observe performance, and repeat. It’s always easier to give more than to take away.

6. Failing to Test with Real Workloads

Contrived workloads don’t cut it. They don’t reflect the messy, unpredictable reality of production systems. I’ve learned that capturing and replaying real production activity is the only way to validate performance and uncover bottlenecks before going live. 

Advice: Capture real workloads using tools like SQL Server trace or PostgreSQL logs. Replay them in your target environment using free tools like RML Utilities or WorkloadTools. Redgate Monitor is ideal for baselining and validating database performance both pre and post migration, as it can monitor live performance on-prem and in the cloud.

7. Forgetting Post-Migration Optimization

I’ve worked with teams that were guilty of this. We finished a big migration, declared success, and then everyone instantly wandered off on to their next project. Six months later I got an urgent call asking for help: the cloud bill was double what was expected and yet the performance was way below expectations. No one had gone back to review how it was running. Migration isn’t the finish line; it’s the start of a new phase of optimization work. 

Advice: Use Redgate Monitor to keep track of resource usage and performance over time. Schedule regular reviews to fine-tune configurations. Work with your FinOps teams to ensure your technical decisions continue to align with budgets. 

Tooling

8. Not Knowing What ‘Good’ Looks Like

I’ve walked into crisis situations where I was expected to diagnose what had gone wrong based on only a few hours of monitoring data. Without a baseline telling you what “good” looked like on-prem, it’s impossible to know if things are better or worse in the cloud, or even if database performance is within the expected minimum and maximum thresholds. 

Advice: Deploy Redgate Monitor early. Capture metrics like query response times, transactions per second, and resource utilization. Establish baselines over a full business cycle so you can maintain stability during even the busiest of times and migrate with confidence. 

Governance

9. Neglecting Governance and Security Planning

Just because a cloud service is PCI-DSS compliant doesn’t mean your implementation is. I was involved in a project where I saw teams that had security and compliance automatically handled by the cloud provider, and that’s a dangerous mistake.  You still need to configure things properly and prove that your controls are working.  

Advice: Work with your security and compliance teams from the start. Define clear policies for access control, data retention, classification standards, and data protection requirements. . You can use tools like Redgate Test Data Manager to implement policy-driven data protection and support regulatory compliance across your database estate.

10. Overlooking Compatibility and Feature Gaps

I’ve also seen workloads break post-migration because teams didn’t realize that, for example, Amazon RDS for SQL Server limits sysadmin privileges. In one case, the legacy vendor application we were migrating checked for sysadmin access at startup and exited if it didn’t have it. We had to shift our entire migration strategy toward Retain/Retire, retaining the functionality but retiring the application in favor of one that worked with RDS. 

Advice: Run compatibility assessments well before migration. Tools like AWS Database Migration Service (DMS) or Azure Database Migration Service can generate a premigration assessment report, but only if you configure the schema conversion properly (e.g., enabling schema analysis in AWS DMS). In addition, tools like AWS Schema Conversion Tool or Azure Data Migration Assistant can help identify unsupported features when moving between environments or database platforms. 

If your workload depends on features not supported in standard managed services, consider using options like Amazon RDS Custom or Azure SQL Managed Instance, which offer more flexibility and control. 

Finally, use representative test workloads (see mistake 6) to trial your application in the new environment, especially if you’re refactoring or switching platforms. It’s the most reliable way to uncover unexpected behavioral or performance issues before go-live. 

Final Thoughts 

Cloud migrations aren’t just technical tasks; they’re strategic business decisions. Success depends on observability, cross-team collaboration, and a commitment to continuous optimization. Whether you’re moving SQL Server to Azure or PostgreSQL to AWS, start by baselining your workloads. With tools like Redgate Monitor and Redgate Flyway Enterprise, you can scope and migrate what’s needed, while gaining all the performance insights you need to make the right decisions, before, during, and after the move.  

September 23rd 2025, 4pm BST/10am CDT

Lessons from the Cloud: Database Migrations Done Right

Redgate’s John Q Martin leads a panel of seasoned experts who bring firsthand insights from high-impact migration projects across diverse industries - revealing how to deliver safe, auditable, and high-performance database changes at scale.

Register for the free webinar