Answers:
Max给出了一个不错的答案，当我输入完该备用视图后，我会投票赞成。
我不喜欢在进行升级迁移时还原系统数据库，并且我喜欢迁移而不是就地升级，正如我在对另一个问题的冗长回答中所讨论的那样。
基本上，我喜欢在迁移时开始“新鲜”。我发现通过还原进行系统数据库的迁移和升级有时会导致还原受挫，并且可能会带来潜在的麻烦。
您还询问了索引，存储过程，视图。这些数据库级别的项目应全部存在于用户数据库中。因此，当您将数据库X还原到新服务器时，所有数据库对象（表，用户，视图，过程，函数等）也将在那里。
系统数据库中存在的是作业，登录名，警报，链接的服务器，加密密钥等。实例级别的项目。
我喜欢复习这些内容，并使用各种脚本来迁移所需的内容-最近就是DBATools.Io powershell脚本。我特别喜欢使用他们的脚本来复制sql登录名，因为它可以处理经过SQL身份验证的用户，使他们的密码和安全标识符保持相同，以便这些登录名中的数据库用户都可以使用。他们还有一个完整的SQL Server迁移命令，该命令运行其子命令来复制我通常要复制的项目。
我不认为马克斯对此答案有错，因此不赞成。我只是获得了更多的成功和更多的运气，并且更愿意迁移到新版本，而不是尝试在版本之间恢复系统数据库。我要说的是，老实说，我不记得上一次进行版本升级迁移并且没有以这种方式执行而不是还原系统数据库的事情。
如果您需要访问存储在这些数据库中的元数据，则需要考虑迁移系统数据库（主数据库，msdb以及模型）。
主机存储诸如登录名，安全证书等项。
msdb包含有关备份的详细信息，并存储SQL Server代理作业配置以及其他详细信息。
您或您的团队可能已自定义模型，以允许新创建的空白数据库包含您在每个数据库中使用的一组预定义对象。
迁移系统数据库很容易完成。可从MSDN的“系统数据库的备份和还原（SQL Server）”中获得详细说明。
根据您的要求，您可以BACKUP DATABASE在2005实例上对用户数据库执行操作，然后RESTORE DATABASE在2016实例上对用户数据库执行操作，以带入整个数据库，包括所有数据，索引和其他对象。
至少在一开始，这将需要数据库在2005实例上消耗的空间量相同。但是，一旦还原了数据库，就可以利用数据压缩来大大减少所需的占用空间。
有关执行备份的详细信息，请参阅关于SQL Server备份；有关还原的详细信息，请参阅关于还原方案。
是2012年还是2016年？有所不同的是，IIRC 2012是经过测试的迁移路径，而2016不是。因此，已知问题已记录在案，并且/或者将被2012升级顾问捕获。未测试的路径可能仍然可以正常工作而没有任何问题，这只是未知的。就是说，强烈建议您参加2016年。我怀疑所做的努力几乎是相同的。
请参阅是否要从SQL Server 2005升级？在2005年升级选项的文档中，以及指向非常详细的升级过程的链接。升级过程是针对2014年编写的，但仍适用于2016年。