Max ha dato una risposta decente che voterò una volta finito di scrivere questa vista alternativa.
Non sono un fan del ripristino dei database di sistema quando eseguo una migrazione di aggiornamento e preferisco eseguire migrazioni sul posto degli aggiornamenti, come ho discusso in questa lunga risposta a un'altra domanda.
Fondamentalmente mi piace iniziare "fresco" quando faccio una migrazione. Trovo che giocare con le migrazioni e gli aggiornamenti del database di sistema attraverso il ripristino a volte causi frustrazioni con i ripristini e possa ripercorrere potenziali peccati.
Hai anche chiesto informazioni su indici, stored procedure, viste. Quelle voci a livello di database dovrebbero vivere tutte all'interno di un database utente. Quindi, quando ripristini il database X sul nuovo server, saranno presenti anche tutti gli oggetti del database (tabelle, utenti, viste, processi, funzioni, ecc.).
Ciò che esiste nei database di sistema sono lavori, accessi, avvisi, server collegati, chiavi di crittografia, ecc. Elementi a livello di istanza.
Mi piace rivederli e migrare su ciò di cui ho bisogno usando vari script - ultimamente quelli sono gli script DBATools.Io PowerShell. Mi piace usare il loro script per copiare gli accessi sql in particolare, perché gestisce gli utenti autenticati SQL mantenendo le loro password e identificatori di sicurezza gli stessi in modo che gli utenti del database da quegli accessi funzionino. Hanno anche un intero comando di migrazione di SQL Server che esegue i loro comandi secondari per copiare gli elementi che in genere copierei.
Non credo che Max abbia torto con quella risposta, quindi il voto. Ho appena avuto più successo e più fortuna e mi sento più a mio agio a migrare verso nuovi invece di provare a ripristinare su database di sistema tra le versioni. Direi che onestamente non ricordo l'ultima volta che ho eseguito una migrazione dell'aggiornamento della versione e non l'ho fatto in questo modo invece di ripristinare i database di sistema.