Our migration plan has changed slightly. To recap, we plan to migrate from our old two physical nodes with high availability groups on a SQL 2012 cluster with several named instances to a virtual (VMware) three node SQL 2017 (2017 due to vendor requirements
- we wish to maintain our named instances during the migration) system with Cluster Shared Volumes on Windows Server 2019 nodes. Currently, we plan to use the latest version of Microsoft's SQL Data Migration Assistant tool and/or a backup and restore method.
Some of our concerns are ensuring that we migrate ALL of the security information from the source to destination. Can the Data Migration Assistant do this or is the backup and restore method required? It still isn't clear to us.
When we create SQL instances on the new cluster won't we have issues with the installation stalling since we have DNS entries that already exist? What about existing named instances? We plan to use aliases if we must use different names/IP addresses.
Also, we may make the default instance a named instance on our new destination cluster. If we go this route, will this cause any complications for migrating databases that are currently in source default instance?
Some of our concerns are ensuring that we migrate ALL of the security information from the source to destination. Can the Data Migration Assistant do this or is the backup and restore method required? It still isn't clear to us.
When we create SQL instances on the new cluster won't we have issues with the installation stalling since we have DNS entries that already exist? What about existing named instances? We plan to use aliases if we must use different names/IP addresses.
Also, we may make the default instance a named instance on our new destination cluster. If we go this route, will this cause any complications for migrating databases that are currently in source default instance?