| Status | PENDING STAKEHOLDER REVIEW |
| Owner | Gautier Todeschini, Beatrix Gabrielli, Cristiane Rocco |
| Stakeholders | James Kyndt, Frank Bolata, Boris Foiselle |
Issue
AODocs is a complex and customizable system embedded within Google Workspace, and there is not a simple/obvious way of migrating the AODocs libraries towards the Microsoft environment.
Recommendation
Option 1: Custom migration towards Sharepoint (semi-automated data migration, manual rebuild of complex features).
Background & Context
AODocs combines storage (on Google Drive), with advanced permissions management, metadata, and customization elements like workflows and scripts (in the AODocs layer or "envelope").
Metadata is contained both in the AODocs layer, and in the Google My Drive files that are owned by the libraries' service account ("storage account").
As of early November, there are 2115 AODocs libraries at Syensqo with various levels of complexity: 133 complex, 330 Intermediate, and 1537 basic.
Their migration process can be separated into 3 levels: data migration, metadata migration, and workflows & scripts migration (for Intermediate & complex libraries).
NB: AODocs library owners (and subsequent users) already went under two disruptions recently. Firstly in 2023 for the spin-off where most libraries had to be copied to split the data between Solvay and Syensqo, and Syensqo got the copies (with different links, amongst other impacts). Secondly, in S1 2025 during the separation programme as all libraries had to be moved to a new tenant to follow the Google Workspace separation - this created the same impacts (punctual freeze periods for cutovers, URL changes for files contained within the libraries, etc.).
Assumptions
Basic libraries can be moved to Sharepoint with a good level of automation of the migration process, and without losing any functionalities at target.
Intermediate and Complex libraries will require additional effort of rebuild, with PowerPlatform elements, to recreate their current functionalities (workflows, scripts, etc.).
In all cases, metadata must be preserved as they play an important role in the AODocs use cases (audit & compliance, version control, etc.)
Constraints
- Limited offer & maturity of 3rd party tools handling AODocs to Sharepoint migrations
- Metadata and logs must be kept as, for some libraries, they form part of compliance frameworks
- In all considered scenarios, the URLs of files contained in AODocs libraries will change (as the storage platform will change)
Impacts
Third party tooling requires an elongated pilot phase, and security validation.
Manual migration requires creation of complex scripting.
Options considered
Option 1: Custom migration towards Sharepoint (semi-automated data migration, manual rebuild of complex features).
Option 2: Third party tool migration & Rebuild of complex features
Option 3: Keep AODocs while changing the storage system from Google Workspace to Azure
Evaluation
Option 1: Custom migration towards Sharepoint (semi-automated data migration, manual rebuild of complex features). | Option 2: Third party tool & rebuild | Option 3: Keep AODocs while changing the storage system from Google Workspace to Azure | |
|---|---|---|---|
| Technical Feasibility | (Complex) For all libraries, coordinated between all project stakeholders (Syensqo, Altirnao, Folgo, Avanade, Microsoft Fast Track): 1) Export of metadata and history 2) Move a Google Shared Drive with Folgo 3) Fastrack migration towards Sharepoint 4) Custom script execution 5) Workflows recreation 6) Pilot and incremental execution | (Complex) 1) Export of metadata and history 2) Custom script execution 3) Workflows recreation 4) Pilot and incremental execution | (Complex) 1) Adjust library types to "DMS" 2) Copy files from Google Drive to Azure Blob storage, then delete files from Google Drive 3) Redevelop of custom scrips & workflows 4) Directory switch and libraries reactivation |
| User Impact | (High)
| (High)
| (High)
|
| Support Impact | (Medium) Less support impact as the entire recreation / orchestration is handled by COE | (Medium) Some incidents to expect depending on the outcome of the 3rd party tool migration | (Medium) Comparable to option 1 |
| Time to implement | (Very high) Requires an extensive pilot phase. Workflows & scripts inventory and assessment is time consuming Rebuild & testing with owners will span over several months | (High) Requires an extensive pilot phase. No guarantees on throughput speed or timeline Complex developments not handled by the tool would still need to be inventoried and recreated similarly as option 1 | (High) AODocs interface kept, but with some UX changes due to the change of storage platform (including URL change). |
| Security & Compliance | Scripting and custom coding follows the highest security standard, Microsoft validated endpoints and Azure security principles. Complex developments will require authorizations & cybersecurity assessments. | Requires third party tooling validation. Complex developments not handled by the tool will still require authorizations & cybersecurity assessments. | Complex developments will still require authorizations & cybersecurity assessments. |
Operational Complexity |
|
|
More dependency on Cloud Ops team for Azure Blob Storage management |
| Cost | (High) High external resource cost for Rebuild (400-500k€) Tooling cost (Folgo: 50k€) | (High) Medium resource cost Tooling cost (Ensentia) | (Very high) Migration costs similar to Option 1 AODocs licenses and managed services recurring costs still running |
Limited coexistence as the complex features can be rebuilt and tested in advance
Freeze period during data transfer (over a weekend)See also
LM01-KDD002 - Gmail Migration to Exchange Online
LM01_KDD006 - Google Sites migration strategy
[WIP] LM01_KDD00x - Personal Drives Migration to OneDrive