<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
