Version: 2020-02-20

Technical specifications

The migration service can be used to migrate or backup one or more user accounts (e.g. email or online storage accounts) that can be retrieved from a server.

For using the migration service, you will only need an up-to-date internet browser with JavaScript support. The installation of software on a local computer is not necessary.

The types of data that can generally be transferred include files, emails, address books, calendars, tasks, notes, and certain configuration settings. The data types that can be migrated in a specific case are displayed during the setup of the migration. In individual cases, they depend on the available data interfaces of the source and target servers and the scope of services purchased by the customer.

The following requirements, functionalities and limitations apply to the self-service migration tool. For larger projects, individual points can be adapted to customer requirements in deviation from the terms described here.

Requirements

  • The billing of migrations is done via so-called "voucher codes", which are provided in advance or can be purchased during the setup of the migration. The extent of functionality described in this document can be restricted by the voucher code used.
  • For the migration or backup, the user must provide a target account, which will be initially empty in most cases (but does not need to be). However, the target account must have enough free space to hold the data of the source account.
  • The target account must also be basically suitable to ingest the data of the source account. Individual providers may, for example, limit the number of folders or the number of items per folder.
  • When moving several related accounts (and possibly related concepts such as groups, functional accounts or resources), ideally all affected accounts should already be set up at the target provider before the migration is started. Otherwise, for example, folder permissions may not be transferred.
  • For access to the source and target account, the user must provide the necessary access data. This is usually a combination of username and password or an explicit authorization via OAuth and similar procedures. For individual systems, access via an administrator or migration user is also possible, so that the passwords of the individual accounts are not required.
  • In addition to selecting preconfigured providers, the user can also specify the source or destination server for a migration. These servers and especially the required data interfaces must be accessible via the Internet and have sufficient free network bandwidth (at least 10 Mbit/s). In addition, throttling settings and similar restrictions, such as at the firewall or software level, must be adjusted for the time of the migration. However, no guarantee can be given for the correct functioning of the migration service, as it is not possible to ensure detailed quality control for self-configured servers. Therefore, the migration should be prepared very carefully.
  • Due to the unavoidable imponderables of migration – especially due to the dependence on third parties (i.e., source and target providers) – generous test and buffer time should generally be planned for a migration.

Functionality

  • Once a migration order has been submitted, the migration executed in a fully automated fashion. The Internet browser is only necessary for the setup and for tracking the progress of the migration.
  • The customer will receive an email notification during setup, start, and completion of the migration.
  • During the migration, data will be copied from the source account to the destination account. The source account will only be accessed in a read-only fashion.
  • The migration service can only migrate data that is also stored on the server of the source provider and which can be read via the data interfaces used. Data that is only stored locally on the user’s computer will be not migrated.
  • During the copy process, the data retrieved from the source account is transferred directly to the destination account. The data will not be permanently stored by the migration service beyond that copy process.
  • Due to the variability of the source and target systems, as well as the data to be migrated, a complete and generally valid description of the scope of functionality is not possible. The following information provides an overview of the general system functionality. If more detailed information is required for the migration of certain data fields, we offer the possibility of a free test migration of partial data and, upon request in individual cases, the possibility of a free test migration of complete accounts.
  • Order
    • The customer can define a migration start date, which defines the earliest time when the migration should begin.
    • Otherwise, migration orders usually start a few minutes after ordering. For technical and organizational reasons, however, the start can be delayed - for example if many migrations have already been executed from the respective source or destination provider.
    • Furthermore, we reserve the right to delay migrations up to 24 hours. A special agreement is necessary for a guaranteed execution date.
    • If a migration order consists of several accounts, several of them are moved in parallel, depending on workload and configuration. Migrations that go beyond the respective parallelization are carried out following previously completed migrations.
    • Due to different interfaces for data access, the move of an account for different data types can be separated into several separate "jobs". Although these are presented in a bundled form, they are processed separately from a technical perspective.
    • Up to 14 days after completing a migration order, a free "delta move" can be started with a single click (unless this function is otherwise restricted). This will copy the new data created after completion of the original migration. Changes to already migrated data or deletions of data will not be synchronized. To use the delta migration, it is necessary that source and target accounts can still be accessed with the access data originally provided.
  • Server
    • The connections from the migration service to the source and destination provider are always encrypted by default. Suitable procedures (e.g., SSL or STARTTLS) are used in each case. An unencrypted connection will only be used if the source or destination provider does not support encryption.
    • The migration service supports a variety of different source and target systems. The available systems can be selected when setting up your own server. Due to the variety of versions, no complete guarantee can be given for functionality and correctness. It is advisable to carry out tests or to consult us in advance.
  • Folder
    • In the target account, folders and subfolders are created - as far as possible - according to the folder hierarchy of the source account. In some target systems, empty folders that do not contain any data are not created.
    • You can only migrate those folders that are visible and can be accessed via the respective data interface. Some source providers do not make all folders available via their data interfaces by default (for example: archives or certain views). In individual cases, the user can work around such limitations by making changes to the source account before the migration.
    • Individual target providers restrict the creation of folders or folder hierarchies in various ways (for example, by restricting the depth of folder hierarchies or folder names). If folders cannot be moved from the source account, they may be modified (renamed) or in extreme cases omitted. In the latter case an entry is created in the migration protocol.
    • By default, the migration service migrates only those folders and data that are directly associated with the specified account. In particular, data from so-called "Shared Folders" and "Public Folders" are not migrated by default. Migrated "Shared Folders" is usually not necessary, since their data is contained in other accounts that can be migrated separately.
    • For individual source systems, heuristics are used to detect "shared folders". For example, folders are considered "shared folders" if the owner/creator of the folder is different from the account owner.
    • Folders with deleted data or data classified as problematic (e.g. "Deleted Items", "SPAM") are in most cases not transferred because many target systems do not allow the import of such data.
    • System folders that contain redundant copies of data (e.g. the Gmail folder "All Mails") are usually not or only partially migrated to avoid the creation of redundant data.
    • Access rights of folders (Access Control Lists; ACLs) can be migrated for many systems if the assigned rights and the authorized users or groups are supported by the target system.
    • The display name of folders or folder names in source and target systems can sometimes differ from the actual folder name (for example, due to translations). This applies particularly to default folders in the respective system. The actual folder name may be adjusted as part of the migration if it can be expected that this will make it easier to use in the target system.
    • Individual systems allow you to show and hide folders. During the migration, folders can be explicitly made visible if it can be expected that this will facilitate use in the target system.
  • Data
    • As far as possible, data is copied to the target system in its unchanged original state with all properties, as fa as this is possible based on source and target system.
    • Especially the ownership property of data elements and certain time stamps cannot be transferred to all target systems.
    • In the case of individual properties that cannot be mapped exactly in the target system, the migration service tries to preserve them as best as possible. In the case of individual target systems, they may be added as comments/attachments to the respective data element.
    • Due to the data interfaces used in each case, it is possible that data and workflows (e.g., for inviting appointments) cannot be migrated exactly, even when moving between similar systems.
    • The migration service can make changes to data to enable its storage in the destination or to avoid undesired behavior of the destination server. The latter includes, for example, suppressing the distribution of the unintended notifications to third parties (e.g. read confirmations or appointment invitations). Changes to data can include the removal, modification or artificial creation of properties.
    • If no or ambiguous information on the time zone of different data elements is available, the migration service may use the time zone of the account or the default time zone defined in the migration order.
    • Source and target systems sometimes reference the same users via different identifiers (e.g. email address ot username). The migrations service tries to resolve which different identifiers identify the same users.
    • If the size of a single data item (especially emails or files) exceeds the storage limit of the destination provider, it is not migrated. The user is informed of this process in the migration protocol.
    • If errors occur when retrieving or saving data, the migration service will in most cases make several attempts, depending on the actual error pattern. If data can finally not be transferred, this is noted in the migration protocol. If a maximum number of errors (default value: 500) is exceeded, the migration will be automatically terminated as a precaution.
    • Individual providers allow the storage of the same data element in several folders in parallel. Depending on the source and target system, the migration service can migrate these data elements only once or in multiple copies.
    • If an identical data item exists more than once in a folder of the source provider, it may happen for technical reasons, that it is only moved once to the target provider. A data item is also classified as duplicate and is not moved if an identical data item already exists in the folder of the target provider.


Limitations

Some of the following limitations may be waived for a particular order upon special request.

  • The maximum duration of a single migration order is limited to 30 days by default. After this period the order can be cancelled automatically.
  • To secure operations, a single migration order is limited to a maximum of 100 accounts and a data volume of 1 TB (email accounts) or 5 TB (online storage accounts). However, a single account may not exceed the data volume of 50 GB (email accounts) or 100 GB (online storage accounts). These data volumes may be further limited based on the scope of services purchased by the customer. Please contact us in advance if you wish to carry out larger migrations.
  • By default, we do not migrate data elements larger than 10 GB (files) or 64 MB (all other data types) for operational reasons.
  • In individual cases, some providers may block access to services or locations that are unknown or unusual, even if the access data provided by the user is correct. In this case it may not be possible to carry out the migration.
  • Especially those providers with proprietary interfaces for data access can temporarily or permanently impede or even prohibit access for the migration service. In this case, it may not be possible to carry out the migration.

Please contact us for further options and details regarding the migration of shared and public folders.

Retrieved from "https://www.audriga.com/w/index.php?title=Self-service_migration/Technical_service_description&oldid=211"