Migrating to Office 365 from Google Sites Doesn’t Have to be a Nightmare

Google Sites, typically available as part of Google Apps for Work when used within large enterprises, is a team site service that has some functional overlap with content/collaboration platforms such as Microsoft SharePoint and Lotus Notes/Domino. Although Google Sites hasn’t been strongly promoted by Google since it was first released in early 2008, it has been used, especially in conjunction with Google Drive, for a range of enterprise content/collaboration needs. Several recent press articles (such as this VentureBeat article) reported that Google Sites has an impressive base of 240 million users.

As has often been the case with traditional SharePoint and Notes/Domino, Google Sites deployments tend to grow organically and sometimes out of control, with lots of creative custom site work (often by businesspeople rather than professional developers), little or no IT guidance or supervision, and, eventually, a large percentage of abandoned or little-used sites.

Google Sites deployments can create several challenges for enterprises migrating to Office 365. In this blog post, we’ll provide a brief overview of Google Sites, explain how Google Sites migrations can be as problematic as migrating complex Notes/Domino and SharePoint deployments, and highlight how CASAHL’s DART solution can greatly simplify and accelerate migration projects.

Google Sites: A Platform in Transition

Google Sites was unveiled in early 2008, based on technology Google acquired in late 2006 from a then-fast-rising startup called JotSpot, which had created an innovative extension of the wiki model. JotSpot went beyond basic wikis to address common content/collaboration needs, including a range of document-centric application types. In some respects, JotSpot was like a Web-centric and wiki-modernized version of Lotus Notes, making it easy for non-programmers to create non-trivial document workflow forms and applications. Little of the original JotSpot technology has been evident in Google Sites since Google acquired JotSpot, however.

Furthermore, Google Sites has in general seemed a bit resource-starved over the years, with infrequent updates and ambiguity about where it fits within Google Apps for Work, relative to Google’s many other content/collaboration offerings (including, for example, Google Groups, Google+, and, most recently, Google Spaces). As a further complication, Google also announced in June 2016 that it’s testing a new modern Google Sites that will replace the original Google Sites (now called “classic Google Sites”). We’ll revisit the latest Google Sites news momentarily, after a quick tour of the classic Sites service that has been broadly deployed within enterprises for many years.

Creating a new site in classic Google Sites starts with the option to start with a blank site or select from a list of templates:

The template list includes a mix of templates created by Google and the Google Sites community. For this overview, we’ll start with the project wiki template. After providing a few parameters such as the site name and selecting a site style, classic Google Sites creates the site and populates it with a mix of sample data and customization tips. Here’s the top part of a site home page created with the project wiki template:

There’s a lot going on here, with:

• Home page content in the middle, including sample content and a list of sample team messages

• Site navigation on the left-hand side

• A team discussion, below the site navigation section; joining the discussion switches to Google Groups (with a completely different user experience)

• A recent-activity section (empty, in this example) below the discussion section

In case you’re wondering about the “2103 days since project due date” in the example screenshot, it’s probably safe to assume that’s an indication of when the project wiki template was last updated.

The site home page continues with additional content and tips:

The to-do list is an example of a Google gadget (similar to a SharePoint Web part), in this case displaying a list of project tasks. The embedded Google spreadsheet is an example of using Google’s productivity apps for Google Sites page components.

Note that nothing in this example represents a traditional wiki, despite the site template name. While it’s possible to edit pages, other traditional wiki capabilities, such as CamelCase formatting conventions (e.g., linking to other pages or created new pages with text shortcuts) aren’t supported.

Editing a classic Google Sites page presents a number of options:

The “… More gadgets…” option presents another long list of choices:

Overall, classic Google Sites can be both empowering and overwhelming. Before taking a look at some common classic Google Sites enterprise deployment patterns, we’ll next take a quick look at the new Google Sites, which represents a completely new architectural foundation.

As of early July 2016, the new Google Sites was still in private beta testing. You can view a couple video walkthroughs of the new user experience on YouTube, such as How to use the New Google Sites – Tutorial 2016. The Google Sites Help Center is another useful resource to explore, with high-level guidance for both classic and new versions of Google Sites.

To briefly summarize what’s new, the new Google Sites model, relative to classic Google Sites, is a lot like the difference between the modern SharePoint authoring experience relative to traditional on-premises SharePoint (for more details on what’s new in modern SharePoint, see our post A Refined and Revitalized Role for Modern SharePoint).

In both cases, the new approach:

• Has a greatly simplified user experience, with clean and attractive page designs, pages divided into easily editable sections, and the ability easily insert images, documents, and links

• Has first-class support for mobile devices built-in; pages viewed on tablets or smartphones are automatically reformatted and optimized for the mobile platforms

• Offers far fewer but less convoluted customization options than its predecessor, with more emphasis on embedding content, especially resources managed in Google Drive apps or Office Online apps (e.g., embedding spreadsheet-based lists rather than using a basic table editor)

• Will run side-by-side with the earlier version (although viewing “classic” sites via mobile devices can be an eye-straining experience), which is one way to address the fact that the modern version is, both architecturally and in terms of related tools, a disruptive departure from the classic version

While some Google enterprise customers may opt to continue with their Google Sites deployments, CASAHL has been recently engaged in several very large enterprise migrations from classic Google Sites to Office 365 and/or on-premises SharePoint, and we anticipate that trend may become more widespread when classic Google Sites customers consider the compelling advantages of Office 365 and the inevitable complexity and disruption of continuing with Google Sites. As such, we’ll next review some common Google Sites migration challenges.

Deployment Dilemma Déjà vu

Perhaps paradoxically, considering its Web and cloud foundation, Google Sites enterprise deployment patterns are in many ways similar to the Lotus Notes/Domino migration patterns CASAHL has been addressing since 1993.

One common pattern is that Google Sites deployments grow organically and sometimes out of control. As with Notes/Domino, in many cases the new sites are created by businesspeople rather than professional developers. People working for enterprises that primarily use Google Apps for Work, for example, may discover that Google Sites can be used to address a range of team or project content/collaboration needs, often with little administrative overhead and no additional cost. When confronted with the choice of using an (explicitly or tacitly) approved service at no additional cost versus building a business case for acquiring and deploying a new platform or service, many enterprise employees opt to use Google Sites, even though it can be, at least in the classic version, a bit bewildering.

Another Google Site pattern that’s consistent with enterprise experience with Notes/Domino is the tendency to start with templates (system templates and “the nifty fifty” template set in Notes, many years ago, along with Notes community-created templates) and continue with custom development, again generally done by businesspeople rather than professional developers. This pattern can result in poorly documented and difficult-to-maintain sites that often can’t evolve to address changing business needs.

A related problem stems from a lack of IT guidance and supervision, with businesspeople sometimes making counterproductive form-follows-function fit choices because they haven’t done detailed requirements analysis or don’t fully understand the pros and cons of different templates for varying business requirements. It’s not unusual to see conversation (a.k.a. discussion) focused sites used for more document workflow-oriented scenarios, for example, or document libraries used to address what’s actually more of a conversation- or coordination-oriented team site need.

The form-follows-function-fit challenges often extend beyond basic content/collaboration scenarios to include business applications, as businesspeople left to their own devices can essentially cobble together site-based apps to address their business needs. One common result of this pattern is that users often capture and manage structured item lists in Google Sites (or, in a previous generation, Notes/Domino apps) that would be more effectively managed in a more traditional database management system (DBMS). This pattern can be considered path-of-least-resistance app and data management, as businesspeople go with tools and services with which they’re familiar rather than ones that are most effective for their needs and overall enterprise resource management requirements.

Over time, another consequence of often poor form-follows-function-fit site template choices, site and app development by people who aren’t professional developers, and a lack of IT guidance and supervision is that a large percentage of sites can go dormant, as users get frustrated with site shortcomings and look for other ways to accomplish their business activities. Many project-focused sites also end up abandoned when projects are completed, wasting resources, making it more difficult to discover useful content, and potentially exposing enterprises to compliance and audit risks.

To reiterate, these Google Sites deployment patterns are similar to enterprise patterns CASAHL has seen hundreds of times with Notes/Domino deployments, and the resulting migration challenges can seem just as daunting.

The Keys to Successful Google Sites Migrations

Fortunately, the same tools and expertise CASAHL has developed in working with enterprise migrations from Notes/Domino (and many other content/collaboration platforms and services) can be used with classic Google Sites deployments as well (since the new version of Google Sites was still in a private beta test phase as of mid-July 2016, this section refers to classic Google Sites as a migration source).

Going far beyond basic file migration, CASAHL DART addresses the full spectrum of migration requirements and accelerates successful Office 365 deployments by making familiar content and collaborative app resources available in the latest Office 365 tools. Although there are many architectural inconsistencies between Google Sites and Office 365, DART also embodies innovations that can automate the transformation of intricate and unusual Sites conventions (such as a wide range of Google gadgets) into optimized Office 365 deployments.

DART also preserves access control, metadata, and link-based relationships, so Google Sites deployments are migrated with their original contexts intact. For example, links in Google Sites referencing files managed in Google Drive can be mapped to SharePoint Online sites with links referencing files migrated to OneDrive. Inter-site links from Google Sites deployments are also preserved by replacing them with inter-site links to the corresponding new SharePoint Online sites in Office 365.

For enterprise planners who need to better understand the resources and risks in their Google Sites deployments, CASAHL’s Pre-Migration Assessment service provides a quick and cost-effective way to get a detailed inventory of a Google Sites deployment, along with preliminary migration recommendations and identifying potential migration blockers that need to be remediated. By identifying abandoned or little-used Google Sites-based resources, the Pre-Migration Assessment service can dramatically reduce the overall migration project scope.

CASAHL’s DART suite also offers a rationalization capability called DART Dashboard, using an Office 365 workspace in order to engage all migration stakeholders in a collaborative and qualitative review of the Pre-Migration Assessment results. DART Dashboard makes it easy to get all migration participants on the same page for setting priorities and project schedules. This approach also provides hands-on experience with Office 365, helping migration project participants understand its advantages relative to Google Sites.

CASAHL’s Fixed-Fee Migration Service (FFM) is a popular option for enterprises that are ready to begin their migration projects. Starting with the detailed plans produced during the assessment and rationalization activities, FFM is a highly automated and scalable service used to migrate content and template-based sites to Office 365 and/or on-premises SharePoint.

For enterprises with collections of highly customized and complex apps in their Google Sites deployments, CASAHL’s Application Recomposition Service can be used to disaggregate even the most complex Google Sites apps and recompose the related resources for optimized experiences in Office 365.

With a unique architecture supporting multiple migration sources and targets, DART can also be used to migrate resources to better form-follows-function-fit tools and services. Large structured lists previously stored in Google Sites pages, for example, can be easily migrated to more effective structured data management services in the Office 365 and Azure cloud platforms. In doing so, DART makes it possible for enterprises to gain more value from their structured data resources by making them securely available to a wider variety of apps and tools (e.g., for business intelligence scenarios using Power BI).

If you’re ready to make the move from Google Sites to Office 365 and want to fully leverage all of your content/collaboration resources in the new modern SharePoint platform, CASAHL’s migration solution is a uniquely powerful approach to assessing, rationalizing, modernizing, and migrating your legacy deployment resources. CASAHL supports a wide range of sources (Lotus Notes, traditional SharePoint, Google Drive/Sites, file servers and sharing services, and more) and flexibly leverages the powerful new tools in the modern SharePoint platform. Please contact us or visit our Web site to learn more about how CASAHL can cost-effectively accelerate and optimize your Google Sites migration to Office 365.