primarily doing POP/SMTP. After needs assessment for new email/groupware, I
did a comparison of what was out there. Having worked with Exchange, Google,
Kerio, FirstClass, Lotus Notes, postfix/dovecot in the past and pricing for
what functionality we needed, Kerio was an easy choice.
We are not doing a huge migration, but rather moving people over as we can.
We are moving people off pop/smtp to IMAPS. We have all mail routing to the
new email server, but if an internal address is not found there (i.e. The
user has not yet been migrated) then it redirects over to the legacy
sendmail/dovecot server). We have .forwards at the linux level there for
users who have been brought over so no one knows/feels the background
straddling. Many like to use a simple email client so we keep them on that
(Mail.app for example) but many also want the groupware functionality
(calendar, contacts, shared resources) so we go Outlook or Entourage for
them. We also have Blackberry users, Palm and iPhone users. Kerio's
ActiveSync is nice for iPhone and Palm users with over the it syncs.
I went down this approach to limit the trauma of a massive one-time
migration and drama or user-generated drama. As far as user email, we
brought over everything they had since we want to make their new email setup
valuable and desirable to use. Also, there was a lot of issues with POP/SMTP
in the past pulling emails off the server, so this now gives them a
consistent mail store on iPhone, via SSL web access, or via application on
multiple machines.
Jonathan
................................
Jonathan Mergy (jmergy@lwhs.org)
Director Of Technology
Lick-Wilmerding High School
755 Ocean Ave, SF CA 94112
P:415.333.4021 x365
http://www.lwhs.org
> From: Tom Phelan <tphelan@PEDDIE.ORG>
> Reply-To: ISED-L <ISED-L@listserv.syr.edu>
> Date: Tue, 14 Oct 2008 10:18:01 -0400
> To: ISED-L <ISED-L@listserv.syr.edu>
> Subject: Re: Switching Email Systems
>
> On Mon, 13 Oct 2008 16:42:18 -0700, Steve Taffee
> <sustainability@CASTILLEJA.ORG> wrote:
>
>> We are considering switching email systems. From what to what is not as
>> important to me at this point as hearing from you as to what lengths
>> you have gone to in migrating user data.
>
> We switched to Google Apps this September a week before school started. This
> is the first email format switch for us and thus some users had data dating
> back to the mid 1990's!
>
> In a nutshell, here was our plan re legacy data:
>
> * We migrated nothing besides address book entries on an as-requested basis.
> * We will leave our previous email server online for 1 year providing easy
> access in a familiar format to old email via either the old client or
> web-based access. However, after the mandatory migration day all inbound and
> outbound email from the old system was disabled.
> * We will provide faculty and staff with a CD which contains the old client
> software and their mail file along with easy instructions for installing the
> client in a standalone capacity to access their email. We also archived
> these files to tape in case faculty loose their CD.
>
> After experimenting with various migration options, in the end we decided
> that the best way to provide access for legacy emails was in the same format
> users were used to. We saw a lot of down sides to migrating old emails and
> not a lot of up side. Users know where their stuff is in the old system and
> how to find it best when it is still in the old system. Many also found it
> reassuring to know that the old system would still be available for an
> entire year essentially untouched so they didn't have to worry about whether
> they would be able to find their old emails. Furthermore, it is our
> experience that users need access to their old emails far less than they
> think, especially for email over 1 year old. Thus having to go into the old
> system with an occasional cut and paste is not too cumbersome and we
> anticipate that the CD we provide will rarely be used.
>
> Six weeks into the new system and we have had almost no negative feedback
> regarding access to old emails. The biggest area of negative feedback was
> getting used to a new system and different ways of doing familiar things.
> Thus our experience has been that email migration was not the issue needing
> the most attention, rather helping users to get comfortable using a new
> system that they all use on a daily basis was most important.
>
> Toward this end we provided a 3 month optional migration period for all
> faculty and staff to build up a good core of users already comfortable with
> the new system before the forced migration day. We also migrated all offices
> on an office-by-office basis over the summer so we could give offices
> focused attention before faculty returned and they could be comfortable with
> the new system before the busy start of the new academic year hit. These two
> approaches both significantly helped reduce the support load on the tech
> department and reduced anxiety over the switch. By the time of the mandatory
> migration more than 1/2 of non-students were already migrated.
>
> On the student side we decided to migrate all students at the same time as
> we felt we could not handle assorted questions/problems from hundreds of
> users migrating at different times. By migrating all students at the same
> time they relied more on helping each other than on the tech department.
>
> --
> Tom Phelan
> Director of Technology
> Peddie School
>
> [ For info on ISED-L see http://www.gds.org/ISED-L ]
> Submissions to ISED-L are released under a creative commons, attribution,
> non-commercial, share-alike license.
> RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=ISED-L
[ For info on ISED-L see http://www.gds.org/ISED-L ]
Submissions to ISED-L are released under a creative commons, attribution, non-commercial, share-alike license.
RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=ISED-L
