This topic was created by chivo243 .
Hey All,
The topic of e-mail system migration has come up during our weekly meetings. Since I missed the fun and glory of the last migration our institution embarked upon, I have a question regarding time and planning. Little background, about 1000 users in an educational environment. What is an expected amount of time to prepare for such a migration process? Does anyone have a bullet proof way of doing it?
Thanks for reading, and many thanks for any replies.
D.B.
You haven't mentioned what platform you are on or migrating to which could be a fairly major factor, depending on the availability of tools for doing the migration.
Also depends on how much mail you have to move, how much disruption and user training etc you're planning/willing to have.
Do you have desktop mail clients that will need replacing and configuring?
All of the above gives you timescales somewhere between 1 and 9 months I'd suggest, entirely variable within that.
The new mail platform has not yet been determined. The decision will be made by non-technical administrators in the near future after reading a user generated study by a very small group of technical and non-technical users. So, I have very little information at this time regarding the direction of the project, only it’s projected implementation.
Many thanks for taking the time to respond to my vague question,
D.B.
The new e-mail system has already been selected. The user survey will include requirements that are a precise match for every single advertised feature of a particular product. If users generate any other requirements, these will be advertised for the version N+1 release. When the product arrives, you will find half the features are non-functional at best.
In your place, I would polish up my CV, start looking for my next job then propose testing various products prior to any decision being made.
"The decision will be made by non-technical administrators in the near future after reading a user generated study"
With that context you're pretty much doomed. I think you need to polish your CV and hang out in the jobs section.
But if you're able to influence the process, tell us what system you are currently using, what the daily mail volumes are, and the size of the mailboxes, and we'll try to help.
I strongly suggest you consider NetWin from New Zealand, their SurgeMail product. It has a built in Migration procedure that makes migrating users a dream. Essentially, you set the new mail server as your primary, and point it to your existing server. When new mail arrives, if the user doesn't exist, it's passed to the old server for delivery. As each user connects, and logs in with their email client, the NEW server, if the user doesn't exist, the NEW server will query the old server with user/password. If that pair is valid, the users account is CREATED on the new server, and ALL of their old mail is pulled to the new server, and from that point on, that users email, and logins operate on the New Server. They have both POP3 and IMAP migrations. If I recall, the IMAP migration will also pull all folders and such from the old server to the new server. There is virtually no need for you, the email admin, to setup each users accounts on the new server. You can leave the system in Migrate mode for as long as you like. They have Surgemail for Windows, Mac OSX, Linux, Solrais, etc. The pricing is VERY fair, and their support is AMAZING. I've had feature requests added in a week or two. Plus, if you have a special need, they're very responsive to your needs in adding functions, and doing special builds for you until they roll that function into the base releases.
http://www.netwinsite.com
Glenn
> The decision will be made by non-technical administrators in the near future after reading a user generated study by a very small group of technical and non-technical user, chivo243
Obviously the non-technical administrator will pick what ever buzz-phrase he read last in the non-technical technical press, eg CLOUD.what.BYOD.ever.INNOVATION, and you are the fall-guy that's going to take the blame for when the migration fails ..
As others have stated, without details of the current system and the new system no-one can offer any detailed advice. If both systems support IMAP then you can use various imapsync scripts to copy email from one system to another. With the correct scripts and users set up at the destination end this can then be an iterative process where you do an initial sync (which might take hours/days depending on the amount of storage and the network bandwidth/disk bandwidth available). Then you can re-sync several times to bring the new system in-line with the old until you are ready to switch over.
That's a bit subjective. What rig(s) were you running?
For my part I moved about 32k messages (coming to about 2.4GB) off a Core2 Quad desktop (localhost) to a Raspberry Pi (so only 10/100 link speed), IMAP-to-IMAP, using Thunderbird. Took about 4 hours all up.
Of course that's SOHO level stuff, the OP is probably better off paying somebody to take the risk/liability at their scale, as has been said.
Hi It’s me, D.B,
I’m back, OK I can provide some extra details after wonderful Monday meeting has passed.
Current messaging system: FirstClass 11.1 (OpenText) Replaced Exchange 2003 as a better tool for an Educational institution at or about the arrival of the previous tech director.
Candidates: Gmail, as the institution already uses google docs in some fashion.
Apple Mail Server, as the school is 95% Apple environment
Exchange, just because of the Cisco rational. (Nobody ever got fired....)
Roll out is to be incremental beginning around May 1st. Which data to migrate is still under discussion.
As many have said, get out the polish and cv...
Thanks to all for reading my post and replying.
D.B.
If you are migrating out of First Class you are not just migrating mail - also user data (we moved out of First Class a few years ago). I would STRONGLY suggest doing the migration at the end of the school year. Tell the Admin people that this will greatly reduce interruptions. Also means that you have far fewer users to migrate. Do you roll over student email from year to year? We did a migration from another email system to Office 365 in 2012. Used MigrationWiz.com. You setup all the mailboxes in the new system then setup the migration source and destination servers then setup the accounts to be migrated. With this system you can do multiple passes with the migration. Run it once over a couple of weeks to get the initial data across, do a second run just before you change where new mail is delivered to, then a final run after "go live" with the new system.
As far as platform choice goes, Mac Mail server is ok but does not give you the same features that you can get with the likes of Groupwise, Exchange, Office365, Gmail.
OS X Server is a nice platform because it comes bundled with all the necessary groupware stuff, but the simplified UI in recent times means that unless your needs are fairly trivial, you will be tinkering with it under the bonnet (at the command line, for example). Underneath the UI, OS X Mail is just Postfix+Dovecot, so if you can handle those, you're fine. As a Mac head this works out well for me since I know how to use AppleRAID, CoreStorage, Time Machine, etc and there's plenty of good Apple documentation on the subject, but unless you need the features that are specific to Apple (like iOS and Mac push and management) then it may not make the best choice for standalone use. I would point you to my review on the Mac App Store, but it's been obliterated by the recent updates, so I suggest that you give it a fair shot using an available Mac--any recent Mac will do--and see for yourself if it will do what you need. It really is very team-spirited, and users besides myself have been utterly delighted even without CLI changes. This always surprises me.
As for Google, well, the best you can say about them is that they're generous. Very task-focussed, it's "Free", and it's in the cloud, so all your problems melt away. But beware the big G. Google is not interested in doing more than is necessary to make it work, so if IMAP is too slow, or your choice of platform is not well-represented (think Symbian after the ActiveStink drop), well, too bad. But it's very shiny, and Google does many things correctly (compare Google Groups to your average Mailman install, EG), they're very big on collaboration, and it's very hard to argue with a turnkey solution that does most things right out of the box. Indeed, at the time, I only came back to self-hosting email (but still in the cloud) because I badly needed better mailing list support than Google Apps had at the time. Still miss the pee-easy moderation of Google, though, and it's really only possible because all the data is up in the cloud where Google's spam filters are. Same for archiving--for extra money, they'll audit trail for you. Very slick, indeed. In fact I think you can now get the Postini service separately, so you could still run your own mail server but get Google's spam filtering and archiving if you wanted to.
But anyway, as others have said, we really need more details to be of any specific help to you, I think.
Some people within the organization have voiced the un-usability of FirstClass. Is it good for the student population? So there is now an investigation into other platforms, and “IF” it should be blessed, it is scheduled for the beginning of May. Cloud bases is not really the issue, but rather the best product, whether locally hosted, or somewhere in the mist.
D.B.
I would ask the complaining users to offer training to the 900+ other people who are being forced to learn a new system because of their complaints.... And if they are unwilling to train others, then training for the new system must be in the budget as well as the migration costs, either of which could easily double the actual software/service cost.
Regardless, if you are going to try to migrate a system while it is in use, you will have to keep both systems running for at least a week and will risk some serious sync issues. And that's assuming all your DNS entries are clean.
Seriously, given all that, I would update my CV and leave before any of this happens....
The market leader in email migration tools is Quest - now owned by Dell:
http://www.quest.com/ondemand-migration-for-email/
It will migrate you to Office 365 - which is of course free for educational institutions....And significantly more fully featured than Borg Apps....
Hi,
Migrating from IMAP to Google Apps, I have used MigrationWiz a few times for my larger migrations and it was very cost effective and fairly quick. NOTE: I'm a Google Apps reseller so part of my job is email migration.
I have used MigrationWiz to do an unattended 2 pass migration of close to 200GB of data off an IMAP server with a single ADSL connection over a weekend.
From FirstClass, if you are using their calendar, there are some some scripts and a basic migration walkthrough here;
https://sites.google.com/a/bbns.org/tech-day/local-library-catalogs/migrating-calendar-from-firstclass-to-google
For a specific FirstClass solution, the Google Apps marketplace lists Salvair FirstClass to Google Mail service - which I have not used but has positive reviews.
Get in touch with Audriga (https://www.migrate-mail.com/en.html). They don't just do "cloudy" migrations (i.e. via their own servers), they can also supply a sort of black box approach. This is, of course, assuming you do a transfer between two DIFFERNT systems (for instance, from Exchange to an Open Source solution), so what you'll do is log into an account and pump emails into the target.
Your main challenges are (1) legality (privacy needs to be protected so you're going to have to get the process inspected or get people to sign agreements), (2) bandwidth, and (3) getting everyone's passwords, although you can just give an outage time and do a password reset instead.
Good luck - it doesn't actually take as long as you think, but planning, backups and test runs are essential. However, one warning: the use of Google may put you on the wrong side of Data Protection laws. Regulators seem to be reluctant to mention this publicly (I assume it's politics getting in the way), but as a sender never has the ability to approve you passing on an email to a 3rd party you are apparently breaking Data Protection every time you receive an email. Just give the ICO a call - they will confirm this (at least, they did when I called). You may want to keep this in mind - don't let the illusion of "free" cloud your judgement (sorry about the unintentional pun).
I've BTDT on both a much larger (70k+ users - years ago) and much smaller scale (e.g. 50 users).
Without knowing more about your environment, it's hard to know what advice to give. Worst case scenario you'll have to do an IMAP to IMAP migration and at this scale it would take a while. The gating factor would be the amount of messages in each inbox.
If it were me, I would outsource the work - make it part of the new system RFP - that's way better than trying to DIY it.
If you insist on DIYing it, couple of things:
- Make sure you have properly setup & tested secondary mail servers
- Backup everything AFTER you have stopped all services
- Make sure your backup & restore procedure is thoroughly tested way before your do this
- Do a dry run well in advance of the turn over and test any roll-back procedures you have
- Make sure you understand what will happen to every device after the migration
- DNS is your friend, understand how to use it to your advantage.
- Whatever the case, plan this for a 3-day weekend
- It's worth paying for commercial tools at this scale.
But, honestly, at that scale, I would make it someone else's headache.
It's very difficult to say. It all depends on what you're on, what you're moving to, what you're migrating and how you're migrating. :)
How big are inboxes?
Is the new mail system on the same network? What bandwidth is available? Is it feasible to use disk-shipping if it's a remote system?
What storage backend does each system use?
If they're both maildir then the task is quite simple - copy all the files to the new system and perhaps script a few tweaks to some of the files.
If you use something like IMAPSync then it's going to take quite a bit longer. A large mailbox over the internet might take hours.
Is it just mail too, or are you going to try and migrate contacts and even calendars? Unless both systems use some kind of standard (CalDAV etc) then it's going to be a manual process - export, convert, import. Even with CalDAV etc. it's going to be fiddly.
So without having anything to go on, I'd say it'll take a few weeks, if not more.
Subject to details such as platform and OS, here are some basics.
1) Back up everything. Twice. Then verify the backups to make sure they are valid. Ensure you can go back to the old server if needed.
2) Get the new server up and running with all SP and OS patches. Run it for several weeks without any accounts on it and check your error logs for any issues with the new hardware. If they allow direct transfer of mailboxes between old and new servers, transfer a few small accounts and one big one over and run them for a while to make sure all is well. Make sure they are not corporate VP's or mission critical accounts. Former employees make for a good source of test account for this.
*** LET PEOPLE KNOW AHEAD OF TIME THEIR EMAIL MAY BE SLUGGISH OR UNAVAILABLE WEEKS BEFORE AND JUST BEFORE YOU DO ANYTHING ***
3) Make sure your DNS and firewall is updated to send mail to the proper IP's (Old and new).
4) Test, test, test. Send, receive, attachments, calendar, notes, etc. Check error logs. After any issues are identified and fixed, bring the remainder of the accounts over in batches. The number per batch depends on network speed and your personal comfort level. Don't do everything at once. Repeat as necessary.
5) When all accounts are transferred, keep the old server available for at least a month in case you need to go back (if you can). Keep a virtual image of the server at the very least and full data backup if at all possible because you will miss something.
6) Backup everything. Twice. Then verify the backups to make sure they are valid.
7) Good luck.
Boy, you are in for a rude shock. Migrating stuff between mail systems has all kinds of problems and it's likely that you will experience a number of them. Off the top of my head:
- Flags missing (aka starred messages)
- Delegated mailboxes not working
- Mail not forwarded properly
- Aliases broken (esp. with Gmail)
- Mailing lists need to be re-created
- Server-side filters deleted/gone
- Away messages not working/different
- White/black lists broken/different
- Spam handling working better/worse/different
And that's just moving from Desknow to Gmail for 50-ish users, never mind 1000. Like I said, I would make this someone elses headache as it would be hard to discover/document all of the odd ways people use/abuse email, esp. in an academic environment.
I would add that if at all possible, test the backups on a different server using a different (obviously compatible) tape drive. Do this even if it costs you extra. If the head on your tape drive is out of spec, no other tape drive will ever read those tapes. Don't risk this. I have seen the fallout from one of these disasters. It was apocalyptic.
The tech details are too different in each case to give a lot of specific advice. But if you really stick to these two principles, you'll be fine.
1. Plan for success and you will have failure.
2. Plan for failure and you will have success.
Well, yes, but without wishing to disparage the earlier commenters so far, I don't think we've helped the OP much yet.
I share an earlier poster's concerns about the "decision to made by non-technical types later" (later? like after the budget and timescale have been fixed?), but I think "polish your CV" is possibly unhelpful in the current climate. My own suggestion would be to recognise that this project hasn't started well and might turn into a buck-passing exercise if anything goes wrong. Your best defence in these situations is to have a clear statement of original goals so that you can resist (or at least argue for more time or resources) disruptive or contradictory changes later on.
So ... it might be a good idea to get management to state their reasons for wanting to migrate. You can use that to keep the project focussed. And if they aren't willing to say, I suppose you can always go back to polishing that CV. :(
Ah ha! The curse of technical professions strikes again :)
This isn't a 'free consultancy', this is a client education correspondence course. It is unlikely the OP was going to shop this job out, since he asked 'The Internet' what his options were. If he wasn't going to go this mostly alone, his sales droid would already have told him what he needed. So by providing information isn't going to lose you anything and you stand to benefit many times over from the education session. Let me explain:
The proles often think that ignorant customers are what businesses prefer. Anyone who has been in business will tell you that's bullshit. The absolute most valuable customers are the ones that know exactly what they need. Those customers are little more than a transaction: Money for Thing. Everyone is happy and both parties can get back to their primary mission. Plus you don't have to worry about the ghost of customer (mis)expectations rising up 24 months from now to bite your ass. It's also the mature type of customer who is much more likely to have peers that face similar challenges and who will recommend your services to them.
Now, here's the rub. For those easy money educated customers to become educated, someone has to educate them (crazy right?). Often, as the educator, you won't land that customer, but who educated the last educated customer that came through your doors? I'm not advocating you doing any actual work for free, but educating customers is an evergreen opportunity.
Customer education pays off, eventually, for everyone. But it's one of those things that is most beneficial if everyone does it.
There is so little information that it is impossible to give a semi-accurate response.
- what clients are used today? If there is software (e.g. Outlook, Thunderbird) on user PCs, will that work with the new mail system? If you're moving from one closed system (e.g. Exchange) to another (e.g. IBM Lotus Notes) you will have a lot more work training users on the new clients and converting all the desktops.
- what features of the current mail system are used (e.g. shared folders, mailbox ACLs, distribution lists, etc. some also come with built in calendar). You probably have a webmail, so you need to consider how it will work on the new system and if you need to migrate settings and contacts
- what's your defined maintenance window for the cut over? that can dictate the processes you need to use
- phased migration or single shot (i.e. move some users at a time or move everyone at once)? Some mail systems cannot support operating in a mode where some users in the domain live on a different mail server so a phased approach may not be possible
- can you get into the mailboxes on both the current and new mail system without knowing the users password? A lot of mail systems let you do this using some kind of administrative proxy login function, either through proprietary extensions or SASL. If you need to know the users password, that can complicate things a lot.
I've been doing e-mail migrations for far longer than I care to admit and to be honest you're not giving us enough to give you further help. If you're using commercial software, investigate using the new vendor to move your mail for you. Some will throw a migration in for free.
If you're using open source, good luck. There are a lot of ways of doing mail migrations, but often not well documented and I've often had to go digging in the source to find the features I need to make the migration happen.
Just like in Madd Maxx, speed is just a matter of money, how fast ya wanna go? Cost is not in my purview, I only have to support what comes down the pipe. I just want to know how much toilet paper to bring... Thanks for the reply! Any suggestions in case the study is inconclusive?
D.B.
@ chivo243
How long the toilet paper is? Really? So you'd be happy with cheap bog roll that will falls to bits as soon as it gets any where near any vaporous anal cavity resulting in dirty hands, an unwiped arse and a good chance of follow on issues of passing nasty butt bugs to other users thanks to your dirty hands (oh you will wash your hands...but tell me...is there a sink in your stall?) or would you rather a more resilient solution consisting of two or maybe even three ply sheets that are not so rough that they cut your anus to shreds or don't fall to pieces in the presence of a vaporous butt crack?
Length is not really the issue is it?
Okay,
This is a pretty serious project. But we don't know what the goal of the project is. And the people making decisions have no material expertise to base their decisions on. That seems like a bad idea (and business as usual for an IT project, unfortunately).
Since the decision is apparently made without any technical input, there is no need for an analysis of costs.
A bulletproof way of doing it:
- Determine target system requirements (storage, network, backup, load balancing, etc.) based on technical requirements, current usage (storage, backup, bandwidth) and specifics of the intended target email platform (i.e. some systems store mail more compactly than others).
- Acquire target platform hardware and software.
- Install target platform hardware, software, tools for client connectivity, backup etc.
- Set up the new mail platform to send mail via the old mail server
- Test target email platform and client software with a limited number of accounts.
- Test the backup solution for your new system.
- Create a user manual for the new platform and client tools, detailing how to preform basic operations in the new platform (reading and sending mail, scheduling meetings) and some advanced topics (i.e. out of office notifications, sorting mail into subfolders etc.)
- Create a backup of the target system
- Migrate/import/create all mail accounts (but not mailboxes) to the new platform. This may be done with a bulk creation (e.g. from AD) or with a (power)shell script.
- Check that accounts were created correctly. Roll back if not.
- Create a backup of the old system.
- Set up forwarding rules from the old system so mail delivered to the old platform also get delivered to the new platform. Probably with a with a (power)shell script, although some mailservers may accept more generic rules.
- Check that the forwarding rules work. Roll back if not.
- Create a backup of the new system
- Migrate a handfull of mailboxes to test the mailbox migration process
- Check that mailboxes were migrated correctly. Roll back if not.
- Create a backup of the new system
- Migrate all mailboxes
- Check that mailboxes were migrated correctly. Roll back anyway.
- Plan a final migration date, notify users of impending changes and downtime
- Distribute the user manual to all users
- Create a backup of the new system
- Migrate all mailboxes
- Test that mailboxes were migrated correctly. Panic if it didn't work.
- Change MX records to deliver mail directly to new server
- Route mail from new platform directly to destinations
- Change SPF records (if any).
Once you know what your source and destination platform are, people may be able to suggest useful tools to help automate the migration process.
Focus on the migration.
Many times I see people (project managers for the main) say "well, this would be a great time to have a tidy up, remove inactive accounts, etc."
DON'T
Invariably the tidy ups cause far more issues than the migration itself. And when you get problem reports, you'll spend ages trying to work out what the problem was with the migration - only to realise the account in question got "tidied".
You cannot plan the migration until you know what you will be migrating from, and what to.
You should refuse to give any estimates until you know the destination platform. If they insist, say "between N weeks and 6 months depending on what the destination platform is".
Meantime if you actually want advice at least tell us what you are migrating from. Presumably you know that much, right?
I know you said that the number of users is about 1000. But no indication of the average size of a mailbox, number of items among other things. The platform you're migrating to would be of significant importance. If you're keeping the solution in house migration shouldn't be too bad. It may take time for the data to move over (depending on the platform your going from and to). It'll be more about getting the users already in the environment trained on the new environment (again depending on the source platform and destination platform).
If you're looking at an external solution (Google Apps or similar cloud hosted) you need to take a long hard look at the amount of data you have, the connection you have to it, and how long it'll realistically take you to move that data over. Environments with users and multiple gig mailboxes may take longer than what would be considered a reasonable amount of time to migrate.
Also depending on the amount of data you have in the current system you may want to look at implementing an email archiving solution in tandem with the migration to make the amount of data you have to move to the new system significantly smaller without severely impacting the users. Again this is all going to depend on what you're going from and what you're going to.
All of these things will have to factor in to the time line you have for making the switch over.
My assumption here is that being an educational system you have some sort of long break to do this migration over. Students are usually off from June to August, unless they chose to take summer classes, and that's when big switch overs typically happen. This gives them time to move the data, test to make sure connections are working properly and documentation is available for users on how to use the new system.
It's just that we see many that finally understand that there are other solutions that can do the same job, require a lot less HW and cost a lot less.
Anyway I think we need a bit more info to give you an idea about complexities and amount of time required.
For me moving users away from MS Exchange is quite simple as we have a migration tool that just grabs users and their datastore from one system and moves them to the other but you've got to keep in consideration the transfer rates you can get to calculate how long it's going to take.
Do you plan to move them all in one go?
Are the servers on the same network?
What read and write transfer rates do you get from the 2 servers?
Size of the current database?
Are the attachments store within the database or on file system? Are they already deduplicated?
If they are still in the evaluation phase then I recommend to add to the list Zarafa Groupware, you get MS Exchange features but as I said above it's lighter, cost effective and it's also Open Source if you plan to do some integrations.
Thanks, I posted more info as it was available today. I had no idea I would be a forum on the front page! And, no, we had Exchange2003 and it lasted only a few years, then we migrated to FirstClass, being an educational institute, the product fits. Unfortunately, a small group have grumbled long enough to ask for a review of our communications tool. Exchange is back on the list, please see my other post under my original post for all the gory details,
Many Thanks,
D.B.
We just went through this with far less users and it was horrible. Get all users to do back up to .pst files right now. Also find a 3rd party vendor to do the NEW EXCHANGE SERVER. I would also literally kill your "a small group have grumbled long enough to ask for a review" with kindness.
You have an answer. Get EXCHANGE!!!!!!!
No one can answer your question until you know what you're migrating too.
It sounds like this project isn't being run particularly well to be honest. As others have said you need to go back to basics: Why are you changing email system? What's wrong with the current system? What new features do you need?
You need to do a full audit of your current system: Number of mailboxes? number of items in each mailbox? Size of each mailbox? Number of emails sent/received per day and per hour? Etc
Plus you need to think about disaster recovery, archiving and legal issues etc. Are there any data protection issues with using cloud based services? which country would the data be stored in? Do you need to archive email? How long for? Etc etc
Thanks for the comment, actually our current system is feature rich, and seems a bridge too far for a small group of vocal users. We use FirstClass for Education. As we are educational, the flux of messaging is large, some days not much, closer to exams or other deadlines, it can become heavy, it’s not business usage. Mail boxes range from a few mb to many gb.... so we must plan for large mailbox stores and get lucky with small ones.
Your last paragraph is almost exactly what I mentioned in a meeting and faced a bunch of blank stares... Glad to know I’m not losing it.
"Real project!!!
or is someone trying to bulk out some coursework!"
Wow - have I wondered onto a microcontroller forum or something? That's where I usually see the "I can't answer (or can't be arsed to) the question so I'll just accuse someone of laziness so I'm upping my post count" crap. Grow up or shut up.
Doesn't it also depend on what client software they want to use? If everyone is gung-ho on Outlook, they're going to want something that gives them all the Outlook features. Even without that requiremkent, do you need to integrate with Active Directory and other Windows technologies?
I'd stick with a Linux system with IMAP, but then I have less than ten users to worry about so the scale is somewhat different. At my level, lack of licence issues means it costs less, but with a large system the running costs will be a significant part of the equation.
Everything is relative
Are you moving existing messages to the new system?
Are you requiring calendar synchronization for the coexistence period?
Are there Applications that are bound to the email server?
Do you need to contact each desktop / Laptop / Mobile device to reconfigure?
Knowing the answers to the above questions will help assign resource / time metrics
As the world has moved since chivo243's organisation migrated to FirstClass, it would be sensible to start drafting some new requirements by asking a few questions:
What 'email' clients and systems other than FirstClass are being used and why.
What do users (particularly the one's stirring things up) hope to gain from the migration.
Unless your organisation has money slushing around, which is highly unusual in UK education establishments, it will be hard to justify the expenditure, so you need to find out who in your user population is going to be taking this to the board, because believe it or not it isn't IT's responsibility. Your (IT's) responsibility is to provide advance and guidance on the IT challenges their preferred solution presents and reliable figures for their case.
Reading between the lines of Chivo243's various comments, it seems that some are wanting Exchange back, but is it really Exchange and not just the Outlook client? This wouldn't surprise me as many users seem to be comfortable with Microsoft because they know their products are widely used in industry.
So even if the user's agree on a preferred product, your design journey will have only just begun. From Chivo243's postings, it seems his organisation will have to motor to complete this migration in time for the new academic year starting September - as I would not wish to under estimate how long procurement negotiations can take.
"...our current system is feature rich, and seems a bridge too far for a small group of vocal users."
Regardless of the technical complexities, there's huge potential for disaster just in that statement. Is it really only a small group of users who are dissatisfied? Or only a few, of a much larger group, who are doing the complaining? The difference is significant.
If it genuinely is only a small group of dissatisfied users, then the new system will perforce have to mirror all the features of the old one. (Albeit in a more user-friendly format, to satisfy the whingers.) Because, sure as eggs are eggs, there will be people who liked the old system because of its "rich features" -- even if they only used a handful of them. Forcing all users to acclimatise to a totally different system is hurdle enough. However, if it's being done at the whim of a minority, that is begging for outrage on a monumental scale. (Trust me. I've worked in academia.)
That said, if there has to be a migration, the least disruptive option is probably Gmail. It's likely that a significant proportion of the corpus will already be using Gmail on their home devices, so there's minimal learning curve. However, Gmail does have serious failings regarding privacy/tracking. This would be a major drawback in an educational environment and would require 'tweaking' the settings -- possibly on an ongoing basis, as the email platform itself evolves.
I'd suggest amassing all the evidence, from both the technical and user standpoints, and pray that well-presented logic will quash the whole idea (meantime polishing your CV...).
Part of the purchase requirements should include having the selected vendor price out the complete migration job, including Firm Fixed priciing, scheduling, user training literature, videos, etc.
Since they have done it before (they have, haven't they?) they should know the ropes.
After getting that quote, they you can milk it for space and resource (including time, time, time) relief.
If it seems too high, they may be telling you the most important metric for the migration--that it won't be pleasant, or they are milking you.
Out of curiosity, I googled around to see what others had done.
https://knowledge.riverdale.edu/index.php?title=FirstClass_to_Google
http://middleschoolblog.blogspot.com/2009/10/google-apps-for-education-rating-our_04.html
http://tech4teaching.org/wpblog/?p=742
Tons more here https://www.google.com/search?q=first+class+migration+plan
This is an interesting counterpoint to migrating away from FC - http://www.commonworldinc.com/firstclass/info/S0037953E-0037953E
Has anybody explained WHY they want to migrate email? Until you know why, you can't identify the success factors (explicit and implied). And if you don't know what those are, you can almost guarantee that at the end of the project, even if you've met all the technical requirements, the sponsor will be unhappy because you've not met his gut feel about "why it's now better".
This is just a small part of the job which you've already thought of, but just in case:
Once you know the date you're going to move mail servers, around a week before, set the Time To Live on your DNS records to be smaller, perhaps around an hour or so. Then when you make the final changes to your MX records on the day, the DNS change should propagate that much quicker.
Leave the TTL short for a couple of days, in case you need to roll back in a hurry.
Seriously, I cant reiterate that enough.
I worked for a fairly modern Australian university that migrated from Exchange to Gmail while I was there. It was nasty. The test group were administrators and IT staff and I think a very small group of senior academics.
Turns out that Gmail simply doesnt have the flexibility or customisability that the university needed (for instance, Google limits the number of email addresses you can bulk email at once. They also limit the number of contacts you can have, or at least did at the time). The university was also too small to warrant any attention from Google (5000+ staff, 20,000+ students), so trying to get any issues resolved, or in some instances even investigated, was nigh on impossible (unless Google already had a first line support level write up for a known issue).
When they made the final switch, within weeks the service desk started to melt under the pressure and it never really let up, as we would resolve one thing only to have something else come up.
Hi,
there is actually a FCAS exporter for Firstclass that exports to mbox format (that is easily read by about.. anything).
i couldn't use it b/c it killed all umlauts... but if you have FCAS, then that'd be the way to go..
http://www.firstclass.com/products/FCAppStoreContainer/FirstClass%20Export%20Tool%20v1.1-33%20%28MBOX%20format%29
"The final decision is made by non-technical staff."
This is a recipe for disaster. Polish up your CV and check what colour your parachute is.
Seriously.
Decisions need to be made by technically competent people and if nontechnical people are involved it must be simply to sign off on those decisions.
$orkplace has so far spent £5+ million pounds and 3 years migrating from a slightly broken(*) locally administered unix/exim setup to Office365 ("But it's Free!") - and ended up with a substantially inferior system (much higher levels of support handholding required) - thanks to a decision effectively made via conversations and handshakes on the golf course ("But it's FREE!")
Justification: The new system is "FREE" - technically yes, but it's also broken(**) and is incurring 20 times more support manpower than the old one did.
(*) Slightly broken = overloaded and manglement wouldn't spend money upgrading the storage/frontend, resulting in increasing amounts of downtime during peak hours.
(**) Limits on the number of connections mean that users are seeing effective downtime in increasing amounts during peak hours - and there's no way of increasing the limits as it's all in the hands of a third party. That's on top of the system often taking 12-20 hours to deliver messages which have arrived during peak hours.
I need some suggestion on how I will increase traffic counter on my site as well as website hit counters? I am starting out to promote my own website organically but don't know how to do it. also I want to know about free web stats counter for my site & how will I get that. If anyone know about this please help me.
Any help would be appreciated :)
what features of the current mail system are used (e.g. shared folders, mailbox ACLs, distribution lists, etc. some also come with built in calendar). You probably have a webmail, so you need to consider how it will work on the new system and if you need to migrate settings and contacts
I've done a dozen or so email migrations before, ranging from exchange 2010 to office 365, etc. I wanted to check with you guys and see what you think is the best way to migrate from G Suite to Office 365? I Want to make sure I'm not missing an easier way to do this.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
