How does this work?
A quick walkthrough
The migration tool is provisioned in a GCP project reserved for the customer who will get an IAP protected access to the web server where he will then be able to control the migration and it’s status, or we do everything for you 🙂
Alternatively the user can install the tool in his own GCP environment via a script, in this case no IAP protected acces is provided.
We might in the future provide a small tool which can be run by the customer to analyze the source environment and define the licensing needs.
The migration itself will be run inside the provided GCP environment.
So, what do we store?
The following data is stored on the migration servers (wherever they are located), the long term data is stored as statistical information on JuLu Soft GmbH own servers.
DRIVE
Long term
Nothing except stats regarding number of users, scanned and migrated files and time to do so, date of migration – domain anonymized
DB – deleted after migration + retention time defined by customer (no less than 14 days for migration acceptance)
For each file – id, name, owner, parent folder, all permissions, logs and errors
In Memory
Nothing more than in the DB
Long term
Nothing except stats regarding number of users, scanned and migrated mails and time to do so, date of migration- not domain connected
DB
For each user which month has been migrated, ID of mails, labels their IDs and label colors.
In memory
Content of emails during migration and associated metadata
CONTACTS
Long term
Nothing except stats regarding number of users, scanned and migrated contacts and time to do so, date of migration- not domain connected
DB
Contact and contacts label IDs
CALENDAR
Long term
Nothing except stats regarding number of users, scanned and migrated events and time to do so, date of migration- not domain connected
DB
IDs of events, calendars and their associated migration status