I’ve been working with several people as they re-architect their SQL Server systems to use their hybrid or cloud-first providers for their systems. In each case of this example, they’re currently entirely on-premises with their systems and are moving to the other types of platforms.
What’s odd, at least to me, is that one of the reasons for the move that has come up a few times now is that they’re looking to use the move to take back control of the databases. By forcing the process of migrating and changing things up, they’re using that as a bit of a checkpoint in taking back control. I’ve worked with each quite a bit on this because I think it’s both the wrong thing to do and not something that will serve them well going forward in terms of end-user satisfaction.
Specifically, they feel that the development efforts and teams have too easy access to the SQL Server engines deployed, and they want to wrap tighter permissions and access controls around those processes and try to take back ownership of the data and responsibility for it.
That whole “responsibility for it” is probably a good thing, but using it to install new gates to the data is not something I’m really a fan of. In fact, if you’re moving (and upgrading) databases, there’s a good case to be made for doing the opposite; to use this as an opportunity to figure out how to make the information more secure, more available and more useful to the end-users. I think that’s the overall direction we’re all paddling the proverbial data ship and it’s important to the successful use and protection of information.
It’s sort of like being a fireman. Sometimes you have to run into the location on fire to put out the flames and return things to a better state.
If you’re facing such a move, IMHO, it may indeed be a great opportunity to re-evaluate your systems and access points. Review what information is used, how, where and by whom. Find out so you can support those uses that are legitimate. But use the new engine tools and technologies to support those initiatives, not put up unnecessary fences around them.
If you move systems and suddenly are providing more and better access, more concise and clear security, and more tools for management in terms of moving forward with your system, it’s a win all the way around.
We’ve done this successfully on several systems of late, creating new views, new tools, new stored procedures that are used to better manage things that are actually used. I say “actually used” because one thing that a move is great for is finding legacy access points and tools that may no longer be used or important. One example of this that I have talked about before is a hospital I was working at that distributed boxes of reports daily to the end-users. Because it had always been done that way…
I stopped the reports. Just stopped showing up with them. And waited to see who complained anticipating that we’d find out what they really needed and make sure they had that information.
No one complained. Not one person. They still got their work done, still got the information they needed.
It was a good lesson to review how your systems are used from time to time and make sure you’re both keeping up with the needs, and discontinuing things that are no longer needed.
However, the LAST thing you want to do is cut off access to needed information – or development efforts. Just not a good idea at all.