March 4, 2009 at 7:06 am
I am still trying to finish the SQL 2000 migration to SQL 2005. I have read the comments that the SQL 2000 to SQL 2008 migration might be a better use of time than to stop at SQL 2005. In my situation I have decided not to do this and instead opt for getting teh SQL 2005 migration completed. I have 3 SQL 2000 server instances left to migrate.
It has taken time to remove deprecated features to get some of the older databases ready for the SQL 2005 upgrade. There are more changes that they will require before they can be moved to SQL 2008. Some of these databases have been upgraded since the SQL 4.x days(I inherited them after they were at SQL 6.5 or SQL 2000) and it seems every upgrade has required rework of some DB programming that was acceptable practice at some point that isn't anymore. From built in functions that start returning null (from SQL 7 to SQL 2000 migration) to deprecation of non ansi syntax for outer joins (*= and =*) to the next thing that I know of is the deprecation of User Aliases. Every upgrade isn't seamless and it seems that the people that wrote the applications that I am now tasked with upgrading chose to use every feature that has been deprecated.
Some of these older apps are being rewritten, but in the meantime you have to keep reworking to upgrade – and hope that on the rewrite you don’t choose to use syntax/features that in SQL 11 will be deprecated.
March 4, 2009 at 7:19 am
We are 100% on SQL Server 2005. We moved from 7 to 2005 to get the 64 bit version and far better memory management and user capacity with new hardware. We have 0 installs of any version of 2008 and I don't see any reason to do so anytime soon. If I built an additional SQL Server today, it would be 2005 64 bit on Windows 2003 64 bit. It just works.
Student of SQL and Golf, Master of Neither
March 4, 2009 at 7:30 am
I think a 24 - 36 month cycle is good, although my company tends to be late adopters. We're a pretty small shop and all of our servers are still on 2000. We tried to get 2008 in the budget for next fiscal year (May) but it got axed. If Microsoft does move to a shorter cycle, I would hope their pricing structure for SQL Server changes also, i.e., a little less expensive, so it's easier for us smaller guys to upgrade.
March 4, 2009 at 7:40 am
We're currently working on plans to finally retire our last SQL 2000 instance. The main database on it will no longer be necessary to the business by about mid-month, so that makes it a lot easier to plan and implement.
Not sure if there are any plans to move to 2008 or later at this time. Probably not for another couple of years anyway, with costs and such being cut as much as possible.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 4, 2009 at 8:01 am
We have just moved our development environment to 2008 and hope to move production to 2008 by July or August.
March 4, 2009 at 8:23 am
For internally supported code staying 1/2 or 1 release behind in production DBs makes the most sense to me.
IE, start working on conversion to the latest version once the first major patch kit has been released, with plans to implement it into production around the time the next major release comes out.
Since one definition of "pioneer" is "someone laying face down in the mud stuck full of arrows", I tend to avoid early adoption.
Unfortunately, a lot of us are stuck with externally developed code. Some of which is tied to obscenely outdated releases.
I think most ERP software vendors have a tendancy to stay a version or two behind, and when you add on their customer's tendancy to stay a version or two behind, it can get really outdated.
We are currently running on 2K, and by the time we convert to the next version of our ERP software (which runs on 2005) I suspect 2010 will be out...
March 4, 2009 at 8:39 am
bob.willsie (3/4/2009)
For internally supported code staying 1/2 or 1 release behind in production DBs makes the most sense to me.
Personally, I'm with Bob -- being behind is just fine.
We upgraded production to 2005 a couple years ago, and all new databases are in 2005... but we still have a few production environments on 2000.
We've been even slower with the "packages" -- we had problems making SSIS respect our firewall, so we're still developing in DTS, even on the 2005 machines. We know there's a way to solve that... but it's just not a hot issue.
Part of what slows us down is that we have applications that are live 24-7, and making money 24-7 (websites), and upgrades interrupt that. But these are choices between "great" and "greater", so our attention is more on things that make a difference, directly, with our business.
I like new toys, and we don't want to get too far behind, but it's "all in good time."
March 4, 2009 at 8:46 am
We have 15 production SQL 2000 and 5 SQL 2005. Quite honestly the new pace Microsoft is on is more about revenue than innovation I believe. SQL 2008 isn't much more functionality better than 2005. I cannot goto my boss and tell him SQL 2008 will save us any money or give us any more functionality for the over quarter of a million bucks it will cost to upgrade all of ours especially in this economy. We still have two SQL 2000 running on Sp3 because the vendor was behind the ball certifying SP4 and then our IT Dept has higher priorities than the big number of hours for application testing for a new release of software. Another two are running dead software that either the software company is out of business or we are moving to something else and won't upgrade it and will eventually turn it off.
For the most part unless we have a business need we will skip upgrading alot of ours to 2005 and go from 2000 to 2008. In the future I expect alot of companies will go into the skip a release as more and more SQL Server apps become 24 X 7 and IT Dept become more stressed for people and time.
March 4, 2009 at 9:08 am
We, too, are trying to wrap up the migration from SQL 2000 to SQL 2005. It's taken us a lot longer than previous migrations because of the big jump in functionality in the engine and SSIS. So, we're just starting to look at 2008. Budget is a whole other story.
Greg
March 4, 2009 at 9:38 am
We upgraded from 2000 to 2005 some time ago. The biggest problem with that upgrade was re-writing all the DTS packages into SSIS, and that truly was a nightmare. But that is done. All my databases are fully 2005.
I've looked at the depreciated features for 2008 and it doesn't seem like that big of a deal to me.
Assuming that the SSIS packages will work fine in 2008, I don't think we would have to make any application changes to work in 2008. The new T-SQL enhancements and some of the other things I have read about make 2008 look very attractive. I remember how much my code improved when we got the new T-SQL enhancements for 2005. It was GREAT. So, while I don't control the budget, it is my hope that we will upgrade to 2008 soon.
Question: Does anyone have any experience with in-place upgrading? My co-worker is insisting that if we want to upgrade, we have to buy a new server and "move-over". Our current server meets our needs completely and should be able to run 2008 just fine. My co-workers only concern is what we would do if the in-place upgrade went wrong. We do have an old test server to play with doing an in-place upgrade. Have you tried in-place upgrading, especially from 2005 to 2008? If so, how did it go? Thanks!
March 4, 2009 at 10:07 am
My dilemma is new projects. Our shop is 3 servers all on 2005, and they work fine, with no reason to upgrade. Size and load are not an issue, and we are not using any fancy features that might benefit from the latest performance improvements or GUI enhancements.
On the other hand, we are about to embark on a complete re-write of our customer service/billing/sales system that is coming up on 9 years old. I know the next version will have a similar life span. I should write this to last as long as possible. Which means VS2008 and SQL Server 2008, but I haven't learned .net yet, and classes are only offered for VS2005/SQL2005.
I think it comes down to, I don't want to bleed that much.
We'll be 2005 for awhile.
March 4, 2009 at 11:15 am
"The means each of us needs more skills, which means work learning about new features and practicing with them. But it also means that investments you make today, learning about 2005 or 2008, will likely continue to pay off for some time in the future."
Some of the best investing advice I ever read was that your very best investment is always one you make in yourself - as in education, training, developing new skills, etc. And in this economic climate, that advice holds more true than ever.
March 4, 2009 at 12:38 pm
Getting down to "brass tacks" ...
- 200+ servers and/or instances thereabouts
- roughly 50/50 SQL 2000 & SQL 2005
- no plans at all for 2008
- why, licensing is too, too much
- testing, testing testing of applications
- we are waiting for SQl 2010
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
March 4, 2009 at 1:50 pm
The shop I am working in right now has a completely mixed environment with several large apps running on SQL Server 2000, one on 2005, one being upgraded from 2000 to 2005, one being upgraded from 2000 to 2008 and new development going on in all three. I'll tell you one thing, it has been a blessing from the standpoint of my own flexibility and understanding of the versions! Plus I get to plonk a year of 2008 on my resume; bonus.
Re: question all our upgrades have been in side by side environments moving individual databases via backup/restore, so I can't address the inplace upgrade, but the only issue we have had is with the .net scripts in SSIS packages having to be rewritten. If anybody has an easy workaround for that I'd be happy to hear it.
😎 Kate The Great :w00t:
If you don't have time to do it right the first time, where will you find time to do it again?
March 4, 2009 at 2:52 pm
Hi,
In our shop I've installed a CTP of 2008 on a VM for test, in production we have only 2000 and 2005, almost finished migrating the majority of systems to SQL 2005, wil probably be there Q3 2009. But we still have 2 vendor delivered prod system on 6.5, as well as a single in house developed system live on 7.0, crazy I know but my management won't pay for the effort of moving it.
//SUN
Viewing 15 posts - 16 through 30 (of 41 total)
You must be logged in to reply to this topic. Login to reply