I would say that I've honestly can't remember the last time I did a version upgrade migration and didn't do it this way instead of restoring the system databases. I just have had more success and more luck and feel more comfortable migrating to new instead of trying to restore over system databases between versions. I do not believe Max to be wrong with that answer hence the upvote. They also have an entire SQL Server migration command which runs their sub commands to copy over the items I typically would copy over. I like using their script to copy sql logins especially, because it handles the SQL authenticated users keeping their passwords and security identifiers the same so the database users from those logins will work. I like to review those and migrate over what I need using various scripts - lately that is the DBATools.Io powershell scripts. What exist in the system databases are jobs, logins, alerts, linked servers, encryption keys, etc. So when you restore database X to the new server, all of the database objects (Tables, Users, Views, Procs, Functions, etc) will be there as well. Those items at the database level should all live inside of a user database. You also asked about indexes, stored procedures, views. I find that playing with system database migrations and upgrades through restore to sometimes cause frustrations with the restores and it can carry over potential sins. I am not a fan of restoring system databases when doing an upgrade migration and I prefer doing migrations over in place upgrades as I discussed in this lengthy answer to another question.īasically I like to start "fresh" when I do a migration. Max gave a decent answer which I will upvote once I'm done typing this alternate view up.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |