Google Apps for Education - Rating Our Transition - The Mistakes

Image by colin_n via Flickr

So in a previous post I shared what went well with our transition to Google Apps for Education from Firstclass. I would say that we did many, many things well, but we did make some mistakes. In the spirit of openness, transparency, and a hope that someone out there will learn from our mistakes, let me elaborate on where we failed here in this post.

Some data about our transition (may be helpful to compare to your transition for scale):
Number of accounts transitioned from Firstclass to Google: 550
Number of faculty/staff accounts: about 125
Number of student accounts: about 425
Years our school had used Firstclass: I believe around 10

1.  We made promises we couldn't keep - Particularly in the area of Firstclass conference replication and data migration. Firstclass has this tool called "Conferences" that some of our users really liked. Prior to the transition we told people that Google Sites along with mail groups would give them the same functionality. The truth is that Google Sites doesn't do the same exact thing that Firstclass conferences, yet we promised folks that they would. Secondly, we promised that all data would migrate over, including calendars, contacts, and mail. We made a big mistake here. Firstclass is so horribly broken in terms of IMAP and other systems standards that it simply wasn't possible to automatically migrate sub-folder mail content from firstclass with the push of a button. In retrospect we should've tested data migration more thoroughly prior to announcing that mail content would be migrated over from the old system to the new. Don't make promises you can't keep if you are heading in this direction.

2.  DNS Preparation - we were ill prepared with new DNS entries up and ready to go for all of our new services. There were a few times after our cut date where our new mail address wasn't working internally...as a matter of act, it still isn't working, but thanks to Adam Contois we have some hack in place that does a quick re-direct internally.


3. Calendaring confusion - I can't say this is a mistake because we truly didn't anticipate that our entire organizational calendaring system would move over to Google Apps Calendar. Firstclass' calendaring is fairly wretched and we were using FinalSite's calendaring system which we purchased as a part of their web CMS. I don't think anyone who managed our calendars was particularly satisfied with Finalsite as the calendaring solution, so when Google Calendar came around we had some folks who were eager to try it out. Calendaring seems to be a real challenge in most organizations, and when we moved to Google Cal we didn't quite have our arms around how we were going to implement this as our organizational calendaring system. Luckily we had several folks step up (Mid, Dana, Katherine, Shannon) to build an excellent solution for our calendaring needs-they created an entire Google Site in our network that has all of the various calendars that our folks may elect to subscribe to.

We also have had some difficulties with the use of using Google Calendar for scheduling some of our resources like computer labs and rooms. We're still trying to figure this out at the time of this post and if we arrive to a solution I will share it out here.

4. Document Sharing - we didn't expect so many of our folks to use google docs to share information, which is absolutely great! However, many people are using Google Docs instead of sending attachments or placing the message right in the body. This is causing a bit of "Google Doc" fatigue. Google docs are great for collaborative writing, but when it comes to simply passing along information that you'd like people to read, attaching a document or placing the text in the body of the email is completely fine (or simply publishing the doc to a URL and sharing that URL is another good route). I'm going to create a little help document that helps people decide when they might consider sharing a google doc vs. sending a standard attachment. This isn't a huge deal, but some of our folks are experiencing a little Google Docs fatigue.

5. Network mail groups - we have way too many network mail groups. We have nearly 60 or so that we brought over from firstclass. We should've probably thinned this list down to a few dozen or so when we transitioned, but it proved easier said than done. I'd imagine as time progresses we'll only keep the highly useful ones around.

6. Client software for mail access - prior to the transition we talked to our folks about how they could use various mail clients like Mac Mail, Thunderbird, Outlook, etc. It is true that this is possible, but as a school tech department it is difficult to support all these various client software programs. We now have a policy that we only support web access to email...folks are welcome to configure a client, but they are pretty much on their own if they go this route.


7. Mobile support - we should've been clearer about how we were going to support mobile access. Outside of providing links to help documents and video tutorials that show users how to configure their iPhones, Blackberries, etc, we really don't have the bandwidth to support all of these various mobile platforms that are represented in our student, faculty and staff community. Luckily mobile access setup of Google mail is really easy, so we really haven't had to offer a great deal of high touch support for mobiles.


8. Under-estimation of support during for the transition - While we did have a transition support team of 8 faculty and staff or so, looking back it would've been best had we doubled that number with an appointed transition expert in each department. I'm a big believer in empowering community members to help each other out and our transition team went part of the way in making this happen.