How do I move mail from an old server to a new server?

Question

I am rebuilding my server. The new server runs on OS X 10.9.4 with Server 3.1.2. The old server ran OS X 10.9.x and Server 3.x (the exact versions are not known).
Within the folder /Library/Server/Mail, I found the email stores for both systems.  I have gone through each folder and identified the 36 character string that serves to identify the user's mailbox and paired each one to a user id on both systems.  On the old system, there are multiple mailboxes for some users, and I think it is a result of the users being deleted and recreated: perhaps the system identified the identical name and assumed that the user might be different and therefore created a unique 36 character id for the mail system.
The trick is, I am trying to recover the mail from the old server.
I have attempted to copy the files which are human readable and formatted for SMTP transmission to the new server under the correct mailbox corresponding to the owning user (see screen shots below). The simple act of copying the files has not made these files visible via the IMAP protocol. I have tried restarting the mail service hoping that the Server app would rebuild whatever indexes need to be built so that the mail can be served via IMAP, and that has not worked either.
The question is, how do I get the mail from the old server mail boxes into the new server mailboxes?
This screen shot shows the location of one mail collection at /Library/Server/Mail/Data/mail/[userid].  Mail sits in the "new" folder only for a moment before being processed and put into the "cur" folder.  Copying mail from the old server into the "new" folder produces an empty "new" folder, but one can see the files populate briefly before they are moved into the "cur" folder.
The next screen shot shows one email opened in TextEdit.  The format should look very familiar.  This is the same format that one would use to send SMTP requests to an SMTP server.  This particular example happens to be an email from a Gmail account to the PediatricHeartCenter.org domain to test the mail system when the old server was set up.  It was sent on 24 Jan 2014 and had text reading "Intended for Mavericks1. -Jared".

Answer 1

On further research, I have learned that OS X Server sets Dovecot to use the MailDir format.  The email messages can be removed from the folders and put back, and as long as they were present in the folder to begin with (received by Dovecot originally), they reflect in the Mail.app on client computers.  Deleting a file in the "cur" folder causes the file to disappear in Mail.app. Copying the file back into the "cur" folder will cause the file to reappear without any modification of an index file or any other system component, as long as the file was properly formatted by Dovecot to be identifiable to that folder.
According to Dovecot.org's review of MailDir found here (http://wiki2.dovecot.org/Ma,ilboxFormat/Maildir), the file name can be broken into simple pieces: " [unixtimestamp].[process id].[hostName],S=<message size>,W=<virtual message size>/2,[status tags]".  The original MailDir++ specification requires the string ":2," to appear after the virtual size, but this file naming format is not legal in Mac OS X, so Dovecot is modified by Apple to use "/2," instead.
The Dovecot's wiki describes inserting new messages as follows:
Mail delivery
Qmail's how a message is delivered page suggests to deliver the mail like this:
Create a unique filename (only "time.pid.host" here, later Maildir spec has been updated to allow more uniqueness identifiers)
Do stat(tmp/<filename>). If the stat() found a file, wait 2 seconds and go back to step 1.
Create and write the message to the tmp/<filename>.
link() it into new/ directory. Although not mentioned here, the link() could again fail if the mail existed in new/ dir. In that case you should probably go back to step 1.
All this trouble is rather pointless. Only the first step is what really guarantees that the mails won't get overwritten, the rest just sounds nice. Even though they might catch a problem once in a while, they give no guaranteed protection and will just as easily pass duplicate filenames through and overwrite existing mails.
Step 2 is pointless because there's a race condition between steps 2 and 3. PID/host combination by itself should already guarantee that it never finds such a file. If it does, something's broken and the stat() check won't help since another process might be doing the same thing at the same time, and you end up writing to the same file in tmp/, causing the mail to get corrupted.
In step 4 the link() would fail if an identical file already existed in the maildir, right? Wrong. The file may already have been moved to cur/ directory, and since it may contain any number of flags by then you can't check with a simple stat() anymore if it exists or not.
Step 2 was pointed out to be useful if clock had moved backwards. However again this doesn't give any actual safety guarantees, because an identical base filename could already exist in cur/. Besides if the system was just rebooted, the file in tmp/ could probably be even overwritten safely (assuming it wasn't already link()ed to new/).
So really, all that's important in not getting mails overwritten in your maildir is the step 1: Always create filenames that are guaranteed to be unique. Forget about the 2 second waits and such that the Qmail's man page talks about.
The process described by the QMail man page referenced above suggests that as long as a file is placed in the "new" folder, that a mail reader can access it.  The mail reader then moves the file to the "cur" folder and "cleans up" the "new" folder.  This is clearly happening in OS X, because the messages are moving from "new" to "cur", but IMAP is still not serving these foreign messages to the remote readers.
The thought crossed my mind that perhaps it is the fact that the host name does not match, which would cause the failure, however changing the "host" portion of the name from the old-server to the new-server did not fix the issue.  Even with the new server name in the file name, the inserted message fails to appear in client Mail applications.
Within the file their is header information that still references the old machine. I'd like to not have to change the email files, because this will violate the integrity of the message. Also, this might take a lot of time or incur risks associated with poor automated processing. The header information should not be referenced by Dovecot, because the wiki page describing MailDir notes that neither Dovecot nor Dovecot's implementation of IMAP refers to the messages header information when moving and serving these mail files.
Unlike when using mbox as mailbox format, where mail headers (for example Status, X-UID, etc.) are used to determine and store meta-data, the mail headers within maildir files are (usually) notused for this purpose by dovecot; neither when mails are created/moved/etc. via IMAP nor when maildirs are placed (e.g. copied or moved in the filesystem) in a mail location (and then "imported" by dovecot). Therefore, it is (usually) not necessary, to strip any such mail headers at the MTA, MDA or LDA (as it is recommended with mbox).
This paragraph leads me to believe that after the mail box is identified that the content of the file becomes irrelevant to the system which manages. This suggests that we should be able to inject messages into a mailbox and have the system serve them as though they had belonged in that mailbox all along. Yet I have not found a way to do this.