随着微软发布下一代SQL Server(SQL Server 2012)，人们很容易忽略的是，现在机房和数据中心仍然有大量运行着SQL Server 2005甚至2000的服务器。现在，可能是时候对它们进行升级了。

　　许多组织仍然在坚持使用这些旧版本，因为SQL Server不同版本的升级过程是非常麻烦的。但是，有许多方法可以实现数据库版本之间的迁移，其中最简单的一种就是：复制。

　　使用复制最主要原因是：您可以在迁移过程中保留现有的SQL Server环境。无论处理的是一台或两台物理服务器，您都可以一起安装新版本的SQL Server，同步复制数据库，然后再迁移到新的服务器，从而减少旧服务器的停机时间——这对于只有一台服务器的组织是非常重要的。

　　实现这个过程的方法有很多。最简单的方法是执行一个备份-恢复操作，再通过单向复制操行保证所有数据和对象都保持一致。这种方法能够一次性复制大部分的数据和模式，而且复制过程中能够使两个副本保持一致。

　　复制过程的模式修改可能会出现问题。在大多数情况下，模式修改是无缝迁移的，但是有一些特殊内容是无法迁移或者经常会出现问题的：

　　标识字符无法修改或删除;如果出现这个问题，它们将无法正确复制。

　　索引无法添加、修改或删除。但是，为了自动处理约束(如主键)，索引是隐含创建的。

　　未显示命名的约束不会自动生成名称，因此可能在发布者和订阅者之间产生不一致。

　　另外还有其他一些问题。简而言之，要避免对模式或对象设计进行大改动，同时要使用复制保持新旧环境的同步。

　　另外，根据您处理的硬件，备份过程本身可能导致SQL Server实例的响应速度减慢。与其他重要操作一样，最好的方法是在非高峰期执行备份操作。复制本身对系统性能的影响是很小的，但是备份可能会使一些方面性能下降，特别是当它们写数据的物理服务器就是数据库所在的服务器时。

　　在备份后执行复制的一种方法是，使用原始(发布者)数据库的现有备份。然后，直接从该备份初始化订阅。采用这种方式，您就不需要恢复备份。在SQL Server 2008中，这种迁移可以通过 sp_addsubscription命令和@sync_type=’initialize with backup’选项实现。

　　这是一种真正节省时间的方法：除非备份是离线存储的，否则您不需要自己搜索备份和将它填充到新的SQL Server实例。而且，如果您在旧服务器上部署了自动备份计划，那么您完全不需要修改;您可以专注于新服务器的操作。

　　然而，这个方法的前提是原始和目标服务器可以互相通信，而且能够访问同一个文件共享库，或者它们位于同一台物理主机上。注意，如果整个初始订阅过程所需要的时间比分布式清理代码的当前保存期长，那么您可能要先停止分布式清理代理。

　　最后，如果是迁移一个非常老的SQL Server版本(例如，SQL Server 2000)，而且使用数据传输服务(DTS)，那么您可能还要迁移SQL Server整合服务(SSIS)。DTS已经停用很长时间，而SSIS的性能更好，启动更灵活。然而，DTS没有直接迁移路径，复制本身无法解决这个问题——您需要从微软建议的DTS至SSIS迁移方法中寻找解决方法。