October 21, 2011 at 8:19 am
1 server with 2000
3 servers with 2000 & 2005
2 with 2005 (public facing, soon to be 2008 R2)
1 TFS server (which requires 2008) has 2008 R2
We've skipped 2008 entirely as an organization in favor of R2.
Most of my db's are in SQL Svr 2000, some with ugly DTS packages.
Hats off to my (former) manager who (in 2007) let me talk him into requiring that all new dev happen on SQL 2005 and VS 2010.
Not proud of it, but you asked and it is what it is.
October 21, 2011 at 8:24 am
Phil Warren (10/21/2011)
The DTS packages are the biggest reason, we haven't migrated off of SQL 2000 sooner.
Dont let DTS stop you from migrating/updating to 2005. DTS works fine in 2005. We migrated all of our 2000 databases to 2005 instances two years ago, using the current DTS packages. Have slowly begun to replace DTS packages with SSIS, mainly when a DTS package needed to be changed anyways. Still have 19 DTS running successfully.
Need to install 2005 Backward Compatability. Also, a neat tool that easily copies a DTS package from 2000 to 2005 (or 2005 to 2005 for that matter) is called "DTSBackup 2000" which can be downloaded for free.
October 21, 2011 at 8:26 am
Mauro-244882 (10/21/2011)
... And we also have 1 running sql server 7.... but that is the most reliable one! Slow but reliable 🙂
I'd think if you have any 6.5 or 7 servers still running, they'd have to be stable by now. Or you'd have upgraded them.
October 21, 2011 at 8:31 am
I'm in Tech support, so I have to work with a variety of versions: we have customers on SQL2000, SQL2005, SQL 2008 + SQL 2008 R2 (and all patch levels in between! Wheeeee).
One of our biggest challenges is determining whether the issues the customer is having is due to them being on a different patch level or whether it actually is the code. Always and adventure for me.
October 21, 2011 at 8:40 am
We have a couple SS2005 to accommodate third-party apps that require it. Otherwise, we upgraded everything from SS2000 to SS2008 about two years ago. At that time, we installed the optional components that provide backward compatibility for DTS packages (management, run-time, and design-time support.) Naturally, we assumed this would be an interim solution until we rewrote the hundreds of legacy DTS packages in SSIS.
Reality: Fast-forward two years to the current day and we have converted virtually none of the DTS packages to SSIS due to more urgent priorities. I know DTS is deprecated and our situation is not advisable, but, in fact, we are running and maintaining the DTS packages rather effortlessly. In the meantime, we use SSIS for everything new and have achieved competency in that tool as well.
I'm not recommending this approach but I'm curious how many others find themselves in this situation? It seems much more common for people to consider themselves 'stuck' with SS2000 until they convert their numerous DTS packages to SSIS.
(While I was composing this comment, I see someone chimed in about using SS2005 Backward Compatibility features for DTS support.)
October 21, 2011 at 8:41 am
Jo Pattyn (10/21/2011)
SQL2000 SP4 (till the hardware breaks, no DTS), SQL2005 & SQL2008 (not yet R2). All standard or express editions. Next to Oracle 9 and 10.
There's always VMs for this. It's a great way to continue to support older Windows and SQL versions. Even can do a physical to virtual migration, no reinstalls needed.
October 21, 2011 at 9:00 am
Sql Server 2005 and Sql Server 2008 and all sub-versions (SP1, SP2, R2 etc...)
October 21, 2011 at 9:00 am
Just a few months ago, we have replaced our CRM and submission|command system that was 12 years old and a homegrown web asp application. That has made us move 1: 6.5, 1: 7.0, 2: 2000 and 1: 2005 to a singal instance of 2008SR2. The 6.5 was kept because we had tasks (actions) that were encrypted and we were unable to move these actions.
Now we have only one platform on one server, much more easy to maintain, and we can spend more time with users and communicate with them. (And telecommute... shhh! don't tell that to my boss, he his not very fond of it.)
October 21, 2011 at 9:02 am
Hello,
We've got around 20 servers, now all in SQL Server 2008 R2 SP1 CU2 (I have just finished the migration project :-)), three years ago we have migrated all servers from SQL Server 2000 to SQL Server 2005 (that was a bit painful, migration from 2005 to 2008 R2 was quite easy, and there were only little problems with old/incompatible apps).
Regards
Slawomir Swietoniowski, MCITP:DBA+Developer (2005/2008)
October 21, 2011 at 9:05 am
john.barry-1031177 (10/21/2011)[hrDont let DTS stop you from migrating/updating to 2005. DTS works fine in 2005. We migrated all of our 2000 databases to 2005 instances two years ago, using the current DTS packages. Have slowly begun to replace DTS packages with SSIS, mainly when a DTS package needed to be changed anyways. Still have 19 DTS running successfully.
That was our strategy too. We've used SSIS for new projects and converted DTS to SSIS as time allowed. We still have a few DTS packages running in production jobs.
As for versions, we have one production SQL 2000 instance that will be migrated by the end of the year. Most of our instances are SQL 2005, with a few SQL 2008 instances that were installed to take advantage of specific features. We plan to skip R2 in favor of migrating all to SQL 2012 as budgets allow.
Greg
October 21, 2011 at 9:12 am
>DTS works fine in 2005
That concept works fine. But ... DTS packages on Win2K using 32-bit ODBC drivers against an AS/400 will not easily migrate to a 64-bit Win08 machine. What I did get to work ran 2-3 times slower.
There are still 200+ such DTS packages at my old job. So glad I switched jobs to a company where everything is SQL 2008 R2! Best thing ever in my rear-view mirror was SQL 2000 and an IT department that would not budget to stay current.
October 21, 2011 at 9:15 am
Greg Charles (10/21/2011)
john.barry-1031177 (10/21/2011)[hrDont let DTS stop you from migrating/updating to 2005. DTS works fine in 2005. We migrated all of our 2000 databases to 2005 instances two years ago, using the current DTS packages. Have slowly begun to replace DTS packages with SSIS, mainly when a DTS package needed to be changed anyways. Still have 19 DTS running successfully.
That was our strategy too. We've used SSIS for new projects and converted DTS to SSIS as time allowed. We still have a few DTS packages running in production jobs.
Same here. Of course we still have several hundred DTS packages to deal with.
We have about 10 2000 instances, although that may go down rather drastically soon since my manager just sent out an email detailing the cost for keeping them over the next few years (can you say OUCH!).
We have maybe 50 2005 instances, and somewhere around 5-10 2008 with just a couple of R2 instances.
You would be amazed (or maybe not) how hard it is to convince a group of 10-15 managers that now really is a good time to upgrade their DB server.
Everyone pray for me as 2012 comes out, because I foresee in the next year or so having to support 5 different versions of SQL.
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
October 21, 2011 at 9:15 am
We have 1x6.5, and probably 10x2008 with a few 2005's thrown in for good measure. The 6.5 instance runs our manufacturing plant.
October 21, 2011 at 9:34 am
I have 6 production SQL2000 database servers. Why don't upgrade these old buddies? The reason is very simple --- The upgrade cost is very high.
The upgrade cost include:
1. SQL servers purchasing
2. Time to rewrite and test all software developed for them
3. The risk to take if something goes wrong when upgrade the SQL servers.
Especially (3), I can't affort any problem as upgrade a SQL server, and later then I need to rollback everything, since I have more than a hundred databases holding per each server instance.
October 21, 2011 at 9:40 am
Across our entire production infrastructure we have 22 SQL 2000 servers, 44 SQL 2005 servers, 32 SQL 2008 servers, and 1 recently discovered SQL 7 server.
Most of the SQL 2000 servers support key card applications or old web sites. The SQL 7 instance is used by the software for an old piece of lab equipment.
By the end of the year we will have converted most of the 2005 servers to 2008. We are just hoping the 2000 servers just die. And then, by the end of next year, 2012 baby!
Viewing 15 posts - 46 through 60 (of 78 total)
You must be logged in to reply to this topic. Login to reply