In this post I would like to share some Best Practices about SQL Server Decommission:
1. Be aware of your Client IT Policy
The process of uninstalling / removing permanently a SQL Server Instance(s) goes beyond the technical scope. The stakeholders must be aware of what will happen and how their business will be impacted. Depending on the client’s IT policy, even minor changes on test envrionments must have a clear documentation and technical timeline of the events. This is usually done through a Change Management Tool. Some other factors to consider are:
- Extra caution is required when removing a single SQL Server Instance on a Cluster environment with another Instances in production that will not be part of the decommission;
- Make sure to understand if the Client is willing to decommission only the SQL Server product or the whole Windows Server infrastructure, and if another teams are involved;
- Understand the big picture of why the SQL Server is being removed. Despite it may look obvious ( nowadays most of the times it is cost-saving related), does the client know for sure what he is doing? As the DBA, part of your duties should be a trusted advisor for the client in case you notice they are doing something wrong.
Example: You identify the client need only to remove a single user database instead of uninstalling everything (Consider the non-technical business users) because they do not the difference between a SQL Server instance name, User database name, or even DNS name which they use to connect remotely.
This is a common quote from many SQL Server books: “If you don’t have backups, then you do not have a database at all”. This applies to Decommission scenarios as well. Chances of the client requesting back the disposed databases might be minimal. Let’s imagine they are of 1% only. Can you think of the consequences of telling the client their MSSQL is gone for good and and can no longer be restored due to lack of backups? This could cost your Job.
Ensure they are complete before uninstalling MSSQL. If for any reason you are unable to guarantee 100% of backups, it is better to suspend than to move forward to avoid pressure from above. Having the client to pay for some more time for that server running (assuming the decommission is cost-saving related) is preferable over the harsh task of bringing bad news later.
3. Collect useful data
Another tip is to collect useful data that can be helpful in the event of a rebuild. This type of information is commonly used on the client technical documentations (inventory), but it is worth to run some T-SQL scripts to capture actual information from the server prior the change. Such as: Configuration data (Data and Transaction Log locations, Service Pack /Cumulative Update level) are just a few examples.
4. Always use the standard removal method
Microsoft has specific procedures about uninstalling SQL Server Instances from versions 2000 to 2012, either through Standard setup (Add/Remove Programs) and manual ones, where you may need to deal with the Registry Hive. Be careful with this second option and always back up your registry prior changing anything, as it can damage the whole Operating System if something goes wrong there. If the standard removal setup is failing, consider reviewing the Setup Bootstrap Logs and identify what is causing the error and troubleshoot from there on.
These are 4 simple tips. Feel free to add your own comments or any questions you may have about this subject.