Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A prospect wants me to price building an automated solution that will pull data from their email system including email attachments, and move that data into our database application.

Historically, they've used email (Outlook/Exchange) to track and organize important documents, photos, and correspondence. They have files in shared folders so for their collaboration. They've grown weary of using email to manage their work, and have decided to purchase our application, but would like to move all this data to our app, as attachments.

Now, if these were physical files instead of emails, this would not be a problem, however, I've never done any work before to extract emails from exchange.

What questions should I be asking the client so that I can confidently price this work for them?

share|improve this question
    
Are you asking about how much work it would be to program a solution? Then this should be moved to Stack Overflow. Are you asking about the price of commercial software that can trawl through Outlook or Exchange and extract metadata and attachments? –  mfinni Oct 28 '10 at 13:31
    
And is this going to be a one-time conversion, or will you/your software need to be doing this on an ongoing basis? –  mfinni Oct 28 '10 at 13:32
    
mfinni, not being very knowledgeable about Exchange, I'd like to find out what questions should I ask the client about their configuration/setup so that we can figure out whether this is an easy problem, or a hard problem. –  Linus Oct 28 '10 at 13:45
    
mfinni - Lets assume for now this is a one time conversion. I don't know if the best way to go about this is to use POP, or is there an API to access Exchange datastores.. are there separate archives for old emails.. etc. –  Linus Oct 28 '10 at 13:47
2  
All focus on exchange here - focus on the content. Are the emails "standardized"? If not this is a hell of a project to parse the emails and try to make sense out of them - to a degree I think it can not sensibly be done for all emails and every data item must be checked by a human. –  TomTom Oct 28 '10 at 14:00
show 2 more comments

1 Answer

up vote 0 down vote accepted

Besides the usual environmental questions (how many Exchange servers, what version of OS/Exchange, etc.), I'd want to know approximately how many messages there are, the number of mailboxes that contain messages to be imported, and the size of each mailbox. This should be readily available through the System Manager (if 2003) or Exchange Console (if 2007+).

As for technique, it really depends on how many mailboxes and the budget:

  • If there's < 10 users and there's not much of a budget to do this, you could setup an open source DoveCot IMAP server on their premises (or remotely) and walk them through adding an IMAP account to each of their Outlook profiles and simply drag and drop the messages into the IMAP account; IMAP stores it's messages in several optional ways on the filesystem, is fairly well-documented, and (as you say) would "not be a problem" to import files into your application.

  • If there's a lot of mailboxes (and likely a larger budget), I'd use EXMERGE to bulk export .PSTs for each mailbox and you could use Zimbra's PST Import Wizard to import all their mail into a Zimbra server which I believe stores mail on the filesystem or MySQL (need to double-check that, but likely something doable).

  • there's also quite a few options in 3rd-party commercial or open source PST-to-$someFormatorMediaryFormat tools, some require alot or a little code to write.

The good news is, this isn't as exotic as a request as you may think right now; there's alot of Exchange alternatives out there that need to have a reliable method of importing data from Exchange or nobody would convert.

I'd favor going a well-documented route like IMAP/Maildir/MIME Format: once you get it into that format reliably, there's likely alot of open source parse tools in your language of choice to help you import it into your application.

Regardless of what you choose, I would do a "slice" first: decide what's doable, grab a sample set of data from the client to do a test run (or if that doesn't fly, get a good idea of what kind of documents they're storing, whether in sub-folders or not, what kind of "metadata" they use to organize the messages, and create your own sample set) and then extrapolate the time it'll take you to do all of it, padding it accordingly depending on your comfort level.

share|improve this answer
    
gravyface, thanks. Again, I haven't done this before, so maybe I'm thinking this through the wrong way, but we're a .NET shop. That being the case, I was hoping that Microsoft provides a simple-enough API through .NET that would allow us to extract all this content instead of moving them to a different/interim storage. –  Linus Oct 28 '10 at 14:00
    
That would've been helpful in your question, but yes, you can certainly use the MAPI API. I only went the IMAP/filesystem route because you said that files aren't a problem. –  gravyface Oct 28 '10 at 14:13
    
Actually, it sounds like it's not as straightforward as you would think and IMAP may still be the preferred method: stackoverflow.com/questions/652549/read-ms-exchange-email-in-c –  gravyface Oct 28 '10 at 14:17
    
gravyface - thanks. sorry that wasn't in my original question. I wasn't even sure I could use the MAPI API, or if that is easier than going through a file system solution. I'll look at that other question. –  Linus Oct 28 '10 at 14:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.