What is the best way to upgrade/migrate to SQL Server 2005 (including
Reporting service)?
1. Upgrade in place
2. Set up another box for SQL 2005 and migrate
3. Set up another instance of SQL 2005 on the same box and migrate
Thanks in advance for sharing your experience/suggestion on this.

My preference is #2, a clean install, and transfer the databases and server
settings.

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

You can't someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf


"HenryT" <HenryT@discussions.microsoft.com> wrote in message
news:AFFEB59E-8CE9-44DB-92F7-3B97F3351610@microsoft.com...
> What is the best way to upgrade/migrate to SQL Server 2005 (including
> Reporting service)?
> 1. Upgrade in place
> 2. Set up another box for SQL 2005 and migrate
> 3. Set up another instance of SQL 2005 on the same box and migrate
> Thanks in advance for sharing your experience/suggestion on this.

Thank you for a quick answer!

"Arnie Rowland" wrote:

> My preference is #2, a clean install, and transfer the databases and server
> settings.
>
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
>
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> You can't someone get up a hill without getting a little closer to the
> top yourself.
> - H. Norman Schwarzkopf
>
>
> "HenryT" <HenryT@discussions.microsoft.com> wrote in message
> news:AFFEB59E-8CE9-44DB-92F7-3B97F3351610@microsoft.com...
> > What is the best way to upgrade/migrate to SQL Server 2005 (including
> > Reporting service)?
> > 1. Upgrade in place
> > 2. Set up another box for SQL 2005 and migrate
> > 3. Set up another instance of SQL 2005 on the same box and migrate
> > Thanks in advance for sharing your experience/suggestion on this.
>
>
>

And if option 2 is not available?

Regards,
Hank Arnold

Arnie Rowland wrote:
> My preference is #2, a clean install, and transfer the databases and server
> settings.
>

If resources allow (and server/instance naming won't present problems), I
would then select option #3, and remove the original product when the
migration and testing is complete.

However, there is nothing 'wrong' with an 'inplace' upgrade.

My preference is separation to allow for testing and 'easy' rollback if
problems are discovered.

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

You can't someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf


"Hank Arnold" <rasilon@aol.com> wrote in message
news:O2YUN4l$GHA.1224@TK2MSFTNGP04.phx.gbl...
> And if option 2 is not available?
>
> Regards,
> Hank Arnold
>
> Arnie Rowland wrote:
>> My preference is #2, a clean install, and transfer the databases and
>> server settings.
>>

Even there is nothing wrong with option one, would it pose the highest risk
(compare to the other two options) in term of down time during upgrade and
fall back if something goes wrong? Are the following true with upgrade
inplace?
- all databases will be migrated to SQL2005 at the same time.
- all applications using these databases have to be tested, modified as
needed, and certified to work before upgrade.
- all issues with incompatability (stored proc, DTS, Replications, scheduled
jobs, etc) have to be resolved before upgrading.
- fall back will include un-install of SQL2005 and reinstall of SQL2000

Is there anyone out there with good (or bad) experience with "upgrade
in-place" who can share the experience and lesson learned?

Is it a good idea to set databases to SQL2000 compatabilty when applications
can not be tested and certified before SQL2005 upgrade? Will there be
problems with old stored proc, triggers, and security settings?

Thanks in advance!


"Arnie Rowland" wrote:

> If resources allow (and server/instance naming won't present problems), I
> would then select option #3, and remove the original product when the
> migration and testing is complete.
>
> However, there is nothing 'wrong' with an 'inplace' upgrade.
>
> My preference is separation to allow for testing and 'easy' rollback if
> problems are discovered.
>
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
>
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> You can't someone get up a hill without getting a little closer to the
> top yourself.
> - H. Norman Schwarzkopf
>
>
> "Hank Arnold" <rasilon@aol.com> wrote in message
> news:O2YUN4l$GHA.1224@TK2MSFTNGP04.phx.gbl...
> > And if option 2 is not available?
> >
> > Regards,
> > Hank Arnold
> >
> > Arnie Rowland wrote:
> >> My preference is #2, a clean install, and transfer the databases and
> >> server settings.
> >>
>
>
>

You will most likely want to use the 'Upgrade Advisor' before the upgrade in
order to discover any primary issues that will have to be resolved (of
course it doesn't find everything)

SQL Server 2005 Upgrade Advisor
http://www.microsoft.com/downloads/d...displaylang=en

SQL Server 2005 Upgrade Technical Reference Guide
http://www.microsoft.com/downloads/d...displaylang=en

SQL Server 2005 Upgrade Lessons Learned
http://rentacoder.com/CS/blogs/real_...04/28/477.aspx

Other comments inline...

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

You can't someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf


"HenryT" <HenryT@discussions.microsoft.com> wrote in message
newsDC8A4D9-1FDB-4057-825A-211C6B905298@microsoft.com...
> Even there is nothing wrong with option one, would it pose the highest
> risk
> (compare to the other two options) in term of down time during upgrade and
> fall back if something goes wrong? Are the following true with upgrade
> inplace?
> - all databases will be migrated to SQL2005 at the same time.

Yes

> - all applications using these databases have to be tested, modified as
> needed, and certified to work before upgrade.

Are you kidding, who does that? Joking aside, SQL Server doesn't require
that, but hopefully your operations practices will dictate it.

> - all issues with incompatability (stored proc, DTS, Replications,
> scheduled
> jobs, etc) have to be resolved before upgrading.

It would be nice, but I always expect some 'gotchas'.

> - fall back will include un-install of SQL2005 and reinstall of SQL2000

I haven't had to test an uninstall fall-back on a production server, and I
don't want to have to experience it.

>
> Is there anyone out there with good (or bad) experience with "upgrade
> in-place" who can share the experience and lesson learned?
>
> Is it a good idea to set databases to SQL2000 compatabilty when
> applications
> can not be tested and certified before SQL2005 upgrade?

SQL 2000 compatibility is only needed if there are some applications that
are not SQL 2005 compatible.

> Will there be
> problems with old stored proc, triggers, and security settings?

Hopefully, the Upgrade Advisor will point out most of the problems that have
to be corrected.

>
> Thanks in advance!
>
>
> "Arnie Rowland" wrote:
>
>> If resources allow (and server/instance naming won't present problems), I
>> would then select option #3, and remove the original product when the
>> migration and testing is complete.
>>
>> However, there is nothing 'wrong' with an 'inplace' upgrade.
>>
>> My preference is separation to allow for testing and 'easy' rollback if
>> problems are discovered.
>>
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>>
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>> You can't someone get up a hill without getting a little closer to
>> the
>> top yourself.
>> - H. Norman Schwarzkopf
>>
>>
>> "Hank Arnold" <rasilon@aol.com> wrote in message
>> news:O2YUN4l$GHA.1224@TK2MSFTNGP04.phx.gbl...
>> > And if option 2 is not available?
>> >
>> > Regards,
>> > Hank Arnold
>> >
>> > Arnie Rowland wrote:
>> >> My preference is #2, a clean install, and transfer the databases and
>> >> server settings.
>> >>
>>
>>
>>