How do I implement G Suite in my company? As a Google Cloud Premier partner we often get questions like this about the Google G Suite implementation methodology we use to migrate our customers to G Suite. Companies opt to go for G Suite because they want to enhance the way their employees collaborate, communicate and get stuff done. So for a big part, a G Suite implementation is a change management project. But of course there is also the technical side to it. You can find the basics of the technical aspects of a G Suite deployment in this blog.
A lot of companies would say it is one of the easiest projects from a technical perspective. We wouldn’t say a G Suite implementation is extremely easy, but it’s not rocket science either.
Let’s dive in the different technical aspects of a G Suite implementation that need to be carried out well for a successful implementation. Please note that this is not an exhaustive list of activities.
Provisioning is everything related to the creation of domains, users, distribution lists, shared mailboxes and calendar resources.
The very first thing you need to do when deploying G Suite is verifying that you are the owner of the domain, and potentially add additional domains to your G Suite console. The verification of the primary domain can be done by following these instructions and adding additional domains can be done by following this guideline.
You can very easily create the users directly in the admin console by following these instructions, which is perfect for small and medium businesses. Large enterprises mostly opt to sync their LDAP with G Suite through the Google Cloud Directory Sync (GCDS). GCDS is a tool offered for free and allows businesses to continue to manage their metadata in the LDAP.
From distribution lists & shared mailboxes to Google Groups
Distribution lists and shared mailboxes are called Google Groups in Google. These Google Groups can also both be managed directly in the Google Admin console and via GCDS. Here we see that most companies opt to manage their users directly in G Suite because this information isn’t being used in any other application. You can create Google Groups by following these instructions.
Calendar resources (meeting rooms that can be booked, for example) should be directly managed in the Google Admin console. This can be done by following these instructions.
Authentication and system access
When getting started with G Suite, you also need to ask yourself how people should connect to their G Suite environment.
If you already have a Single-Sign-On (SSO) solution in place, you’re probably going to prefer to authenticate with your existing SSO. G Suite offers you the ability to authenticate with SSO, but your solution needs to be SAML 2.0 compliant. You can follow these instructions if you want to configure your SSO on G Suite.
G Suite also offers its own, best-in-class authentication mechanism for this SSO purpose. So if you don’t have an SSO yet, you can perfectly use the standard G Suite authentication mechanism. This authentication mechanism can be extra secured with 2 step verification. If you have an Active Directory in place, you can even sync the Active Directory passwords with Google so users can use the same password as they are using to login on their laptop. The tool used to sync passwords is called G Suite password sync.
Mail routing approach
Depending on the size of your organisation, you might choose to deploy G Suite in a ‘big bang’ or in a phased approach. If you opt for a big bang, please jump to the section of Direct delivery.
A G Suite deployment in large projects is done in three phases. The first phase is a sort of pilot phase where the IT teams start using G Suite. In this phase you are going to opt for split delivery where the MX record keeps pointing to the legacy MX. Mails are forwarded through a shadow domain for the IT people:
At this stage, it is also important to configure G Suite’s SPF record.
During the second phase of your implementation project, you are going to onboard some early adopters in your company, which account for 5% of the population. These people will help you support the users that are going live in the last phase. During the early adopter phase, you will want to opt for dual delivery where the MX records are switched to G Suite and mails are forwarded to the legacy server if the person isn’t known in G Suite:
In the last and final phase, or in a ‘big bang’ approach as explained earlier, all emails will be delivered directly into G Suite:
When moving from a legacy system to G Suite, you probably want to migrate your existing data to G Suite. Luckily you can really migrate all your data from almost any platform to G Suite. So far, we have been using a tool called Cloudmigrator to execute data migrations because Google didn’t offer an enterprise grade migration tool.
Google has however launched their own tool for this purpose called ‘G Suite Migrate’ in Beta, and we can’t wait to give this tool a go in the near future.
In general, all migration tools work the same way. The tool is installed on a (virtual) server and has access to both the legacy platform and G Suite.
At Fourcast, we organise the go-lives of our customers always on Friday afternoon. We first switch the mail routing for the people going live and then start the migration.
Next to provisioning, authentication, mail routing and data migration; we could also talk about some extra technical activities like networking, mobile device management and Google Vault. But these topics are rather optional in your G Suite deployment.
As you can see, the basic setup of G Suite is rather straightforward. But you do need some technical knowledge to do this correctly. Also don’t forget to think about the change management in your G Suite deployment: this is very important if you want your implementation of G Suite to succeed!
How to approach the change management of your G Suite deployment?
Questions about any aspect of a G Suite implementation? Drop us a line, we’re happy to help!