I'm curious as to how much time it takes to transition 1K email (~200mb/acct) accounts from a locally hosted groupwise 7 mail server to a 2010 exchange server hosted in the cloud. Can you transfer over all old email and contacts? Is it possible to manage this transition so that users can have continuous access to their email? Our bandwith to the internet is 100mbps.
My organization is making this transition—we're a school. Email must be down for 5-7 days to allow for the transition. I'm told by IT that it has to be this way. It sounds like this isn't true, correct? Email could be kept up continuously, and the transition could be done much faster?
I helped lead a team that did this for GroupWise 5 to Exchange 2003 in year 2005 for over 5,000 users. It was LAN but 100Mb. Obviously old GroupWise servers, but we used a Quest Tool that we ran on a dozen desktops simultaneously. Two desktops each pulled from a single GW server (6 GW servers) and all mail was going to just two mid-sized Exchange 2003 servers with a iSCSI SAN backend. It took us nearly 3 days 24/7 of all dozen desktops running to pull from the servers. There's a long tail to our method meaning 75% were done in first 36 hours and huge mailboxes with GB's of email took another 1.5 days.
No idea what tool you're using migrate but you can always test by doing a migration and leaving old data intact, then delete the mailboxes on Exchange once you’re done. Rinse, repeat. We did this starting with just 1 test mailbox to understand migration feature set and scaled to 10% a few weeks beforehand. Don't assume the tool only READS data from Exchange and doesn't change it at all, as our original tool would mark email read which could be bad for testing if users don’t know. We first did a test from two GW servers to one Exchange server weeks before just to get a time est and did it on weekend and told users all their mail would be marked read.
Tons of little issues will show up as previously mentioned. Does it migrate inbox rules, what about email templates, or signatures, notes, public calendar permissions, etc. (I’m not savvy with GW 7 features). It's much better to involve power users and a few regular users beforehand to talk about what their concerns would be besides just "will I keep all my email". I.e. our GW5 actually had large attachments in old emails over 50MB that we decided not to migrate and telling them ahead of time prevented user revolt later. Another one was people hated the poor support for recall message in Outlook compared to GW and we had to come up with documentation beforehand to educate. Email client love/hate is like religion to many users and there isn’t much else in their work toolbox that they depend on so much as email clients.
The way we ensured 100% email availability was that all mailboxes in Exchange were provisioned weeks before and we kept the two account systems in sync through manual entry. We communicated to everyone many times that at 5pm on Friday you should stop using GW (and we blocked user access to svr IP at the router when time came). At 5pm you can start using OWA, which will at first be empty, and slowly be populated with all your info over the weekend. That was a simple message that users understood.
On the backend we started all 12 migration desktops at 5pm. We actually did 2 passes, 1st pass through all GW mailboxes migrated everything BUT email. Then 2nd pass through all mailboxes again to migrate just email. Through testing we found people had a hard time being without anything in their mailbox for days, but DID tolerated missing email IF they had their calendar/contacts, etc. in the worst case that migration took a WEEK.
Also at 5pm we changed all internal/external DNS so all new mail would go to Exchange.
Also at 5pm we had a very well tested script that uninstalled GW5, removed mail profiles, and installed Outlook on client computers. They were instructed sent to users on how to use OWA until outlook icon showed up on desktop.
We were a local government so we had to have 24/7 email uptime. With the magic cutover time for users while systems grind in the background it removed nearly all pressure of having an outage-based migration, yet provided users nearly everything they needed within hours of the cutover due to our 2-pass strategy.
Hmm, in a perfe.. erm, on this planet? 6 months for planning and documenting each and every single step. 9 months for real smooth migration and fitting the users in (in waves/groups). +6 months for fixing errors. From my point of view, I'd say 2 years at least.
The problem is not the transition itself or if it'd be possible. It is all about good planning. You need to be prepared for everything, for every exception, for every reaction (users), and for every possible problem. You really need to think the migration through down to its very bit.