Upgrade SQL Server 2000 to 2008 R2 with replication

I have been looking into this project for a side-by-side upgrade solution. The most widely suggested/used solut开发者_C百科ion is to do a full back of SQL Server 2000 database and restore on SQL Server 2008 with norecovery. Then restore the subsequent transaction log backups with norecovery. When we are ready to switch, change SQL Server 2000 to read-only mode, backup the tail-log and restore it on SQL Server 2008 with recovery. Then bring SQL Server 2008 online.

But, can't the upgrade be done with transactional replication where SQL Server 2000 is the publisher and SQL Server 2008 is the subscriber. Script all objects such as logins, indexes, etc and apply to SQL Server 2008. When we are ready to switch, we will stop replication, delete all replication jobs, and switch all apps to connect to SQL Server 2008. I haven't found anyone that suggests this method. Is there anything wrong with it?

---

The method of data migration you describe is possible to perform using SQL Server Replication.

There is nothing wrong with this method or any other data migration method for that matter, so long as the choice you decide upon addresses the specific requirements of your project/application platform.

That said the method you describe is certainly more technically involved in both the configuration and implementation of the actual migration steps. If you can accept downtime, a simple backup and restore process is certainly going to be much more straight forward. Log shipping would also be another simpler migration method.

So far, you know that the replication method could work in theory. Now is the time to build out a working solution in test in order to validate your data migration strategy and to practice the implementation process.

---

If you aren't replicating otherwise, creating a replication subscription will change your schema and a few settings. For example, you may end up with GUIDs generated for all your rows just to facilitate the replication.

---

Caution - transactional replication will turn off all IDENTITY columns at the subscriber (the transactional replication SPs actually depend on this fact, as they insert into the IDENTITY columns without first specifying IDENTITY_INSERT ON). I can only confirm this is the case when the subscriber is SQL 2000 as well - perhaps the subscriber on 2008 will behave differently.

For this reason, transactional replication with SQL 2K doesn't really give you a hot standby. We had to do a fair bit of SQL tweaking (re-instating the IDENTITY columns & re-writing the replication SPs with IDENTITY_INSERT wrappers) to get ourselves a situation where the subscriber actually works as a hot standby, ready to have applications pointed at it. But it certainly wouldn't work out of the box =)

---

Yes, it will work, provided that you transfer the other objects over.