Google Workspace Implementation & Setup

Verifying your domain and planning the DNS and MX changes; creating users with a naming convention that will scale; building the organisational unit and group structure that policy depends on; designing Shared Drives owned by the organisation rather than by individuals; setting the external sharing policy deliberately; applying a security baseline including 2-Step Verification and admin role separation; deciding endpoint rules; and publishing SPF, DKIM and DMARC. Then rolling all of it out without interrupting trading, and handing over documentation your own people can work from.

Implementation builds the system: structure, policy, security and access. Migration moves what you already have into it — mail, contacts, calendars and files from your current platform. On most projects the two run together, because there is no point migrating data into a tenant whose structure has not been decided. If you are starting genuinely fresh with no existing system, you need implementation and no migration at all.

The technical build of a straightforward tenant is a matter of days rather than weeks. What sets the real timeline is how quickly the decisions get made on your side — how open sharing should be, who holds admin, whether personal devices are allowed, how long data is kept. Organisations that answer those in a single session are live far sooner than ones that answer them over a month, regardless of size.

Yes, and it is a common request. The usual picture is a tenant bought direct and never configured: everyone in one organisational unit, external sharing wide open, super-admin on a single personal account, company files sitting in individual Drives and DKIM never published. Remediation is scoped like an implementation but sequenced more carefully, because people are already working in it and changes have to land without breaking access they rely on today.

Very little, if it is sequenced properly. Most of the configuration happens before anyone is moved, and the recommended approach moves a small pilot group a week or two ahead of everyone else. The moment that genuinely needs coordinating is the mail cutover, which is scheduled for a quiet window. What causes disruption is not the technical work — it is people arriving on Monday to changes nobody warned them about.

We build the structure, but you decide what it should be, because it has to match how your work is actually organised rather than how an outsider guesses it is. In practice we run a short session to map out how files are grouped and who needs access to what, then build and populate it. Getting this right during implementation is far cheaper than moving thousands of files between Shared Drives later.

Then say so, and we will be straightforward about whether you need us. A three-person team that only wants domain email can reasonably do the setup themselves, and we would rather tell you that than sell you a project. Implementation earns its cost where structure, policy, compliance or staff turnover are genuinely in play.

A short, role-specific session at rollout is part of the work — what changed for that person, where their files now live, and how Shared Drives differ from emailing attachments. It is deliberately not a product tour. Deeper adoption training is available separately for organisations that want it, but the brief version at cutover prevents most of the support load that follows.

You do, always. The super-admin accounts belong to your organisation, and the handover documentation sets out who holds which role and how to recover access. We keep whatever access you want us to keep for ongoing support, and none if you would rather run it yourselves.

It is scoped on user count, how much structure is genuinely needed, and whether a migration runs alongside it. We quote it as an explicit line next to the licences rather than folding it into a rate, so you can see what each part costs. The requirement call and the quote are free.