This month’s T-SQL Tuesday is hosted by Koen Verbeeck (sqlkover.com, LinkedIn, @Ko_Ver). The topic is remigration, or moving from the cloud back to on-premises or a private data center.
Migration
As a data engineering consultant, I’ve helped many customers migrate from on-premises to the cloud. Because my experience lies in the Microsoft data sphere, nearly all of those migrations have been from SQL Server to Azure. Most migrations with which I’ve assisted have targeted Azure SQL DB, but a few have landed in SQL Managed Instance, still fewer have landed in other data platforms.
The reasons for migration to the cloud have been manifold. Most of the customers I helped were migrating to the cloud because they believed they could save money. Many believed offloading the care and feeding of on-premises servers – managing patches, security updates, and the like – would save them money in two ways:
- The enterprise would only pay for services needed by the enterprise (aka “right-sizing”); and
- In the case of enterprises with teams of data professionals, enterprises believed they may not need as many people.
The results were mixed.
Mixed Results
Right-sizing didn’t always work out the way some clients were led to believe it would.
In nearly every instance, the right-sizing argument was presented (sold) as the solution to over-provisioning, or purchasing hardware to serve peak loads. The classic example was a US income tax service that needed more and faster compute available to meet increasing demand starting in late January and peaking in mid-April each calendar year. After mid-April, hardware that was beefy enough to handle that peak load sat mostly idle for the next 9 months.
For enterprises with spike-y loads like this, the right-sizing argument made sense. And scaling up to manage the load and then scaling down during off peak times helped some bottom lines in real life.
Alas, Math.
Cost-benefit analyses, performed in earnest, demonstrated many companies were not achieving the savings for which they’d hoped (or been sold).
In addition to not saving money (or not saving that much money), limitations in functionality combined with (rare, but not never) cloud outages that, effectively, consumed the savings – sometimes as a slow bleed (functionality), sometimes all at once (Azure being down for a day).
A famous remigration / repatriation use case is Basecamp, who decamped (double entendre intended) the Amazon and Google clouds in 2023. According to their website dedicated to sharing their reasons and experience, they will save “~$10 million over five years” and not needed to add additional staff.
That’s quite a testimonial and ROI.
I do a lot of data engineering work. I can hear some of you thinking…
“How is data engineering impacted by remigrations, Andy?”
That’s a fantastic question. I’m so glad you asked!
I’ll speak to the impact on SQL Server Integration Services (SSIS), since I have more experience using SSIS than any other data engineering platform. I have it on good authority that SSIS package executions increased 15% in one 10-week period in 2024 (between the end of Summer to mid-Autumn).
That’s quite an increase.
When I learned this metric, I consulted friends and the community to gather their opinions as to why. To a person, everyone I consulted replied with some form of “economics.”
For my part, I noticed an uptick in subscriptions to my SSIS Premium recorded training offering, which includes seven days of recorded training </ShamelessPlug> around that same time – an uptick that has remained steady since that time.
That tracks because SSIS remains a supported and viable platform to accomplish on-premises data engineering.
Conclusion
What conclusions can we draw from remigrations? Math matters – especially when it comes to math about money.
Will all enterprises benefit from leaving the cloud?
Goodness, no.
Will some, though?
Goodness, yes.
I encourage all of my customers and potential customers to do said math.
Comments