Cloudiway’s site migration solution helps businesses perform elaborate technical migrations through a simple SaaS interface. As a result, site migrations require no additional software installation or overhead, and migrations can be performed securely and quickly.
The Cloudiway platform is flexible enough to support all types of migration paths. Your migration strategy will depend on your business setup, type and size. Whichever migration path you choose, Cloudiway provides all the essential features such as site content, permissions, site layout and URLs (included rewrites where required). Delta passes are also available, which means you can complete a migration to capture any changes since the initial pass.
For more information about security, please refer to this article.
For more information about migration performance, please refer to this article.
4.1. What can be migrated?
When migrating from Google Sites to SharePoint, the following site items can be migrated:
The platform supports delta migration which means that modifications (new items and updates) are propagated between passes (no deletions).
4.2. Migration limitations
Google Sites and SharePoint site are set up differently, which makes it difficult for some elements to be migrated successfully.
Google Site pages are organized in a tree hierarchy where pages can contain sub-pages (such as http://www.mysite.com/mainpage/subpage. SharePoint stores each site’s pages in a flat library; to avoid page naming conflicts, Cloudiway migration platform renames Google Sites pages as ‘mainpage-subpage’.
Google Site menu depth is unlimited, whereas, by default, SharePoint is limited to two nodes. By default, Google Site menus with a depth of more than two nodes cannot be migrated.
The Google menu control can contain text. SharePoint menus cannot, so text content in the Google Site menu control is lost.
Google gadgets that do not have web part equivalents are not migrated.
Announcements are migrated to SharePoint discussion boards. However, discussion boards do not support attachments. To work around this, announcement attachments are migrated in a SharePoint library with the post title.
Important note before migrating Googles Sites: Embedded Drives
Google Drives can be embedded in Google Sites making the migration of files, permissions and the assignment of an owner more complex than for standard migration.
By default, Cloudiway migration platform will not migrate the embedded Google Drives. However, there is a way to migrate embedded Google Drives by following this process:
Prior to the Google Site migration, it is mandatory to run a file audit of all the Google Drives. This is in order to build the list of Drive documents and respective owners.
Follow the below process:
1) Perform an audit of the Google Drives with the File migration tool (requires Cloudiway file migration licenses for each Google Drive)
2) Migrate the Google Sites
3) Migrate the Google Drives
Read more details about how to migrate Embedded Google Drives in this article.
We strongly recommend you use Cloudiway’s file migration tool in conjunction with the site migration tool to achieve the best migration results possible. Please see our other documentation for more details about how these two products interact.
This guide is aimed at experienced system administrators who are capable of connecting to remote systems and using a variety of administration tools.
Although we provide support for our own products, we do not provide support for third party products such as PowerShell or server administration of Google or Microsoft products.
If you are concerned you might have any difficulty completing these steps, please consider a solution with our consulting team, contactable via firstname.lastname@example.org. This will ensure a fast, costeffective and stress-free implementation.
5.1. Before you start
Before you start, you will need to ensure you have the details outlined in the following table.
|Cloudiway login||Stores details and provides communication between the systems you already use.||https://apps.cloudiway.com|
|Our extensive knowledge base is always accessible, with videos, troubleshooting tools, samples and more.||https://kb.cloudiway.com|
|Google Admin console||The Admin console is where administrators manage Google services for people in an organization.||https://admin.google.com|
|SharePoint Tenant administrator account||Account with Sharepoint Tenant administrator that bypasses SSO and is able to authenticate using username/password credentials, preferably with the format:
|We recommend you create an account with admin access especially for migration. After all migrations are complete, simply delete this admin account.|
To ensure successful migration, we also recommend that you prepare any mapping tables for users and groups in CSV format, ready to upload later on.
5.3. Permissions Pre-requisites
For setting up the pre requisites, you need a tenant administrator account at both the source and target.
In Google, the tenant administrator account will be used to setup the service account permissions.
In Office 365, the tenant administrator account will be used to setup the graph API application.
https://www.google.com/calendar/feeds/, https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/drive.readonly, https://sites.google.com/feeds/
NOTE: 1. Each scope must be separated by a comma.
2. Some scopes require slashes (/) at the end and others don’t: please use the above strings. 3. If you add another scope later, existing scopes will be removed: you need to add the whole list at the same time.
7. Click on the Authorize button
8. You can check that the scopes were successfully registered by looking for the names next to the client ID.
You need an Azure Active Directory Application with relevant permissions.
To proceed, please follow this “How to create Azure Apps Registration” page.
Graph APIS requires application permissions on groups, users and sites.
For CSOM access, the migration account must be SharePoint administrator.
6.1. Create your G Suite source connector
For Cloudiway to migrate your sites, it needs to be able to communicate with both your source and target domains. To do this, Cloudiway uses connectors, which are configured on apps.cloudiway.com. You will need to set up a connector for each source tenant and each target tenant. Follow the steps below to configure a G Suite source connector.
6.2. Create your target connector
With the source connector now configured on the Cloudiway platform, it’s time to create and configure the target connector. Follow the steps below to configure a SharePoint Online target connector.
6.3. Import sites with the Get Sites command
The Cloudiway platform provides a tool called Get Sites which returns a list of all sites from the domain you added to the source connector (using the admin credentials you supplied in the source connector). This is a useful tool which provides you with a complete picture of sites to be migrated.
You should therefore run this tool prior to site migration to avoid having to manually enter details of each site: any syntax errors or spelling mistakes will prevent Cloudiway from finding the intended site. This is by far the simplest method of listing the sites to be migrated.
6.4. Import sites with the Get Sites command
The Get Sites tool will have captured as many source site details as possible for you, to help avoid spelling mistakes or missed sites. However, it cannot specify target site details.
6.5. Complete target site details
With all sources and target site collections added, you can pinpoint specific target locations within site collections to obtain your preferred site structure at the target. You can also delete sites that don’t need migration, configure individual sites and assign licenses.
Before any migration can start, you must assign a license for each source site. You can purchase site licenses these within the Cloudiway platform (or contact email@example.com for further information), and these will be displayed on the License dropdown after purchase.
Logically, you need to add a target connector from the Target dropdown list before migration can begin, as well assign any target site collection locations to your source sites prior to migration.
Remember, you can manually change each site’s name at the target, as well as choose whether to migrate directly to the root site of the collection. You can use the Target site relative URL field to preview the final site URL (relative to the target domain) each time you make a change to the target fields.
Note: You can assign a target connector and collection by entering into the details of the site and editing it (See above).
You can also assign a target to multiple sites from the Action bar at the bottom of the screen. To blanket assign a connector, go to the Manage menu and select Assign Targets (this will apply to all sub-sites).
To blanket assign a collection, go to the Set Collection menu and select a collection from the list.
To blanket assign a license, go to the Manage menu and select Assign Licenses (this will apply to all sub-sites).
6.7. Import or create a mapping table of user details
In order to migrate access rights for the list of users who have access to each source site, a mapping table of users must be defined. Office 365 security groups rights can also be migrated using a mapping table. A list of mail users is used as mapping tables as it defines who has access to the different sites. It is also used to migrate metadata for files and folders.
You can upload a user or site list via CSV, use Cloudiway’s automated Import Users tool, or manually add each user on the Cloudiway platform.
6.7.1. Option 1: CSV import
If you have a CSV file of all your site users and another one for groups, you can upload the files to Cloudiway. The files must have the following fields in the header row:
User CSV: FirstName;LastName;SourceEmail;TargetEmail
Group CSV: Name;SourceEmail;TargetEmail
If you perform more than one upload, any CSV data already uploaded will not be overwritten by following uploads. Therefore, duplicates can occur. Sample CSV files are available to download during the steps below.
6.7.2. Option 2: Create a single user
Many of our first-time customers create a single user and/or group for testing purposes. This provides a means of watching the migration process without affecting all users. Single users and groups can also be created for migrations affecting just a few users.
6.8. Perform an audit
Cloudiway provides an auditing tool which will help identify potential errors prior to migration, such as unfound sites or broken items. We recommend that you run this audit as many times as required prior to migrating to ensure your migration list is fully prepared and ready.
6.9. Perform preprocessing
Cloudiway provides a preprocessing tool that will set automatically all the required permissions at the source and at the target and provision the groups and teams at the target.
What does the preprocessing tool?
At the target:
At the end of the preprocessing, the status of the migration is set to “Not Started”. The sites are now ready to be migrated.
6.10. Activate and monitor your migration
Now that you have performed all the pre-migration steps within your tenants and within Cloudiway, you’re ready to migrate. We recommend you run a test migration on a single site first to check that your configuration produces the outcome you expect.
To start your migration, select the site you wish to migrate and click on the Start button. Your batch will be scheduled and will begin as soon as resources are available.
Cloudiway provides an extensive knowledge base with many resources, including common error messages, video guides and downloads.
Please visit the site migration knowledge base area here:
Please visit the entire knowledge base here (where you can search for keywords or read through topics): http://kb.cloudiway.com/
The knowledge base also contains information on how you can ask for further support, should you require it.