1. Overview

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

OUCS used a six stage process when migrating from Herald to Nexus and envision a similar process being required for migrations from local mail servers. The six stages were:
  1. Evaluation
  2. Design
  3. Testing
  4. Initial Migrations
  5. Early Adopters
  6. Bulk Migrations

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

Nexus supports the following protocols for access:
  1. IMAP (SSL/TLS)
  2. POP (SSL/TLS)
  3. Outlook Anywhere (RPC/HTTPS)
  4. Exchange Web Services
The first two protocols above are not suitable for the migration process as they do not allow delegated/impersonated access to the mailbox. Nexus also does not support direct unencrypted MAPI connections and this should be taken into account when selecting any migration software.

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

Generally IT Services may provide:
  • Standard training courses for departmental/college groups
  • Web-based documentation on configuring software for use with Nexus
  • Web-based documentation on using Nexus
  • Second and third-line support services via the IT Services Helpdesk and Nexus Team, after first-line support has been supplied by local ITSS
  • (There are also some historical, post-Herald, slide decks which may assist with custom training by the unit)

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

Nexus supports the migration of four primary data types:
  1. Email
  2. Calendar
  3. Contacts
  4. Tasks

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.

There are two other data types which may also be migrated to Nexus, most likely outside of the mailbox migration process. These are:
  1. Address list (Global Contacts) meta-data
  2. Groups/Distribution lists
Address list (Global Contacts) meta-data: Liaison with IT Services registration or the Nexus team may be necessary if this meta-data needs to be amended before or during the migration. Such meta-data includes:
  • Display Name (Display names on project accounts must make sense in a whole-University context, i.e. not "Reception" or "Accounts")
  • Street Address (overwritten if user moves department)
  • City (overwritten if user moves department)
  • Province (overwritten if user moves department)
  • PostCode (overwritten if user moves department)
  • Business Phone Number
  • Pager Number
  • Fax Number
  • Mobile Number
  • Job Title
  • Office
  • Manager
  • Assistant Name
  • Assistant Telephone Number
  • WebPage
Many of the fields above are not routinely used, but they may be, depending on the needs of the migrating unit and if a system is to be put in place with the aim of keeping such information up to date in an automated or semi-automated manner. All other data in the GAL is reserved for update only by Nexus/Registration automated processes.

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

Any migration is seen as a collaborative effort between IT Services and the local unit. Due to the limited size of the Nexus Team and the pressures of other work, the resource that IT Services has available to put into a unit's migration project is limited. As a guide, IT Services will endeavour to provide:
  1. An initial consultation to discuss the migration process (The migrating unit is expected to bring details of their current system including number of accounts, groups and relevant sizing information. An outline timetable would also be desirable.)
  2. A technical consultation
  3. An overview of an appropriate migration process
  4. Contacts in other University departments who have either migrated from a like system or will be migrating from a like system
  5. Advice and possibly migration accounts as laid out in Migration Software/Hardware and Administrative Access
  6. Best-efforts assistance before, during and after the migration

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.