Feeds

Mail Migration

This topic was created by chivo243 .

Mail Migration

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.

0
2
Bronze badge

Re: Mail Migration

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.

2
0
Stop

Re: Mail Migration

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.

2
2
Silver badge

Personal conspiracy theory

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.

15
0
Anonymous Coward

Re: Mail Migration

"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.

4
0

Re: Mail Migration

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

0
1

Re: Mail Migration

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.

1
0
Windows

Re: Mail Migration

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.

2
1
Bronze badge

Re: Mail Migration

Why do they feel they need to move systems again?

Is it about money saving or has something been done like moving emails from local based to "Cloud" based?

0
0

Re: Mail Migration

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.

1
1

Re: Mail Migration

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.

2
0
Anonymous Coward

Re: Mail Migration

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....

0
1
Anonymous Coward

Re: Mail Migration

"as the institution already uses google docs in some fashion."

Did you know Office Web Apps is also free, but more powerful and MS document formats actually display correctly?!

http://office.microsoft.com/en-GB/web-apps/

0
4

Re: Mail Migration

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.

0
0
Childcatcher

Re: Mail Migration

Should not be too hard, as long as the old and the new system adhere to the standard Unix mailbox format.

3
1
Anonymous Coward

Re: Personal conspiracy theory

You a manager yet, Flocke? If not, you should be.

It's in your veins. :-)

0
0

Re: Mail Migration

I would recommend the network edition of Zimbra.

0
1
Anonymous Coward

Re: Mail Migration

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).

0
0
WTF?

Mail Migration madness ..

> 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 ..

3
0

Re: Mail Migration

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.

1
0

Re: Mail Migration

You can do that, but it will take days. I migrated 30k emails once using that strategy, I think it took close to 17 hours...

0
1

Re: Mail Migration

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....

2
0

Re: Mail Migration

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.

0
0
Bronze badge

Re: Mail Migration

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.

0
0

A bit vague

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.

1
0
Anonymous Coward

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.

2
0

For weeks? Yikes, the users will blow a gasket if we have issues for a day. That is why I am planning for the worst(work) well ahead of time. Your advice is going in my journal, and will be applied when possible. Many Thanks!

D.B.

0
1
Happy

You've done this before, I see.

0
0
Anonymous Coward

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.

0
0

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.

0
0
FAIL

2nd Migration

So having migrated your mail system once, your organisation presumably made the wrong choice or the perimeters changed. The phrase "the grass is greener on the other side of the fence" springs to mind. I also foresee blood on the carpet; users are involved :-(

1
1
Anonymous Coward

Hang on - there are companies (mine included) who do this sort of thing for a living. This is just free consultancy.

3
4
Gold badge

Re: free consultancy

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. :(

3
0

Re: free consultancy

My manager is a bit maniacal when it comes to playing the c.y.a game, we have that covered in spades, many thanks!

and it never hurts to have an up to date cv, as I don’t have ;-}

0
1
Silver badge

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.

2
1
Bronze badge
Joke

Don't do this.....

Tell all of your users to dump everything into PST files and hope for the best!

4
0

Re: Don't do this.....

its better than telling your users that their emails will be migrated and then when it happens there is nothing there...

1
0
Silver badge

Re: Don't do this.....

That just means they migrated to somewhere other than where the users are looking, probably the bit bucket...

1
0
Anonymous Coward

Re: Don't do this.....

/dev/null - amazing storage capacity, but crap to restore from.

0
0
Anonymous Coward

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.

2
0

Fundamental Questions

How much do you want to spend?

All other questions are secondary until you know this.

2
0

Re: Fundamental Questions

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.

0
2

Re: Fundamental Questions

@ 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?

2
0
Silver badge

Re: Fundamental Questions

A good arsessment of the situation.

0
0

Risky business

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.

1
0

Re: Risky business

This is what I need, good point by point advice I can give in terms of the steps involved when the project is planned, many thanks for your time!

D.B.

0
1
paj

Migration and JUST the migration...

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".

3
0

What from? What to?

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?

0
0

RE: Mail Migration

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.

0
0

Is it another migration out of MS Exchange?

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.

1
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon