Firstly, you will have lots of questions from users, especially if you are going to only use the web interface, and drop Outlook completely.

I would, in fact recommend you drop Outlook completely, because it is not the same once disconnected from Exchange, and calendars especially don’t seem to work too well with it.

We only allowed the support team Outlook in the end, because they needed the Outlook functionality in order to work with the CRM properly.

Everybody else had to move to webmail based functionality, which caused major training headaches. My advice would be to meet with any teams affected before the migration, and explain potential pitfalls.

And the pitfalls?

Well, here are the ones I can remember:

1. Google uses tags instead of folders to organise emails. This can make things hard for users, but there is a lab item called ‘Nested Labels’ which can help, and will neaten up your emails.

2. There is no GAL. Although all of your contacts are there, you can’t pick them from an address book a la Outlook. You have to start typing and Gmail will try and find it for you. Once used, it will remember it, but it is quite frustrating at first.

3. Signatures are less flexible than in Outlook. Images are harder to insert, and may preclude the use of the offline mode.

4. Groups are MUCH different. Google groups, whilst being distribution lists, are also discussion groups that archive things sent to them. Be careful what you write. Using Postini also broke our groups and Postini had to supply a huge regex to allow group mail sending.

5. Management time was much higher initially than Exchange, due to users learning a new system, and learning how to use the management interface.

6. We had to configure a simple relay service in house to allow devices such as scanners and alerting systems to send emails via Gmail. Microsft SMTP service was used, and used TLS to connect to Google.

7. Different browsers behaved in different manners and there were lots of support problems for browser related issues.

8. Shared calenders wouldn’t work if Outlook was used.

9. Some users found Labs items to make life better, but this meant support calls for things I knew nothing about.

10. Filters, which work a bit like Outlook rules, can be a bit fiddly to set up.

11. Doing some things requires the use of Labs features.

Overall it wen’t well, and nothing was lost in translation, but I would urge anybody doing this to:

a) Don’t do it on your own, it needs management and techies looking over each others shoulders.

b)Plan Plan Plan

c) Engage one person from each group of affected users to ensure everybody knows what is happening and when, and how it will affect the way they work.

d) Read EVERYTHING Google has on the web about doing it, and check regularly for updated tools.

So we’ve done a test migration, and have our Exchange account forwarding to the new account in Gmail.

Once you’re satisfied, migrate a small group of trusted, possibly techy people, migrate them too.

Once you’re happy all is well, you can begin the migration of everybody else. Once the accounts are created and emails etc are migrated, and all users have forwarding enabled, you can then go through the process of making sure all the groups are set up with correct email addresses and aliases, and also ensure any aliases for users are added as well.

If you have external contacts, especially if they belong to groups, add them too.

If as we had, there are multiple email domains, don’t worry, when you add another, Gmail automatically adds aliases based on existing usernames/email addresses.

Although the migration will add users calendar data, it won’t add things like bookable resources i.e rooms, so you may also need to add these manually, and also manually recreate existing bookings.

Once all users are migrated, you can think about moving your MX records to point at Google.

Since DNS records can take anywhere between 24 and 72 hours to replicate, leave the forwarding on on your Exchange users until you’re sure no more email is being delivered. Use the standard Exchange tools to do this.

If you were unable to configure forwarding during the migration, or couldn’t make it work, you may well need to run the migration tool again, to ensure any missing items are synced up to Google.

If you are planning to use Postini, wait until you are happy with Gmail before turning it on, as it comes with problems of it’s own, too numerous for me to detail here.

Now all your users should be able to access Gmail through the web, and have email anywhere.

Once you have completed the planning stage, and everybody knows what is happening, it’s time to check the Google tools again. Yes, they change that often!

Once you know how many users you’ll need, you can visit Google and set up an account and buy the number of users you need. You only need to buy user accounts, as groups and calenders all come in the package. You can add the user accounts one at a time, in groups or all at once. It is effectively like buying credits which we will later use to add user accounts.

One area which was lacking at the time I carried out the migration, was that groups had to be created manually, and also populated manually with users once they had been migrated.

You will also need to set up your domain within Google, for which you will need to prove domain ownership, either by adding a Google specific CNAME to your DNS, or by adding an HTML file to the root of your website (If it has the same domain name).

At this stage DO NOT change your MX records, it may cause mail delivery issues.

When migrating to Google, I had to use several tools. Firstly, I had to use a tool which extracted the users from active directory, and created the user accounts in Google. Luckily it had a test feature, as it was a nightmare to configure. I then had to use Google Apps sync and Calendar sync, installed on each and every PC to upload user data to their accounts.

Since I did this, Google has a much better tool which uses a list of users to upload in CSV, and imports directly into Google from Exchange without ever having to visit an end users PC.

Follow the admin guide to use this tool, it explains it better than I could.

Now you have the migration tool installed, you can start the process, however initially start by migrating only yourself, so that you can test the migration tool does exactly what is says it should.

At this point, your email will be in 2 places, but only being delivered to Exchange, so make sure you add forwarding to your Exchange account to make sure any new emails are sent to the Gmail account too.

We were lucky enough to be adding a new email domain, so I was able to set up the MX records for that to Gmail, making forwarding easier, but as I recall you can send to temporary addresses at Google.

If you have problems forwarding, you can re-run the migration tool and specify a time period to sync from, and catch up with those emails.

As for us, because we had dual delivery (2 Domains), this wasn’t a problem, and we were safely able to forward, just be careful if you have Exchange mailbox limits, because this can stop forwarding if mailboxes get full.

Before jumping in though, you first need to plan, otherwise you can end up in trouble. I admit I didn’t plan enough, and it made it much harder.

Before you go ahead and buy a Google Apps account, you need to do the following:

1. Review the accounts, groups and calendars in use in your exchange environment. Record what groups are used for, what shared calendars do, and if you have any user accounts that are shared rather than using groups.

2. Once you’ve completed the review, decide what needs to stay, and what can go. If anything is not really being used, get rid of it now whilst you have the chance.

3.Decide when the migration will take place, who will be migrated, and when. Communicate this accurately, and if possible, arrange for training of key users so that support can be provided.

4.Make sure users are informed of key differences in working, especially if you will be dropping Outlook in favor of the Gmail web interface.

Once you have finished planning, take time to double check your processes, and ensure anybody helping is fully aware of what is happening.

Last year, I took a position at a Cambridge based company as a sysadmin.

Part of the job involved a project to migrate from an in house Exchange server, to a Google Apps solution.

I was largely left to my own devices to do it, and never having attempted anything like it before, I approached it with some trepidation, since I was to do it on my own, with next to no project management assistance, and having to do my daily job as well.

So, where did I start? Well, the only place I could, which was Google.

It is an interesting read, and highlights how it seems to be the networks and their branding which are the problem. Not just Three, but others too.

What is annoying is that Three don’t seem to have added much, aside from a logo during boot and some Three specific shortcuts to their web pages, so why have the loyal customers been left in the lurch? Surely it can’t be that hard, after all, HTC had the update ready in July, after making sure everything worked with the Sense interface.

I have now come to the conclusion that the only way I will be able to get Froyo is to root my phone, de-brand and install it myself.

That is not good, especially for a loyal customer of 6 years, who is paying to own the phone.

The plan is to root and flash on Monday, as I have a day off and can take my time. I’ll report back then……