Migrating 2000 Cluster to 2005

  • Had a question for others out there that have migrated from 2000 clusters to 2005. We are looking at migrating a 4 node and 5 node cluster from SQL Server 2000 to SQL Server 2005 - 7 Instances of SQL Server all together. (The applications that hit the databases are mostly asp applications.) Does 4-6 months seem like a reasonable time frame for application testing, making changes and testing failovers?

    I would be curious to hear other experiences and if our timeframe seems to long or short?

  • Off the top of my head, I'd suggest something like this:

    1) Build a two-node cluster, install one, maybe two instances of SQL on it (depends on what you've got in Production), and mess around with basic database-only upgrade processes. This would be your first stab at the migration process, so focus only on upgrading the database-specific stuff (DBs, jobs, security, linked servers?). Time-consumption wise, much depends on how long it takes to build (and rebuild for subsequent runs) the base system, how complex (number of databases, jobs, DTS packages, maintenance plans, ???) your systems are, and what percent of your time you can address this with. One, two weeks solid effort? Estimate, add a few weeks for slippage and experimentation. This is your 1.0, your basic training, the one you'll throw away... the one where you learn what's going on. Do not factor in application testing just yet--deal with one upgrade problem set at a time.

    2) When your comfortable with the basic database cluster upgrade process, build an N-node cluster as close as reasonable to your most complex Production system--and after (1) above, you'll have a better sense of what your problem areas will be. Take everything you learned in (1) and "extend" it here. I would suspect that this will be fairly simple; while I've only done two-node upgrades, I doubt an N-node upgrade would be significantly more complex [but others with experience might correct me!]. Depending on (re)build times, this should take as much or less time than (1), since you're now experienced.

    3) With a full and acceptable Upgrade test system, you could start testing your applications against it (which, given your starting parameters, you probably couldn't do with only a 2-node system). Maybe you do this at the same time as (2), maybe you do it once you're happy with upgrading a "full" system, your call. Configure your apps to work against the test system before upgrade, then upgrade the databases, then see what breaks in the app and fix it. (Much easier said than done, of course.) This, too, is a new learning curve, and everything depends on how complex, robust, and well-knoen (documented?) the code base is, how skilled/organized the developers are... no way to estimate that over the web. Let these (and other [political?]) factors drive this part of your planning and estimates.

    I guess my main conclusion is: build a simple upgrade enviroment and work out the basics of what you'll need to do. This could take only a week or two, depending on your resources. Once you've gone through this, you should have a much better idea of how long it will take you (your company/group that is) to do a full upgrade on your system.

    Philip

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply