You are here

Migration of Luminis Sun Mail to Gmail

Submitted by bravozulu on Fri, 03/02/2012 - 10:38

Has anyone attempted to migrate Luminis Sun mail to Gmail? We're migrating mail now, and for our end users who do not use Outlook and only use Luminis mail, we're looking at migrating mail to Outlook to then migrate to Gmail. Anyone else find a simpler way to approach this?

Luminis Version:

We recently did this for a few hundred thousand student accounts (employees are going later). We used the Google Apps Directory Sync tool to provision accounts (slowly over weeks). Once that was done, we used imapsync in a perl script to migrate the mail to Gmail.

We also engaged Sungard for their role based sso to Gmail, as employees are still on the old system for a while longer. Part of the migration process was marking accounts with a custom role depending on the status (migration started, migration finished, lastly marked with the role 'gmail', which the CustomIconEvaluator uses to display the gmail email icon).

You can contact us
Me (search for jwhitene) - handled the sso / icon / provisioning / set forwarding addresses
search for dpelinka - handled the postini setup, imapsync, split delivery

We are in the process of migrating from the integrated Luminis email system to Google. We are planning to use the Migration API. I've written a small (but growing) Ruby Library to interface with the API. The migrated messages are flagged with a warning since they didn't arrive via an actual mail system. We've decided to apply a "Migrated" label to the mail with the hopes that it will reduce the confusion for our users.

We are hoping that a straight forward approach will save us time and headaches.

I have Gmail SSO working and others are are working the actual account & mail migration, but what if any settings did anyone use on the Sun Mail server POST migration? i.e. to handle TAs and any other "local delivery" issues ?

I was thinking just reset the smtp server setting on the portal to a local "ghost" that forwards on to google ? and local.mail.server still goes to local channel via existing rules?
Trying to avoid the eye-strain of hacking those wacky imta and mapping files :)



I've been slowly tracking down lots of settings required to fully remove our sun server from our portal environment. It isn't as simple as just changing the smtp host of the portal.

I'm close to being able to turn off our sun email server. Once I verify all the things we had to change in order to remove it, I'll post them. Right now I'm testing whether we need to modify each user's ldap record to fix some email related errors I'm seeing in cp.log.

Also, don't forget about sun calendar (if you were using that). If you don't remove those settings, and simply turn off the calendar server, your message broker will fill up with calendar creation events and your message broker will stop delivering events.

Yes, I was thinking we'll need to modify their email settings in ldap at a minimum (pretty much done already in the banner-to-AD-to-google scripts).

TAs are what concern me most at this point. I'm hoping the modified Ldap email-attrs will handle sending gmail on its way and keep true local (i.e. cpadmin) local

Cal - enabled but not really used that much - will probably just turn off until/unless someone screams.

Definitely post or email me your final settings.


We are planning the same transition from Sun Mail to Gmail at Mt. SAC. Are you able to share the list of things you had to change to turn off your Sun Mail server?

Jason and other forum contributes, I am also interested in the list of settings required to fully remove the sun mail server and the calendar server. My institution switched student e-mail to Outlook (web version) and we currently running two e-mail systems in parallel. The hope is to have the old mail and calendar servers powered down by the end of the year. So, if you have the list of settings, please post it here. I am starting to put together my own list, so I will post it on this forum after I make more progress on it.

You'll want to work with support and fully test things before attempting them in production.

I don't think I ever completely removed all the Sun stuff from our environment. I didn't bother removing a lot of the ldap attributes. And I can still see in the cp.log occasional attempts to connect to the old mail server, which we trick by pointing that name to localhost in the hosts file.

Here are the settings I was able to find in some old docs:

configman -s mua.enabled false
configman -s email.enabled false
configman -s
configman -s SCT.event.smtphost
configman -s
configman -s email.config.aeac.defaultMailHost
configman -s
configman -s ceHost
configman -s email.hosts.outgoing
configman -s grouptools.calendar.enabled false

Good luck