Chatting with the notificaiton folks on this point - unfortunately there's not a lot of good options for suppressing notification events here during import - currently the MTA just processes messages from the COBRAS restore as normal inbound messages - the header has the "seen" tag and original send dates which are applied but AFTER the new message event is processed when the message gets added to the mailstore database (which generates all the counters and other update events needed down the road) - thus any active notification device will be triggered even though the message is almost immediately marked "seen" - train's left the station by that point.
Ideally the MTA would provide special header tags for "supress notification" or the like but this is obviously new feature work that's not trivial.
It'd be possible for COBRAS to forcibly disable all notification devices for a user but the timing is very tricky - you can't just disable them, toss the messages into the MTA and then enable them again since the MTA may process messages in batch (particuarly if it's busy during a large import) and when you turn the devices back on you may do it in front of the actual message insertion - leaving you in the same boat. Plus the disable, send, wait, enable process is pretty ugly stuff in general. To do it right you'd need to create a table of all notifcation devices and owners that had been disabled, disable them all during user import/creation, import all messages for all users, wait till the MTA reports an empty queue and then when you're all done go back and enable all devices again - that'd give you the best chance - but that's a pretty sizable pile of work.
I can eyeball it a bit the end of the week to see if it's less hairy than I'm imagining but I'm doubting it'll be something that can be done safely in a reasonable timeframe (assuming you are looking to migrate sooner rather than later). This is something that would take some testing cycles for sure.
