When is the right time to move to new technology?
Andy Leonard asks about balancing new features and proven technology. And certainly the challenge is real.
I see new features get released, and part of me would love to have all my customers using them. But there is always a cost, and I don’t like my customers to spend money for no reason.
In some ways, upgrades are not as expensive as they once were. Upgrading anything, whether it’s bespoke software or a well-established platform, involves spending time on the work to do it, and that’s assuming that the change doesn’t break anything. Testing should not be neglected, but software vendors do a much better job of testing now compared to 25 years ago, and platform vendors know the importance of backward compatibility.
Cloud technologies such as Azure SQL or Power BI change platform versions behind the scenes, and customers might see performance improve (or occasionally worsen) without their having to do anything, but still making the switch to using new features is not free. If I’m working on something anyway, I can use a new feature – some new visual perhaps, or a T-SQL function – but if I’m not already in there, and the current system works well enough, then the cost to use a new feature simply might not be worthwhile.
Small updates to systems come through so frequently these days that it feels like larger software changes have become rarer. If the system you use gets an update several times a year, then it’s less likely that the grass will feel greener somewhere else. Why would someone leave the Power BI platform when new features appear every month? If some other product offers an amazing feature, aren’t all the competitors likely to roll out their own equivalents? Whereas if upgrading from version 6 of something to version 9 is a large undertaking, changing to the competitor is much easier. Vendors know this and want us to be on their journey of frequent updates.
At times change can feel like a train rushing past, and jumping onto a moving train from an on-premises platform that gets updated every few years can feel like a lot. But once you’re on the train, the change doesn’t feel like it’s a lot any more – relativity makes it feel like the rest of the world is rushing backwards instead.
Andy gives the example of Microsoft Fabric, which at the moment feels new, but which is being built on a lot of existing technology. The VertiPaq technology used in OneLake has been proven effective over many years now. Fabric pipelines leverage technology used within Azure Data Factory (and one day will hopefully have feature parity). And while there are certainly new things, a lot of the platform is already good.
For customers that jumped onto the speeding train that is Azure, there are obvious questions about moving to the Fabric train. If their analytical data lives in Azure SQL, and they’re using Power BI to analyse it, then they already see change coming through. A shift to Fabric might mean you can use Direct Lake mode to consume data, but even if you don’t move to Fabric right away, you’ll continue see new features coming to (most parts of) Azure SQL and Power BI.
Right now, the return on the cost of switching trains is not entirely clear, but in time the cost may become inevitable.
My perspective is that people should be ready to jump onto the train. Whether it’s being Fabric-ready, AI-ready, or real-time-ready, whatever – the steps to prepare for new technology are often helpful in their own right. Knowing the things that might need to change and understanding the patterns that work on the new system as well as the old – these are things that can get you ready to make the leap. Because one day you might need to jump whether you’re ready or not.
And if the train you’re on might start slowing down, perhaps it’s better to move sooner rather than later.
