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 :)

There is nothing to install on the customer side. 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. 

At this time we do not expect to give access to the software to allow running it inside an organisations own GCP environment. 

So, what do we store? 

DRIVE

Long term 

Nothing except stats regarding number of scanned and migrated files and time to do so, date of migration - domain anonymyzed

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 

MAIL 

Long term 

Nothing except stats regarding number of 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 scanned and migrated contacts and time to do so, date of migration- not domain connected

DB

Contact and contacts label IDs

In memory

Content of contact. 

CALENDAR

Long term 

Nothing except stats regarding number of 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

In Memory

Event and Calendar details and permissions