Thursday, January 24, 2008

Perfect Network Migration

I've mentioned several times in recent months, on web casts, in seminars, etc., that KPEnterprises has a Perfect Migration procedure.

We promise clients migrating to new hardware
- Zero compnay-wide downtime (email, databases, shared folders)
and
- less than one hour of downtime per desktop.


I generally get one of three responses to this:

1) Really? How do you do that?

2) Oh yeah. We do that.

3) Wow. That's very cool.

#1 is the most honest. They believe me and want me to give away our secrets.

#2 is bullshit. This is always someone who, conversation reveals, formats his hard drive once a year to fix all his problems.

#3 is generally someone who is working to achieve the same goal, or who has achieved the same goal. I know this because they want to engage in a detailed discussion, and we end up trading information about our current approaches.

There may be more than one way to execute the perfect network migration. But there are a few key elements that are central to the goal.

First, you have to be committed to the process.
You have to believe that you can have a perfect, zero downtime migration.

Second, you have to understand every function within the domain.
In other words, you need to break the job into it's pieces. How will you transition users and permissions? How will you transition domain control? How will you transition email? How will you transition data access?

Third, you have to be detail oriented.
Not only do you need to list every single action you will take in the process, you need to put them in the right order and execute in order.

As I mention in the Super-Good Project Planner for Technical Consultants, most consultants don't plan their work. They just jump in. And that may be fine for a small task such as reinstalling Office.

But on a network migration, you better be a lot more organized.

Or simply charge time and materials, because you'll do quite a bit of backtracking, rework, and inefficient work because you don't have Standard Operating Procedures and a process for success.

In my Relax Focus Succeed seminars, I sometimes ask who wants to be rich. Almost everyone raises their hand. Then I ask how many have formulated a plan of any kind to become rich. Almost no one raises their hand.

Network migration isn't much different.

How are you going to get there if you don't plan to get there? How will you get there if you don't make it a goal, create a list of things to do, and start working through it? Will a perfect network migration simply "happen" one day? No.

You can get started with your very next server install. Write down everything. Break chores into distinct pieces and document each.

Don't just DO the project: Do it carefully and write down everything you did. Make notes about what to do differently.

And the best time to start is . . . now.

That way, you'll have something under development as Cougar rolls into play.

4 comments:

  1. Anonymous7:49 AM

    "- Zero compnay-wide downtime (email, databases, shared folders)
    and"

    Perfect like that?

    ReplyDelete
  2. Anonymous11:51 PM

    What does Zero Company-Wide downtime mean?

    When exchange server is taken down during the coping of the exchange database during the server migration, how is this downtime accounted for?

    ReplyDelete
  3. You make an assumption about procedures that is incorrect.

    We set up the new Smal Biz Server next to the old. At 4:59PM we move the MX records to point to the new address.

    By the time the sun comes up, all the new mail is going to the new exchange server.

    Users are instructed that they will access the old email via OWA on one system and new email via OWA on the other system until we can get to their desktops.

    Zero emails dropped.

    Once an individual user is moved over, they only access the new system.

    No email is ever bounced, or even delayed. It simply stops being delivered to the old server and starts being delivered to the new server.

    If you use exchange defender, or a similar service, you simply redirect E.D. to the new address and let clients use live archive to see all email during the transition.

    There are other options as well.

    The key point is: You have to start with a goal of zero downtime. Then figure out how to do it.

    ReplyDelete
  4. How about the SBS Swing migration?

    http://www.sbsmigration.com

    Anyone tried it?

    -m

    ReplyDelete

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!