Whilst the migration from the OUCS-provided Herald email service is being undertaken by OUCS, we recognise that there are a number of units across the university looking to migrate to Nexus from locally provided solutions. This document sets out the responsibilities of OUCS 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 OUCS 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 OUCS 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 OUCS support for such activities (where feasible). 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
OUCS will provide advice and support regarding the purchase of any specialized migration software. OUCS will also provide a limited number of test accounts in a development environment should the unit wish to run some migration tests prior to committing to a software purchase. OUCS are happy to provide those migrating from systems similar to Herald (IMAP only) with assistance in using the tools utilized by the Herald migration process.
In addition to the assistance with the selection of migration software, OUCS will provide advice and support for the purchase of hardware on which to run the migration process. As a point of comparison, OUCS 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 project, and OUCS, 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 the project, and OUCS, are not funded to provide hardware for the migration process.
4. Methods of Access
For access via Outlook Anywhere, WebDav or Exchange Web Services an administrative account with delegation/impersonation rights over the target mailbox(es) will 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.3 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 has been put 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 OUCS will supply the unit with an account with the appropriate level of access to insert items into target mailboxes. Preferably this account would only have rights over an individual mailbox for the time taken to migrate the account and no longer. In reality access will be granted on a daily basis to the target mailboxes for that day's migrations.
For client support purposes OUCS will provide ITSS with access to a user's mailbox if that user has contacted OUCS to confirm that they are happy for this action to take place. Access will be granted for a specified period agreed with the mailbox owner. 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 currently use administrative access implicitly while performing user support functions, OUCS 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).
OUCS 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
OUCS will provide a limited number of test accounts on a development system for initial/preliminary testing. OUCS will also provide a limited number of test accounts on the live Nexus system for use when the migration process has been tested such that OUCS are satisfied that the risk to the live system is minimal.
9. Account Provisioning
All members of the University have been provided with 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 needs to 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. OUCS will provide appropriate list of accounts if required.
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 at £1.50 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.
For example, in the migration from Herald, the tool used had difficulties migrating certain folder names and thus all users which folder names of this type on Herald needed to be contacted in advance and asked to modify their account to ensure it could be migrated.
Groups/Distribution lists: Groups should be evaluated to determine if they are also solely in a mailing list capacity or if they are also used for authorization decisions. The Nexus service is waiting on the central GroupStore service to deliver user-customizable groups to Nexus, as well as other central services. In the meantime groups/distribution lists will be migrated into Nexus only if they are used for authorization. Other groups, used only as email lists, should be migrated to the OUCS mailing list service. Group maintenance will be manual by a request to the Nexus Team. Units should be aware that they will 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. OUCS Resources
13. Other Considerations
Automated Systems: Automatic monitoring or other system process 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 too disimilar form some current configurations and is entirely acceptable. Carful attention should be paid to mail routings in this setup and we strongly advise units to utilise the Oxmail service for routing their users' email in these circumstances.