Re: Migrating from SBS 2000 to SBS 2003 onto new hardware

Thanks SG!

And thanks also to the other folks who gave comments.

There were two things really important points I wanted to add that I didn't
find got emphasis in the other posts, though I think it's in the snip that
SG included.

1. The time to do a Swing Migration project is best considered to be closer
to 12-15 hrs to be realistic, though I do realize as Mark mentioned you can
frequently cut that time down with both good preparation and familiarity on
how to accomplish more than one task without getting out of the timeline.

2. I know it could look suspicious that a bunch of MVPs point you to a site
operated by an MVP and you wonder if this is odd. I hope you take a moment
to varify the suggestion to confirm it for yourself. If you want to get a
tour of the process in a webcast, you will find it here:

TS2 Wed on the Web: Platform Upgrading, Migrating,Transitioning Strategies &
Techniques
http://www.msreadiness.com/WS_abstract.asp?eid=15003706

Description:
In today's Wednesday on the Web with TS2, we will be exploring the different
methods for moving and upgrading to SBS 2003 from other existing scenarios.
Additionally, we will also be exploring the upgrade and "transition" path
from SBS 2003 to the full server platform. This seminar should provide an
overall upgrade path that will help guide your small business customers in
the right direction. Join the TS2 Team along with Jeff Middleton (SBS MVP)
and Guy Hay*** (Microsoft Senior Product Manager) as we discuss these
strategies and techniques.

I encourage anyone with that concern to go look in google to find
independent comments on Swing Migration, or if you like, you can go reach
out to an even larger circle of local community groups to not only ask about
Swing Migration, but also anything else you want to know. I have a list of
groups posted on my website because they provide even more forums including
local meetings around the world that help propell the best practices and
experiences forward. Take a look:

http://www.sbsmigration.com/it-pro-community.php

In addition, I want to invite anyone interested in worldwide discussion of
SBS in a live chat to come visit the monthly SBS Chat every 3rd Tuesday of
the month. This is the longest running chat on the planet, hosted by
HandyAndy Goodman...yet another SBS MVP, who takes time every month to
anchor a discussion where you pick the topic and the answers roll in from
everyone online instantly!

http://chat.sbsmigration.com/SBSchat/

- Jeff Middleton SBS-MVP
YCST@xxxxxxxxxxxxxxxx



"SuperGumby [SBS MVP]" <not@xxxxxxxxxxx> wrote in message
news:uozx60NvGHA.3264@xxxxxxxxxxxxxxxxxxxxxxx
I hope Jeff doesn't mind me quoting something he recently posted. Keep in
mind this is in reply to another thread where all manner of discussion has
occured and parts are sorttta out of context. I found Jeff's
explanation/insight to be interesting.

---------Jeff-------
I wanted to jump in to comment about the recommendations you are receiving
to your request. SBSmigration.com is my website, the documentation being
discussed is my product, and the unique aspect of this conversation as I
read it is that I see you could conceivably feel like you are being pushed
in a direction you aren't interested in going. Therefore, I want to offer
some additional detail to what has already been posted.

First, you posted a request for Swing Migration, but perhaps you didn't
know
that this is a term than had no meaning relative to SBS deployments and
replacement until 2 yrs ago when it became de facto a moniker for the
process that I fully documented for the first time. Up to that time,
Microsoft offered nothing like this in the form of documentation, nor
would
they then or will they now provide you support in doing a "Swing
Migration".

You could gain a little perspective on this topic if you simply go to
Google
and search for SBS Migration and Jeff Middleton as author. You will find
that I have been talking about this process in the public newsgroups going
back 5 yrs. I have been pushing MS to embrace this idea for that long, and
always without success. You might note that I became an MVP in 1999
primarily because of the time I spent posting answers to questions in the
newsgroups on many topics, not the least of which was migration and DR
strategies.

When MS released SBS 2003, they documented the following migration
methodologies:

In-Place Upgrade
Clean Install/OEM Install (related concepts)
ADMT Migration

After reviewing how that worked and the impact of it, I decided that I
would
write a whitepaper on how to do an SBS migration by a different and more
sensible manner, what is now well known as Swing Migration. I accumulated
my
own experience, combined it with authoritative KB references from my
research and sent it to MS for technical review, comment, and the request
that they publish it _for free_ as an MVP whitepaper. After they reviewed
it, they commented back to me favorably about the concept and thanked me
but
declined to publish it. The reasoning in a very short summary is that they
did not want to support the process I had outlined, even though that was
not
a comment about the viability of the process. In fact, in general, if you
ask someone knowledgeable within MS about the process they will likely
tell
you it's a pretty cool concept, and pretty neat that I actually included
reference to all the MS Kbs I researched to document the process. In other
words, they thought it was neat that I could frame the concept based upon
a
wide range of documents that have nothing to do with SBS, nothing to do
with
domain migration, Exchange migration, websites, etc....and yet build a
cohesive strategy document that is repeatable for people worldwide with
the
widest variety of systems and situations.

The curious point is that like any project of this scale, sometimes things
don't go right, and sometimes things are in bad condition before you even
get started. Therefore, part of the logic of MS in their decision not to
support publishing a completed documentation outline is that they already
had documented how they would encourage folks to approach this topic.

So at this point, I next took the manuscript to a friend who is a book
publisher, and the original draft of the process was published in a book
with 15 chapters, including two that I wrote. One is on Disaster Recovery,
the other is on Swing Migration. That is where the name came into
existance,
when I called it that and explained it that way.

Mind you, many people who are sharp and studious have developed a lot of
the
same concepts in their own trial and error testing over the years, but
I've
yet to find anyone who found that to be trivial. I also haven't met anyone
who compiled it into a unified, start to finish, all referenced project
guide like I have. I'm not saying I invented something nobody else could
think of, but I did try to put it into common use by writing original
methodology and combining it with well defined tasks outlined by MS KBs to
encourage people to have trust in the work.

So having added my two chapters to the work of 13 other people, if you can
justify $45 at Amazon, you can have a good book, an original draft of the
process, and my best regards. It's not like I didn't realize that I was
making that information available for a pretty cheap prices. In fact,
here's
a real kick: I don't make a dime if you buy the book. But it's out there
for
you, and most people can afford a book if they really appreciate that it
could be useful to them.

Books available from SMB Nation Press - Learn more from SMB Nation Press
"Microsoft Small Business Server 2003 Advanced Best Practices"


The next thing I did was to recognize that Swing Migration is a process
that
is far more complex than most people realize. Why? Because it covers a lot
of ground, and it deals with not only building a new server, it
potentially
deals with left over issues from the old server and domain. Having already
submitted the draft to the book publisher, I was suddently overrun by
requests from people who wanted me to provide support for this
concept...in
case they had problems. So now I'm facing the problem of having done all
this original research, documented a process that isn't supported by MS,
and
now I'm supposed to support it. Now I ask you, should I do that for free?
There's a point at which I have to eat and pay my own bills, and it's not
like I'm trying to be unfair.

You can go to my website and see right there a step outline of what we are
talking about:


http://www.sbsmigration.com/migration-projects.php#what-is-a-swing-migration

You can see a complete outline of many aspects of what it can and can't
do,
and you will not find that information anywhere on the MS website....all
of
that is what I introduced to explain why this can work.

In order to give people confidence in this process, and to assure them
that
I'm totally serious about giving the best support I can, I created a
website
to allow people to order the Kit and pay for a lifetime license to use the
materials including the custom script tools I have written. You buy it one
time, and you are personally licensed to use this forever on as many
servers, domains, customers and projects that you want. I expect you will
bill for that. I expect you will make a lot of money from using this
process
because it is ridiculously better than what MS is offering you as a
process.
I provide with the purchase of the $200 Technician Kit a 90 day period
during which you can obtain unlimited tech support toward completion of
your
first project by email. That's direct support, unique to your project, and
I
don't constrain the scope of that to "one SBS to one SBS". In fact, I have
provided support to people with a couple of Exchange Servers, and as many
as
5-6 DCs. I've assisted people moving entire business operations to another
location where a swing of new servers was involved, and I didn't change
them
anything above the cost of the $200 Kit because I nevers saw questions
from
them that seemed to me to be outside the scope of replacing one or more
servers in exactly the manner and outline that I had already covered in my
documentation.

I want to make sure you understand that my scope of project support is
that
if I've covered in my documentation, I'm supporting to the best of my
ability when you contact me. You might want to double-check your
impression
of what MS provides as support when you pay them $245 for a support
incident
call. They cover one ISSUE, not the PROJECT. There's a pretty big
difference
there.

The vast majority of people who value their time realize that once they
look
at the Migration Projects page on my website, and do the math, they will
find that they probably save as much time on the first project and as much
headache for their customers that the Kit pays for itself before you
finish
that job. From there, it's just more income for you to keep on earning and
skill for you to keep developing from your experience.

I am not offended if anyone decides that it's not worth $200 to have
unlimited tech support for presales, project planning, and full transition
to a new server deployment that works transparently at this level. If that
seems not to be worth it to you, I encourage you to go take a glance at
the
book instead.

The reason you will find so many people endorsing the use of this process
is
because it works, I support it, I continue to improve it, and it's a good
value for you, your customer and even for MS that I'm helping people learn
their way through the first job they take. Some people come back and
subscribe to obtain all of the scenario documentation I've written and am
continuing to update. Many people will never use the MS documented
approaches again.

Rather than just taking the word of a couple of people on this list, MVPs
or
not, go search google for sbsmigration.com, or even "sbs migration" and
see
if you don't find a lot of honest endorsements for this all over.

The Technician Kit includes the 200 pgs of documentation discussed on the
website, plus an additional 200 pages of reference information specific to
this type of project. it's intended to provide the only references you
need.
I hope I will have a chance to help you learn this process so that you can
spend your time billing customers for the skill you will have learned,
rather than spending time trying to research what is already
authoritatively
demonstrated by people using my documentation to be a great solution to
use.
Supporting people who want to learn Swing Migration is pretty much my full
time job, and I enjoy the opportunity it has afforded me to make a lot of
people happy and more successful in their business. I really am offering
an
alternative to MS methodology, and I put my time and reputation behind
what
I do.

- Jeff Middleton SBS-MVP

YCST@xxxxxxxxxxxxxxxx




"Rick" <txgeek4@xxxxxxxxx> wrote in message
news:1155255586.967639.120390@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1st
I have a client with a SBS 2000 Dell server and 18 clients. They are
using it for exchange, file server, print server and application
server. I am working up a quote for them on replacing the server with
new hardware and while we are at it migrating up to SBS 2003. I've
found a 50 page white paper on this migration from Microsoft and it
looks to be pretty labor intensive to perform this migration. I'd like

to be able to estimate my time to do it this way, but do not want to
get in a situation that I end up going way over. I understand that
every situation is different, but I wanted to get an idea from others.
http://www.microsoft.com/technet/prodtechnol/sbs/2003/deploy/sbs2k203...


Has anyone done one of these the MS way and how long did it take you?


2nd
I found this site SBS Migration and it talks about doing this via Swing

It!. Does anyone have experience going this route? Their site makes
it sound like this will be a 2-3 hour job and everything will be just
peachy. What's the scoop on this? http://www.sbsmigration.com/


3rd
What is the best practice for doing this type of migration? Where do I

find a write up on it?


Thanks In Advance
Rick





.