Thomson Reuters moved more than 18,000 databases and 500 TB of data to Azure SQL Managed Instance. The new setup supports about 7,000 tax firms and 70,000 users. The move improved performance and reduced some SQL Server support work. Yet cloud operating costs rose at first. The company had to review licenses, service tiers, and workload sizes before costs improved. Microsoft's Thomson Reuters case study shows why this gap matters.
Cloud migration can reduce infrastructure work. It can also give teams access to managed database services. But moving a database doesn't guarantee lower cost or better performance. Results depend on the target system, workload design, application links, and testing after the move.
Lower cloud costs depend on how the workload is moved
The case for cloud migration often starts with cost. Microsoft has cited research that found savings of up to 47% for some on-premises SQL Server workloads moved to Azure virtual machines. That figure shows what may be possible under certain conditions. It doesn't mean every SQL Server workload will save 47%.
A move can reduce hardware replacement costs. Managed services can also reduce some patching, backup, and maintenance work. That gives companies a valid reason to include cost savings when they review SQL Server migration services. Still, the cost estimate should come from real workload data.
The Thomson Reuters case makes this point clear. Its migration delivered useful operating gains, but cloud costs rose at first. Costs improved after the team changed licensing choices and adjusted service tiers. The lesson is simple: moving to Azure may change costs, but cost control still requires work after the move.
The right Azure target must be chosen before migration starts
Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs don't work in the same way. Each option has different limits and management duties. A cheaper target can create extra work if an application depends on features that the target doesn't support.
Microsoft's Azure SQL Database assessment rules list issues that can affect a move. SQL Server Agent jobs don't work in Azure SQL Database in the same form. CLR assemblies can also cause problems. Some BULK INSERT patterns need changes as well.
This is why assessment should come before target selection. A team planning SQL Server modernization should first map its databases and their dependencies. It should also review jobs, application connections, security needs, and performance demand. This work helps the team avoid picking a target that looks cheap but needs heavy repair work later.
Large migrations succeed when the move is broken into controlled stages
The Thomson Reuters migration shows how a large project can work in practice. The company had to move more than 500 TB of data across 18,000 databases. It couldn't restore everything in one step. Azure restore limits meant the team had to work in batches of about 400 to 500 databases.
That detail matters. A platform may support the final workload while the migration process still has limits. Those limits affect schedules, testing, staffing, and rollback plans. They can also change the cost of the project.
A capable database migration company should plan for those limits before cutover. Teams should know how workloads will be grouped and tested. They should also define rollback steps and acceptance checks. A migration isn't finished just because the database starts on the new system. Applications must work, response times must remain acceptable, and production recovery must be possible if something fails.
Lift and shift can carry old problems into Azure
A lift-and-shift move can be useful when a company needs to leave old hardware quickly. It can also keep many parts of the old setup unchanged. That may reduce migration work, but it can carry old design problems into the new environment.
The UK's National Cyber Security Centre warns that lift-and-shift projects can bring existing problems into cloud systems. Its guidance on lift-and-shift migration also notes that poor cloud design can create new security problems.
This matters during a SQL Server to Azure migration. Moving SQL Server to an Azure VM can keep a high level of compatibility. It may also leave the team responsible for many tasks it handled before, including operating system work, SQL Server settings, patching, and capacity planning.
A managed database service can remove more infrastructure work. But it may require more changes to applications and database features. The right choice depends on the goal. A fast move away from old hardware may call for one path. A larger change in how the database is run may call for another.
SQL Server 2016 support deadlines add pressure to migration plans
SQL Server 2016 reached the end of extended support on July 14, 2026. Microsoft offers Extended Security Updates for SQL Server 2016 through July 17, 2029. The SQL Server 2016 lifecycle page confirms those dates.
Extended Security Updates give companies more time to move. They don't restore normal product support. Teams still need a plan for older SQL Server systems that can't remain in their current state for much longer.
Security risk also grows when old software remains in use. CISA has listed unsupported operating systems and outdated software among common security problems found during assessments. Its report on recurring security weaknesses explains how old systems can leave known weaknesses open when fixes are no longer available.
This gives companies a real reason to review cloud database migration services. Still, support deadlines shouldn't force a rushed production move. Teams need time to test applications, compare performance, and define rollback rules before cutover.
Migration claims become credible when teams measure the result
Claims about lower support work can be valid when the new platform removes work the team performs today. Managed database services can take over parts of patching, backup work, and high availability. Cost savings are also easier to defend when compute sizes come from measured use instead of old server specifications.
Performance claims need the same care. Teams should record response times and resource use before the move. They should then measure the same workload after cutover. This shows whether the new environment is actually better.
A migration can improve the database platform without fixing poor queries or weak application design. Those problems may still exist after the move. That is why SQL Server migration planning and modernization work should include checks after production traffic returns to normal.
Checks to complete before accepting a migration claim
A SQL Server migration business case should define what success means before work begins. Cost savings should include licenses, cloud resources, support work, and data transfer where those costs apply. Performance goals should name the workloads and response times being measured.
The technical plan should also identify databases that are ready to move and those that need changes. Teams should define cutover tests and rollback points. After the move, they should compare real cloud bills with the original forecast. These checks make it easier to see whether the promised result appeared in production.
Frequently asked questions
Does moving SQL Server to Azure always reduce cost?
No. Cost depends on the Azure service, compute size, storage, licensing terms, and workload use. Thomson Reuters saw higher cloud operating costs at first. The company later improved those costs by changing licenses and service tiers. Teams should check real usage after migration instead of assuming the first cloud bill will be lower.
Is SQL Server 2016 out of extended support?
Yes. SQL Server 2016 reached the end of extended support on July 14, 2026. Microsoft offers Extended Security Updates through July 17, 2029. Those updates give companies more time to move. They don't provide the same support that was available before July 2026.
Is Azure SQL Managed Instance always the best target?
No. Azure SQL Managed Instance offers high SQL Server compatibility, but it won't be the right choice for every workload. Some databases may fit Azure SQL Database. Others may need SQL Server on Azure VMs because of system-level or application needs. Assessment should decide the target before migration plans are fixed.
Why do SQL Server migrations face compatibility problems?
SQL Server applications often depend on features outside the main database. Jobs, CLR code, drivers, linked systems, and server settings can all affect a move. A database can look simple until these links are checked. Finding them early gives teams more time to fix them before cutover.
What should teams measure after migration?
Teams should measure the same things that supported the original business case. That may include response times, cloud spend, resource use, uptime, licensing costs, and support effort. The results should be compared with the pre-migration baseline. That comparison shows whether the project delivered the outcome that was promised.
For more info Contact Us or send mail : [email protected] to get a quote.
Comments
Log in or sign up to join the conversation.