Last week I was involved in moving software solutions from one server farm to another. 
The transition plan was straightforward:
- prepare a new environment (IP addresses, DNS names, install software, updates etc.)
- preconfigure software (DB links, connection strings, etc.)
- stop current production environment (and notify users prior to that)
- backup databases and restore on a new environment
- reconfigure DNS
- test the new environment
Most of the servers were windows servers, so we didn’t have issues with updates etc.
The preconfiguration phase was done back in December 2018 and been waiting for the final step.
The result
The overall transition went pretty good. I would say that we predicted and covered 90-95% of configuration changes. Although we missed some places. The list is not that huge, but I find it quite interesting and wanted to share.
Here is the list of issues we encountered:
- hardcoded database connections in SQL views and procedures
- hardcoded configuration in the executables (needs for recompilation)
- different localization settings in the new environment
- glitch between app.config files in production and git (acting as our single source of truth). As you can see the list above touches a totally different set of problems.
How we can do better next time?
Given the fact that some of the code is edited directly in the database procedures, PowerShell scripts and config files, it’s hard to relay just on source code repository in the first place.
I wonder how much of this could have been avoided if we would use docker. Perhaps not all issues, but even the hardcoded values would work.