These guidelines were drawn up from the experience of migrating from the old OUCS Herald email system and with other, more recent migrations in mind. This document attempts to set out some responsibilities of IT Services and the unit with regards to such a process.
The Nexus Email Service SLD underpins this document and states
Some departments and colleges run their own Exchange or other email service. Where a unit wishes to migrate from their local service to Nexus IT Services will provide advice to departments and colleges on a reasonable efforts basis, including an initial assessment of the complexity and likely resources required to undertake any such migration, as well as providing supporting materials relating to the preferred methods of undertaking any migration process. However, no specific resources have been allocated for IT Services to undertake a migration from a department service to the Nexus Service or for enabling interoperability between Nexus and a local Exchange instance, for example. Departments wishing to migrate from a local service or who wish to use Nexus beyond the scope of the service defined in this SLD would be expected to commit the required resources to enable any IT Services support for such activities (where feasible). Some useful background information, including indicators of the level of support IT Services can provide to migrating units is described at <http://www.oucs.ox.ac.uk/nexus/itss/altmigrate.xml>. Departments seeking a hosting facility for their own Exchange or email service should contact NSMS in the first instance.
2. Outline Process
Evaluation: Establishing what data needs to be migrated and defining success criteria (in the Herald migration data integrity of the email was the primary success criteria). Look at available tools and perform some preliminary testing to determine if they are fit for purpose.
Design: Design end to end migration process first for a single account and then wrap this with a second process that migrates each account in turn (serial) or several at once (parallel).
Testing: Test each part of the per-account migration process individually then test the full process over several accounts against test servers.
Initial Migrations: Run a small number of live migrations, committing the user to Nexus. Most likely IT Staff for the unit.
Early Adopters: Migrate a small group of users and seek feedback on the migration process. Roll any feedback back into the process to improve it for the bulk migrations.
Bulk Migrations: Migrate all other users according to the timetable.
3. Migration Software/Hardware
IT Services can provide some advice and support regarding the purchase of any specialized migration software. The Nexus Team may also provide a limited number of test accounts should the unit wish to run some migration tests prior to committing to a software purchase.
For larger migrations, a 'migration master' account can sometimes be provided in order to manage the accounts within the migrating unit only. This gives the migrating unit the ability to define security groups etc. and to establish the devolved access (e.g. Full Access privileges) similar to the source system.
With regard to hardware, in 2009, the migration from Herald to Exchange used 8 quad-core machines with 6GB of memory each, each evening for the Herald to Nexus migration process. These machines would migrate approximately 1,000 accounts in 12 hours.
The Nexus Service, and IT Services, are not funded to purchase software on behalf of the unit thus all costs relating to specialized or custom developed software lie with the unit. Similarly both Nexus, and IT Services, are not funded to provide hardware for the migration process.
4. Methods of Access
For access via Outlook Anywhere, Exchange Web Services an administrative account with delegation/impersonation rights over the target mailbox(es) may be supplied so that data can be loaded into Nexus.
5. User Support
A summary of user support responsibilities can be found in the Nexus SLD in sections 2 and 3
6. Email Routing
At any point in time, email should be routed to one mailbox for any particular address. The migration process for a mailbox should start with the update of any routing for the email address and the setting up of appropriate forwarding from the local mail server to Nexus.
Direct deliver departments wishing to migrate should carefully consider the point in the process when they would like to move from direct deliver to oxmail routed (personal routing). Delivering email to the department and then that email being routed back to Nexus is not sustainable and may cause mail loops if the two systems are not kept synchronized. A synchronization process is in place with the oxmails and occurs automatically minimising the likelihood of mail loops and other routing anomalies.
7. Administrative Access
During the migration process IT Services may supply the unit with an account with the appropriate level of access to insert items into target mailboxes. Preferably this account should only have rights over an individual mailbox for the time taken to migrate the account and no longer. Ideally access can be granted on a daily basis to the target mailboxes for that day's migrations. This clearly requires very good planning.
For general client support purposes IT Services will provide ITSS with access to a user's mailbox if that user has contacted IT Services to confirm that they are happy for this action to take place. All access is granted in accordance with the University's IT rules and regulations, specifically the section related to examining user data.
Although some units may have historically used administrative access implicitly while performing user support functions for their email services, IT Services will not grant an individual long-term rights over a large number of mailboxes.
In all cases, authorization for access to a mailbox must come from an indivdual user, the Head of Department, Registrar or Proctors, as appropriate (IT Rules and Regulations sections 17.3, 17.2, and 17.5a).
IT Services will not provide a general administrative account on Nexus. No direct access to the Active Directory or user mailboxes will be permitted outside of that detailed above.
8. Test Accounts
IT Services may provide a limited number of test accounts for initial/preliminary testing. These can also be made live and visible in the production Nexus system for use during and post-migration.
9. Account Provisioning
All members of the University have a Nexus mailbox which they may or may not use. Any accounts held on local mail servers should be imported into the appropriate Nexus mailbox. Where a mailbox does not exist a new account must be provisioned and this will most likely be a 'project account' related to a specific team, project or role.
A mapping between the local mail server accounts (source accounts) and Nexus (target accounts) should be established prior to migrating any data. IT Services can provide appropriate list of accounts with aliases/SSOs, if required.
Please note that it is dangerous to assume that all of your users to be migrated will have empty, unused Nexus mailboxes. In the past, it has been discovered that some users are cleverly using both and do not want the two collections of emails to be merged. IT Services can gather statistics regarding mailbox size and access to Nexus accounts in order to identify such situations.
10. Mailboxes over 3GB
Nexus has a facility in place to permit quotas in excess of 3GB. Any quota assigned above 3GB is charged to the user's sponsoring unit per GB per month (or part thereof). An online interface has been developed to allow ITSS to manage quotas through the ITSS registration system at https://register.it.ox.ac.uk/itss/nexus_quota.
11. Data Types
With each primary data type it is anticipated that some elements may not migrate from the source system to Nexus. The data may not map appropriately into Exchange or the migration tool in use may not have the ability to migrate that data element. It is the responsibility of the unit to determine the limitations of the migration process/tools and take appropriate decisions as the the value of any data lost during the process and to inform end users of any data-loss during the migration process.
For some systems a migration of existing mailbox permissions/sharing rights may be possible, but this will be a product of the source system, migration tool in use and the creation of an appropriate mapping between source and target accounts.
Groups/Distribution lists: Groups should be evaluated to determine if they are solely required in a mailing list capacity or if they are also used for authorization decisions. The Nexus service is anticipating the existence of a central GroupStore service (beyond the remit of the Nexus Team) to deliver user-customizable groups to Nexus, as well as other central services. In the meantime groups/distribution lists should be migrated into Nexus only if they are used for authorization. Other groups, used only as email lists, should be migrated to the IT Services Mailing List service. Group maintenance can be devolved to owners of such groups under some circumatances (e.g. through Microsoft Outlook). Units should be aware that they may be required to migrate their groups from Nexus to the GroupStore service as soon as it becomes available and some degree of reconfiguration may be required for their users at this point (re-granting calendar access for example).
12. IT Services Resources
13. Other Considerations
Automated Systems: Within your unit, automatic monitoring or other system processes may be using a local SMTP server to send email. Post-migration, a local SMTP server would either need to be maintained, or all automated systems reconfigured appropriately.
Hybrid Systems: Some units may wish to run hybrid systems, where some users continue to have mailboxes located on local systems and some on Nexus. This case is not unusual. Careful attention should be paid to mail routings in this setup and you are strongly advised to utilise the Oxmail service for routing users' email in these circumstances.