Main Nav

 

Here at Williams College we are in the process of migrating to Google.  We would like to learn at what point you switched forwarding of new mail to Google in the migration process.  Did you switch it at the start of the migration of an account or after the account was migrated ?  Also did you do more than 1 migration for an account to catch any changes ?

 

Thanks much !

 

____________________________________________________
Maggie Koperniak
Project Mgr, Administrative Systems
Williams College, Office for Information Technology
Margaret.M.Koperniak@williams.edu
(413) 597-2336 FAX: (413) 597-4103

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Maggie,

We gave our users two days to login to the account to make setting changes, etc., then we forwarded all new mail and started the migration on the third day.  We did not do more than one migration, as users were told that beginning with their cutover all changes should be made in their Google account.  This process worked successfully and smoothly for 8500 users and generic accounts.  If you need any further information, please do not hesitate to contact me directly.

Good luck!

Marie Scott


We migrated all of our data for our users.  

We actually did it right on Christmas a few years back.  After we gave notice that the change over would happen, we moved forward with the new Gmail system (on the 25th) and them migrated all data (on or before the change over day) over the following days.  

We only did one migration.  


Message from ajbarnes@ncsu.edu

Good afternoon,
 NCSU moved from cyrus and groupwise systems to Google Apps. Our old pages about our migration are at http://google.ncsu.edu/learn/migration-google-apps and have lots of information. I only remember the groupwise part in good detail without review. For that migration we provisioned all users into Google - and moved their data over about six weeks in ever decreasing increments until the final night we switched over the mail routing, locked out the old system (groupwise) and did the final increment (<1 day of emails) for all users.

-Andrew Barnes


We went through a 3 step procedure during our migration. We redirected all of the user's email at the mail server, then migrated the user's email, then changed the MX record to reflect the new email service. we also migrated our users in batches rather than migrating everybody all at once.




Message from gibson_brian@wheatoncollege.edu

We migrated groups of about 75 faculty/staff at a time using the Exchange Migration tool so our tech support could handle the fall out then at the end we migrated all of the students at once. During that piece meal migration process we routed all mail through our local system but put forwarders out to the username@wheatoncollege.edu.test-google-a.com special domain address that Google provides for the people that we migrated so all mail would come here but get forwarded off to Google for people that were moved. Once everyone's data was moved we changed the DNS MX records to point to Google's servers so mail no longer routed through here and that was that. Actually, I lied, we still needed to route mail through here for our mailing lists but once we moved those into Google Groups we THEN changed the MX records.


++++++++++++++++++++++++++++ Brian Gibson Systems Administrator Wheaton College Are you a musician? If so visit my Arbans Online music site at http://arbansonline.com and listen & contribute On 3/4/2014 2:56 PM, Stuart, Nathan wrote:
We migrated all of our data for our users.  

We actually did it right on Christmas a few years back.  After we gave notice that the change over would happen, we moved forward with the new Gmail system (on the 25th) and them migrated all data (on or before the change over day) over the following days.  

We only did one migration.  



At my previous institution, used a homegrown scripting process to move from an IMAP system to google. We did a hard cutover to deliver mail to google at a particular time (at the start of the migration) and started moving mail from the oldest message to the newest. That way, anything that arrived for some reason to the old mailbox during the migration would get migrated at the end. 

There were some remigrations due to random errors and also because of some corrupted messages that just failed. Also be aware of any mail messages that are larger than google supports (attachments). 

We also used a 3rd party solution to move from group wise to google, and followed the same model. We informed users about their migration start and end times via a home grown website that displayed their status at any point in time. That helped users figure out if they had started moving yet, if they were finished, or if there were errors/delays. 

I could go into much more detail, so let me know if you wanted anything else expanded upon. 

--Nick Young
UNC Greensboro



On Tuesday, March 4, 2014, Maggie Koperniak <mkoperni@williams.edu> wrote:

 

Here at Williams College we are in the process of migrating to Google.  We would like to learn at what point you switched forwarding of new mail to Google in the migration process.  Did you switch it at the start of the migration of an account or after the account was migrated ?  Also did you do more than 1 migration for an account to catch any changes ?

 

Thanks much !

 

____________________________________________________
Maggie Koperniak
Project Mgr, Administrative Systems
Williams College, Office for Information Technology
Margaret.M.Koperniak@williams.edu
(413) 597-2336 FAX: (413) 597-4103

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.



--
..................................................................
Nick Young
IT Manager, Application Administration, ITS
The University of North Carolina at Greensboro
n_young@uncg.edu | http://its.uncg.edu
..................................................................
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Hi all,

We migrated about 6 months ago, and we did the migration in 2 steps.

1.  First, we established our GAFE environment, setup accounts, GADS, and had all users change their passwords (which then sync'd the passwords to Google).  At this point our users had a Google account, but no mail.  We called this "Day 0".
2.  Then, we migrated all mail from our "Day 0" date backward.  Users started to see old mail show up in Google, and they could reply and compose messages, so they got the hang of it.
3.  After all prior mail was migrated (took a couple of weeks), we changed our MX records to deliver new mail to Google.  We called this "Day 1".
4.  We then migrated all mail from Day 1 back to Day 0.

This seemed to work well for us.  Good luck!

John


We did a hard cutover migration, but migrated legacy faculty and staff email in several passes before the cutover.  The weekend of the migration, we changed our MX records to point to Google (make sure you lower your TTLs to around 15 minutes long enough before doing this so that the records update quickly), shut down our GroupWise server, and did a final copy which took several hours (probably about 1000 accounts.)  Students could pay to have their email migrated (it ended up being $10 a person and a few hundred students took us up on our offer.)  At first we had said we'd only migrate 6 months of old mail but it went smoothly enough that we migrated all email over to Google. (there was also exponentially less mail older than 6 months on our systems so it wasn't much additional stuff to move over.)


--Mike





Message from sfs@umn.edu

We have a self-serve migration process.  That process switches the user's forwarding after the most recent 30 days of INBOX, Trash, and Sent mail has been migrated.  Once the entire migration completes, the user is emailed a list of folders that we were unable to transfer and they are given 30 days to deal with that before being locked out of their old account.  Those whose messages all transfer successfully are locked out immediately following.


Message from william.eubank@uah.edu

We did ours several years ago.

We wrote our own web based tool, behind LDAP auth, that let users "opt-in" on demand, over a 3-4 month period.  We had a unix server so opt-in behind the scenes was simply putting a .forward in their home directory on the unix server which effected the forward for that account.  We are on postini as well so the forward in say ~smith/.forward was set to smith@postini.uah.edu which routed to postini, then to Google.

Migrations were done per user using a built in server side migration tool in Google's admin console that has since been removed.  You put in the pop/imap of the source and the google account as the destination.  Some users used their email client with multiple IMAP accounts, one old and one for Google, and drug-n-dropped their own data.  Many were using Outlook with POP which meant most of their data was on their PC so we used the GASMO import.

At the end of the opt-in period we added all the remaining .forward files using a perl script.  Then a few weeks later we switched our MX records in DNS to Google's servers.

It's been 99% awesome ever since.

-William




We migrated our employees and students (who have addresses in the same mail domain) at different times, so we had to make our mail routing flexible enough to deliver some users' mail to Google and some to our legacy system. We kept our MX records pointed at an on-campus server that routed either locally or to Google based on recipient LDAP attributes. Because of this, we were able to set the attribute on each user directly before beginning their individual migration, which caused all newly received mail to show up in their Google mailbox from that point forward. This let us avoid multiple migrations.

We also developed a new email single sign-on page that could switch destinations based on the same LDAP attribute and deployed this for the legacy system in the months leading up to the first migration. This meant that all users continued to land in the legacy system until their individual migration was begun, at which point they would automatically land in Google Apps for the first time. Our communication campaign directed them to begin using Google for reading and responding to new messages while waiting for all of their filed email to show up. We also provided a "backdoor" link to the legacy system if they urgently needed to refer to older messages while they were waiting.

We migrated our students over the winter holidays and our employees over spring break, so the inconvenience of extra steps to access filed mail for up to a few days was not a big deal. Most people didn't care about anything other than their new email, to which they had uninterrupted access.

-jbp

--
Jay Parker | Associate Director - Systems
University of Arkansas at Little Rock | Information Technology Services
+1-501-916-3010 | jbparker@ualr.edu | http://ualr.edu/itservices


Hi Maggie,

 

We migrated our students and alumni last summer to Google Apps (GApps) from a legacy Exchange environment using a cut-over/dump truck migration.  I started migrating the mail data a few days prior to the cut-over but upon the go-live day enabled forwarding using mail contacts that I created previously via scripting.  Because we were moving our students and alumni to a new sub-domain but still wished to provide forwarding externally until an unspecified future date I setup a split-domain delivery within our spam filter for all of our GApps users.  Lastly I setup their old primary domain as a domain alias within GApps to complete that forwarding process.

 

Matthew Spears

Multnomah University

Systems Administrator| Information Technology

w: 503.251.6552 | c: 503.816.7476

multnomah.edu | @matthewspears

 

We switched forwarding for each account at the start of its migration, primarily to avoid having to worry about multiple sync passes.

Initially everything was routed to our existing system and sent to Google as needed. The plan was we'd keep our spam filter/quarantine system as-is and then cut to Google's normal after everyone was migrated. However a couple months into migration we hit the situation where the volume of what was formerly internal mail now going through the spam filters (due to enough users on Google) overloaded them. We then effectively reversed the flow (Google accepts, forwards non-Google users to our old system). Even with that we did have to put the rules in Exchange at the start of migration to prevent Exchange-originated mail from ending up in the old mailbox.

We had initially pre-staged all the Google accounts (because it sometimes took a while for them to be usable after bulk adding), but for the fall-through to our old system to work once they started accepting for our domain, we had to remove those accounts. There were some caching issues due to the large number of changes in a short period not processing correctly, and Google support seeing the old accounts caused some confusion initially too. When we switched to create-at-account-migration-start rather than in as a batch before a group of users the delay went away too. I guess the key lesson was doing stuff in batches kinda bit us, and just-in-time ended up being the approach we went to in the end anyways.



Hello

We..

1) Bought Postini service and moved our MX to it 6months previous to Google migration (meaning come G-Day, it was just a simple/immediate config change)
2) Went through 3 pilots where we moved the mail for them overnight 
3) Took a snapshot of remaining mail that was older than 1 year to reduce our migration time. 
4) This was sent to our migration providers (www.ancoris.com) who pre-mgirated it into our Google Apps accounts for us
5) On G-Day, we then made legacy accounts read only, swopped delivery in Postini and began the migration of the remaining mail. We chose Easter 2013 as this gave us 5 days to manage the migration.
6) Happy users.

Mally


On 4 March 2014 19:19, Maggie Koperniak <mkoperni@williams.edu> wrote:

 

Here at Williams College we are in the process of migrating to Google.  We would like to learn at what point you switched forwarding of new mail to Google in the migration process.  Did you switch it at the start of the migration of an account or after the account was migrated ?  Also did you do more than 1 migration for an account to catch any changes ?

 

Thanks much !

 

____________________________________________________
Maggie Koperniak
Project Mgr, Administrative Systems
Williams College, Office for Information Technology
Margaret.M.Koperniak@williams.edu
(413) 597-2336 FAX: (413) 597-4103

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.




--
Mally Mclane
Communication and Collaboration Services Manager
University of Bristol
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott





On 5 March 2014 13:01, Marie L Scott <mlscott@vcu.edu> wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  


We were lucky - the average staff mailbox here was a grand.... 70mb. Yep, mb, not gb...

Mally

 
Marie Scott


Mally - 

Our users are pack rats!  And in the gigabytes worth of data was a year's worth of data!  We were using the GAMLN tool, which worked like a champ, but with Google throttling the data upload it was took several weeks for some user's data to migrate.

Marie Scott


1 message per second per user did slow things down for us as well.

one of the biggest things that we ran into was that we had some folks that were using their "deleted items" as an archive.



We are about to migrate (mid May) from Zimbra for email and Oracle calendar.   Looking at only migrating faculty/staff data, but we are considering doing students after the fact.  We will only transfer email.  Oracle Calendar is too much of an ordeal and/or too costly.

As of now, I was looking at using the GAMME tool, however it has some shortcomings with regards to do a multi pass migration, which is what I thought initially doing.    I do like it's ability to scale, though Google claims we should not use more than one GAMME tool at at time, with up to 50 concurrent processes (of course it depends on how good our mail system would handle it).  Our initial test run of about 300 accounts with 35gb total took 10 hours (with 50 concurrent processes).   So this would take several days to do 2500 accounts with about 850gb of data.   So, I'm also looking now at imapsync, if anything for the last pass unless I can have it run parallel processes better than the GAMME tool.

Ideally, we will do a 2 run pass a couple of weeks before, then at cut over, all new mail will start to get delivered to the new servers, and we will do a final pass then.  The initial runs will delete messages not on source, except the last run.  This will minimize the time the users will be out of mail and not have to delete again old messages.

I do like GAMME's reporting ability for not transferred messages (so far, it's only been either executable files it seems).

We are Postini customers and will continue to run mail thru it and thru our servers before going to Google apps. 



--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 8:01 AM, Marie L Scott wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott


Hi Ricardo

We also went from oracle. It's such a poor product and caused us so many data quality issues (I reckon our migrated data was only 90% accurate), but we'd have been lynched if we didn't do it :-(

Mally

On 5 Mar 2014 15:45, "Ricardo Stella" <stella@rider.edu> wrote:

We are about to migrate (mid May) from Zimbra for email and Oracle calendar.   Looking at only migrating faculty/staff data, but we are considering doing students after the fact.  We will only transfer email.  Oracle Calendar is too much of an ordeal and/or too costly.

As of now, I was looking at using the GAMME tool, however it has some shortcomings with regards to do a multi pass migration, which is what I thought initially doing.    I do like it's ability to scale, though Google claims we should not use more than one GAMME tool at at time, with up to 50 concurrent processes (of course it depends on how good our mail system would handle it).  Our initial test run of about 300 accounts with 35gb total took 10 hours (with 50 concurrent processes).   So this would take several days to do 2500 accounts with about 850gb of data.   So, I'm also looking now at imapsync, if anything for the last pass unless I can have it run parallel processes better than the GAMME tool.

Ideally, we will do a 2 run pass a couple of weeks before, then at cut over, all new mail will start to get delivered to the new servers, and we will do a final pass then.  The initial runs will delete messages not on source, except the last run.  This will minimize the time the users will be out of mail and not have to delete again old messages.

I do like GAMME's reporting ability for not transferred messages (so far, it's only been either executable files it seems).

We are Postini customers and will continue to run mail thru it and thru our servers before going to Google apps. 



--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 8:01 AM, Marie L Scott wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott


So we are not the only ones with users using the trash can archival system!  I've been held back so many times doing a quick demonstration of pulling a paper out of a trash can for them to sign....

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 9:27 AM, Frank Barton wrote:
1 message per second per user did slow things down for us as well.

one of the biggest things that we ran into was that we had some folks that were using their "deleted items" as an archive.

--
Frank Barton
Apple Certified Mac Technician
Technology Support Coordinator
Husson University
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


So Mally, what did you guys use?  Third party? or home grown scripts?  We currently run this on a 5 yr old Solaris sparc rig.  We do a quick 30 day +- export to ical for a few users.  At one point I actually tested moving it to a little Linux VM and performance for the export was 10 times faster.  

So far they haven't balked at the idea we won't transfer it, but I can see it coming back to us no matter what...

Thanks - Ricardo.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 10:47 AM, Mally Mclane wrote:

Hi Ricardo

We also went from oracle. It's such a poor product and caused us so many data quality issues (I reckon our migrated data was only 90% accurate), but we'd have been lynched if we didn't do it :-(

Mally

On 5 Mar 2014 15:45, "Ricardo Stella" <stella@rider.edu> wrote:

We are about to migrate (mid May) from Zimbra for email and Oracle calendar.   Looking at only migrating faculty/staff data, but we are considering doing students after the fact.  We will only transfer email.  Oracle Calendar is too much of an ordeal and/or too costly.

As of now, I was looking at using the GAMME tool, however it has some shortcomings with regards to do a multi pass migration, which is what I thought initially doing.    I do like it's ability to scale, though Google claims we should not use more than one GAMME tool at at time, with up to 50 concurrent processes (of course it depends on how good our mail system would handle it).  Our initial test run of about 300 accounts with 35gb total took 10 hours (with 50 concurrent processes).   So this would take several days to do 2500 accounts with about 850gb of data.   So, I'm also looking now at imapsync, if anything for the last pass unless I can have it run parallel processes better than the GAMME tool.

Ideally, we will do a 2 run pass a couple of weeks before, then at cut over, all new mail will start to get delivered to the new servers, and we will do a final pass then.  The initial runs will delete messages not on source, except the last run.  This will minimize the time the users will be out of mail and not have to delete again old messages.

I do like GAMME's reporting ability for not transferred messages (so far, it's only been either executable files it seems).

We are Postini customers and will continue to run mail thru it and thru our servers before going to Google apps. 



--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 8:01 AM, Marie L Scott wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott


We had used the University of Washington imap server before and with Google's APIs and our own code, managed to do a rather clever transfer of around one to two thousand users at the time and in the process, redefined their email addresses and delivery route and made sure we had forwarding aliases put in place to catch email being sent to the old address. We informed the students 2 weeks in advance which batch they were in and again a few days before as well as the day before. It took about two months to migrate some 60,000+ accounts but it went remarkably smoothly and students couldn't be happier. This must have been four or five years ago now -- it's all a distant blur. :-)

On 3/5/2014 8:48 AM, Ricardo Stella wrote:
So we are not the only ones with users using the trash can archival system!  I've been held back so many times doing a quick demonstration of pulling a paper out of a trash can for them to sign....

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 9:27 AM, Frank Barton wrote:
1 message per second per user did slow things down for us as well.

one of the biggest things that we ran into was that we had some folks that were using their "deleted items" as an archive.

--
Frank Barton
Apple Certified Mac Technician
Technology Support Coordinator
Husson University
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.



********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

We wrote our own scripts that pulled stuff down from oracle and put it into Google using their apis.

Happy to put you in touch with the right guy here if it's helpful?

Mally

On 5 Mar 2014 15:53, "Ricardo Stella" <stella@rider.edu> wrote:

So Mally, what did you guys use?  Third party? or home grown scripts?  We currently run this on a 5 yr old Solaris sparc rig.  We do a quick 30 day +- export to ical for a few users.  At one point I actually tested moving it to a little Linux VM and performance for the export was 10 times faster.  

So far they haven't balked at the idea we won't transfer it, but I can see it coming back to us no matter what...

Thanks - Ricardo.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 10:47 AM, Mally Mclane wrote:

Hi Ricardo

We also went from oracle. It's such a poor product and caused us so many data quality issues (I reckon our migrated data was only 90% accurate), but we'd have been lynched if we didn't do it :-(

Mally

On 5 Mar 2014 15:45, "Ricardo Stella" <stella@rider.edu> wrote:

We are about to migrate (mid May) from Zimbra for email and Oracle calendar.   Looking at only migrating faculty/staff data, but we are considering doing students after the fact.  We will only transfer email.  Oracle Calendar is too much of an ordeal and/or too costly.

As of now, I was looking at using the GAMME tool, however it has some shortcomings with regards to do a multi pass migration, which is what I thought initially doing.    I do like it's ability to scale, though Google claims we should not use more than one GAMME tool at at time, with up to 50 concurrent processes (of course it depends on how good our mail system would handle it).  Our initial test run of about 300 accounts with 35gb total took 10 hours (with 50 concurrent processes).   So this would take several days to do 2500 accounts with about 850gb of data.   So, I'm also looking now at imapsync, if anything for the last pass unless I can have it run parallel processes better than the GAMME tool.

Ideally, we will do a 2 run pass a couple of weeks before, then at cut over, all new mail will start to get delivered to the new servers, and we will do a final pass then.  The initial runs will delete messages not on source, except the last run.  This will minimize the time the users will be out of mail and not have to delete again old messages.

I do like GAMME's reporting ability for not transferred messages (so far, it's only been either executable files it seems).

We are Postini customers and will continue to run mail thru it and thru our servers before going to Google apps. 



--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 8:01 AM, Marie L Scott wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott


Please do!

Thanks in advance - Ricardo.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 10:56 AM, Mally Mclane wrote:

We wrote our own scripts that pulled stuff down from oracle and put it into Google using their apis.

Happy to put you in touch with the right guy here if it's helpful?

Mally

On 5 Mar 2014 15:53, "Ricardo Stella" <stella@rider.edu> wrote:

So Mally, what did you guys use?  Third party? or home grown scripts?  We currently run this on a 5 yr old Solaris sparc rig.  We do a quick 30 day +- export to ical for a few users.  At one point I actually tested moving it to a little Linux VM and performance for the export was 10 times faster.  

So far they haven't balked at the idea we won't transfer it, but I can see it coming back to us no matter what...

Thanks - Ricardo.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 10:47 AM, Mally Mclane wrote:

Hi Ricardo

We also went from oracle. It's such a poor product and caused us so many data quality issues (I reckon our migrated data was only 90% accurate), but we'd have been lynched if we didn't do it :-(

Mally

On 5 Mar 2014 15:45, "Ricardo Stella" <stella@rider.edu> wrote:

We are about to migrate (mid May) from Zimbra for email and Oracle calendar.   Looking at only migrating faculty/staff data, but we are considering doing students after the fact.  We will only transfer email.  Oracle Calendar is too much of an ordeal and/or too costly.

As of now, I was looking at using the GAMME tool, however it has some shortcomings with regards to do a multi pass migration, which is what I thought initially doing.    I do like it's ability to scale, though Google claims we should not use more than one GAMME tool at at time, with up to 50 concurrent processes (of course it depends on how good our mail system would handle it).  Our initial test run of about 300 accounts with 35gb total took 10 hours (with 50 concurrent processes).   So this would take several days to do 2500 accounts with about 850gb of data.   So, I'm also looking now at imapsync, if anything for the last pass unless I can have it run parallel processes better than the GAMME tool.

Ideally, we will do a 2 run pass a couple of weeks before, then at cut over, all new mail will start to get delivered to the new servers, and we will do a final pass then.  The initial runs will delete messages not on source, except the last run.  This will minimize the time the users will be out of mail and not have to delete again old messages.

I do like GAMME's reporting ability for not transferred messages (so far, it's only been either executable files it seems).

We are Postini customers and will continue to run mail thru it and thru our servers before going to Google apps. 



--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 8:01 AM, Marie L Scott wrote:
Hi - I'm curious as to what systems you all were migrating from?  As it sounds like your migrations went much faster than ours.  We were migrating from Lotus Notes and our users had lots and lots of data (some individuals had several gigabytes in fact).  

Marie Scott


On Wed, Mar 5, 2014 at 7:38 AM, Mally Mclane <mally.mclane@bristol.ac.uk> wrote:
Hello

We..

1) Bought Postini service and moved our MX to it 6months previous to Google migration (meaning come G-Day, it was just a simple/immediate config change)
2) Went through 3 pilots where we moved the mail for them overnight 
3) Took a snapshot of remaining mail that was older than 1 year to reduce our migration time. 
4) This was sent to our migration providers (www.ancoris.com) who pre-mgirated it into our Google Apps accounts for us
5) On G-Day, we then made legacy accounts read only, swopped delivery in Postini and began the migration of the remaining mail. We chose Easter 2013 as this gave us 5 days to manage the migration.
6) Happy users.

Mally


On 4 March 2014 19:19, Maggie Koperniak <mkoperni@williams.edu> wrote:

 

Here at Williams College we are in the process of migrating to Google.  We would like to learn at what point you switched forwarding of new mail to Google in the migration process.  Did you switch it at the start of the migration of an account or after the account was migrated ?  Also did you do more than 1 migration for an account to catch any changes ?

 

Thanks much !

 

____________________________________________________
Maggie Koperniak
Project Mgr, Administrative Systems
Williams College, Office for Information Technology
Margaret.M.Koperniak@williams.edu
(413) 597-2336 FAX: (413) 597-4103

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.



--
Mally Mclane
Communication and Collaboration Services Manager
University of Bristol
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.




--
Marie L. Scott
Director, Collaboration Services
Virginia Commonwealth University
804.828.4055



********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

I didn't do that demonstration, but I did do the "trash can next to a file cabinet" example


We  directed email to Google immediately before we began migrating their old email. They were told to begin looking at Google for new email at 4:00 p.m. on a Friday and to expect most of their email to have migrated by Monday or Tuesday.

Rick
We migrated from Zimbra to Google Apps.  We had an opt-in phase that lasted about 3 months.  During that time clients could go to a web page that we created.  After the client authenticated and agreed to opt-in, a forward was set in Zimbra to send their mail to Google and their account was added to a google spreadsheet.  The web page then gave them links to appropriate documentation for reconfiguring their mail client and such.

One of our Sys Admins would then use a Google provided email migration tool to move all the old mail for batches of accounts at a time.  We had 3 VMs set up with the software so that we could be moving a lot of mail at once.

At the end of 3 months we manually migrated what was left (~10%) in 3 or 4 batches.  We would send an email to the old account telling them their mail was now going to google, set the forward and begin the migration process.  

We didn't change our MX record until we were done will all the mail migrations.

Alan



We were planning on using multiple VMs to run several GAMME tools at once, but Google advised us against that, claiming we could get cross corrupted data.   I find it hard to believe, so I ask,  has anyone had any issues with running multiple GAMME tools at once?  Of course each tool would only access a distinct set of accounts...

TIA.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 11:26 AM, Alan H. Sutter '87 wrote:
We migrated from Zimbra to Google Apps.  We had an opt-in phase that lasted about 3 months.  During that time clients could go to a web page that we created.  After the client authenticated and agreed to opt-in, a forward was set in Zimbra to send their mail to Google and their account was added to a google spreadsheet.  The web page then gave them links to appropriate documentation for reconfiguring their mail client and such.

One of our Sys Admins would then use a Google provided email migration tool to move all the old mail for batches of accounts at a time.  We had 3 VMs set up with the software so that we could be moving a lot of mail at once.

At the end of 3 months we manually migrated what was left (~10%) in 3 or 4 batches.  We would send an email to the old account telling them their mail was now going to google, set the forward and begin the migration process.  

We didn't change our MX record until we were done will all the mail migrations.

Alan


I ran 2 instances of GAMME on 2 different physical machines, and had no problems. of course YMMV


Message from gibson_brian@wheatoncollege.edu

We used several Windows 2003 virtual servers (around 10 I think) running the Google Exchange Migration Tool (with several users per VM) when we moved the students over and didn't see any issues


++++++++++++++++++++++++++++ Brian Gibson Systems Administrator Wheaton College Are you a musician? If so visit my Arbans Online music site at http://arbansonline.com and listen & contribute On 3/5/2014 11:47 AM, Ricardo Stella wrote:

We were planning on using multiple VMs to run several GAMME tools at once, but Google advised us against that, claiming we could get cross corrupted data.   I find it hard to believe, so I ask,  has anyone had any issues with running multiple GAMME tools at once?  Of course each tool would only access a distinct set of accounts...

TIA.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 11:26 AM, Alan H. Sutter '87 wrote:
We migrated from Zimbra to Google Apps.  We had an opt-in phase that lasted about 3 months.  During that time clients could go to a web page that we created.  After the client authenticated and agreed to opt-in, a forward was set in Zimbra to send their mail to Google and their account was added to a google spreadsheet.  The web page then gave them links to appropriate documentation for reconfiguring their mail client and such.

One of our Sys Admins would then use a Google provided email migration tool to move all the old mail for batches of accounts at a time.  We had 3 VMs set up with the software so that we could be moving a lot of mail at once.

At the end of 3 months we manually migrated what was left (~10%) in 3 or 4 batches.  We would send an email to the old account telling them their mail was now going to google, set the forward and begin the migration process.  

We didn't change our MX record until we were done will all the mail migrations.

Alan


That is exactly how our consultants did it  (using amazon's virtual stuff) and we never noticed issues...

On 5 Mar 2014 16:48, "Ricardo Stella" <stella@rider.edu> wrote:

We were planning on using multiple VMs to run several GAMME tools at once, but Google advised us against that, claiming we could get cross corrupted data.   I find it hard to believe, so I ask,  has anyone had any issues with running multiple GAMME tools at once?  Of course each tool would only access a distinct set of accounts...

TIA.

--
°((( = (( ===°°° ((( ================================================

On 3/5/2014 11:26 AM, Alan H. Sutter '87 wrote:
We migrated from Zimbra to Google Apps.  We had an opt-in phase that lasted about 3 months.  During that time clients could go to a web page that we created.  After the client authenticated and agreed to opt-in, a forward was set in Zimbra to send their mail to Google and their account was added to a google spreadsheet.  The web page then gave them links to appropriate documentation for reconfiguring their mail client and such.

One of our Sys Admins would then use a Google provided email migration tool to move all the old mail for batches of accounts at a time.  We had 3 VMs set up with the software so that we could be moving a lot of mail at once.

At the end of 3 months we manually migrated what was left (~10%) in 3 or 4 batches.  We would send an email to the old account telling them their mail was now going to google, set the forward and begin the migration process.  

We didn't change our MX record until we were done will all the mail migrations.

Alan


We ran 12 instances of the GAMLN tool - which is the GAMME equivalent.  We broke out users in groups.  I'm not sure why Google is saying that there would be any data corruption.  We had none - but we weren't also doing multi-pass and we didn't try to do the same user on different servers.  

Marie Scott


Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.