This quick start guide provides you with the basic information to configure CloudMigrator for a migration from G Suite (Google Apps). It is highly recommended that you read the application documentation in full for your platforms in order to understand all of the options available to you during a migration. While the default options are recommended for the majority of organisations CloudMigrator gives users the ability to customise their migration experience. The following are some of the Advanced Options available to customers migrating to GSuite. Changing some of these options can change the way data is migrated.
• Force Appointment Acceptance – set this to true to force all appointment recipients' attendance as confirmed.
• Appointment Visibility – set the visibility of all appointments. Original will use the privacy setting from the source system, while the other settings will override the original setting and set the specified visibility,
• Maximum Attendees – set the maximum number of attendees for any migrated appointments.
• Default Calendar Timezone – set the default calendar timezone to use for recurring appointments which have no timezone set in the source system and where the target Google calendar is in UTC.
• Send Individual Events – send appointment events as individual items rather than as a batch. Performance is slower than in batches, but may help with some rare issues with rate limiting.
• Color Categorized Appointments – if the appointment had a category in the source system, apply a colour to all appointments of that category
• Migrate Attachments – Migrate appointment attachments to Google Drive and share with attendee.
• Migrate to 'My Contacts' – migrate personal contacts to the 'My Contacts' group rather than only to 'All Contacts'.
• Send Individual Contacts – this should generally be left to true, while slower than batch importing its much more reliable.
• Collection Naming Scheme – when attachments or files are migrated to Google Drive, choose the collection label scheme that will be applied to the migrated documents. Choose from:
- Folder Name and Collection Label – migrate documents into a collection based on the folder name the attachment or document originated from, and also apply the collection label specified in 'Collection Name'.
- Folder Name – migrate documents into a collection based on the folder name the attachment or document originated from.
- Collection Label – migrate documents into a collection specified by 'Collection Name'.
- None – do not apply a collection label. This will essentially explode all folders, showing all folders and files on the root.
• Use Cached Items Mapping – use cached item mappings when migrating to Drive. (Not applicable for Google to Google migrations)
• Collection Label – specify the name of the collection label that will be used when 'Collection Label Scheme' specifies that a collection label should be applied to migrated documents.
• Preserve Modified Date – attempt to preserve the modified date during a migration
• Allow Non-Google Sharing – allow permissions to be added for users without Google accounts by sending notification emails to those users. Note this can result in many emails being sent to any non-Google addresses.
• Maximum Results Per Request – the limit on the number of results returned when listing files using the Google Drive API.
Document Options (File and Attachments)
• Convert Text – where possible, convert text and word documents to the Google Documents format
• Convert Spreadsheets – where possible, convert spreadsheets to the Google Documents format
• Convert Presentations – where possible, convert presentations to the Google Documents format
• Convert Drawings – where possible, convert drawings (*.wmf) to the Google Documents format
• Convert OCR – where possible, convert images using OCR
Exceptions when converting
- When migrating from Google Drive to Google Drive, conversion will not occur
- Legacy Microsoft file formats (.doc, .xls, .ppt) may be rejected by Google in the form of 400/500 errors. The solution to this is to either (a) retry or (b) disable conversion and retry.
• Archive Inbox Email – Do not place migrated email from the inbox into the inbox within GSuite. Instead the email will have a label of 'Migrated Email' applied.
• Apply Inbox Label to Sub-Folders - When a message from the source system was in a folder in the inbox, create the message with both 'Inbox' and 'Folder Name' labels. Set to False to just create the folder label.
• Modify Sent Address – for sent messages, if the sender does not match the email address of the destination account, modify it to match. This is to allow for sent items to display correctly in the GSuite interface. Default is true.
• Maximum Batch Count – specify the maximum number of messages in a single batch. Specify 0 to let the tool automatically allocate batches. Only applicable for immediate migrations.
• Email Transfer Delay – specify the number of milliseconds to wait between sending messages.
• Email Thread Count – the number of threads, per user, handling email transfer.
• Use Limited Scopes – for email migrations use Limited Scopes. This requires the following scopes to be enabled : 'https://www.googleapis.com/auth/gmail.labels' and 'https://www.googleapis.com/auth/gmail.insert'
• Explode Message Labels – by default, if an email message is contained within a folder structure the label applied to that message will be the same as the folder structure (e.g. 'Personal Folders/My Folder/My Other Folder'). Setting this option to true will create a label for each of the folders (e.g. for the case described, labels of 'Personal Folders', 'My Folder' and 'My Other Folder' will be applied).
• Create Sub Labels – create all sub-labels for labels within a message. For example, if a message has the label 'toplevel/midlevel', create both 'toplevel' and 'toplevel/midlevel' labels. This is specifically designed for use with nested labels.
• Multi-Server Drive Migration – use distributed locking to allow for Drive migrations to be performed from multiple servers. This can be disabled if using only one server for migration.
Team Drive Options
• Team Drive Default Organizers – optionally, specify a list of existing user email addresses that will be assigned as organizers to Team Drives being migrated to. These organizer accounts will then be used to improve the performance of the migration. In the default case the G Suite admin user account will be used to perform the migration to Team Drives, but specifying multiple users here improves throughput by utlizing multiple organizer accounts simultaneously.
• Remove Team Drive Default Organizers - Enable this option to remove any users specified in Default Organizers
• Team Drive File Permissions – when adding permissions to files within Team Drives choose where these permissions will be applied. Choose from 'File' (the default), 'Root' (where all permissions will be applied on the Team Drive itself and thus inherited down the whole tree) or 'None' (no permissions will be applied)
• Team Drive Folder Permissions – Team Drive folders cannot directly have permissions. Choose whether to apply permissions that apply to folders from the source at the root of the Team Drive, or not at all.
• Write Team Drive Permissions CSV – write a CSV file describing the permissions that were applied, or would be applied when migrating to Team Drive
• Team Drive Same Domain Migration Operation – when migrating from a Google Drive folder into a Team Drive choose whether to copy the files, or to move them. Note in the case of a move, the skeleton folder structure of the source folder will remain
• Migrate Team Drive Members - Migrate Team Drive members when migrating Team Drive to Team Drive
• Check Users/Resources/Groups Exist – set this to false if you do not want to check if users, groups or resources exist in GSuite (useful for testing exporting without creating accounts in GSuite).
• Create Users/Resources – if users, groups or resources (supported source systems only) are not present within the Google domain, create them. If users have not been pre-created within the Google system then this can be set to true to have the migration tool create the users. If the users have not been pre-created and this is set to false then the migration process will fail. Note: Setting this to true requires that the Admin SDK is enabled for the Google domain and also that all details are provided for each user, including name, given name, family name and password. Failing to provide any of these details will cause the creation process to fail for that user. It is generally recommended that users are pre-created in the Google domain before processing with the tool. For resources and groups, only the Resource/Group Name (and Import/Export Names) are required.
• Change Password on Login – force users to change their password on next login.