@Edward Hasbrouck, similar to you, i had issues there, and particularly in the archives. My issue is two-fold, but is indirectly related to the migrator, and an edge-case, nevertheless demonstrates the importance of plesk to be able to migrate all its stuff, lest a subscriber be locked into an old server. .

Im currently in the middle of debugging a mailman issue on a server that is only still active because of 2 client domains that have active mailman lists. The server is more than EOL(think of malfunctioning plesk 11 freshly moved to onyx, centos6,m1/pre nitro).

We recently experienced a mailman issue that had a domains mailing list locked up for a client, for some time. We eventually had to take this to plesk support, where they pulled us through. This wouldn't have been necessary if the mailing lists were successfully migrated with the domain. This was causing real business interruption.

I want to say, im working on migration documentation on our end, e.g. the parts that the migration doesn't cover, and the biggest pain point is just learning mailman, which is in python, and what you can do with it. The mailman bin scripts do have man files or help entry's, however theres not a lot of example documentation, so if you run them with the wrong parameters on a production server, you run the risk of bringing down other clients lists, etc.. .

I can also say, its carefully documented on mailman documentation that creating lists through mailman wont automatically sync in plesk, so for e.g. you cant manage your list through plesk if you did create it via mailman. e.g. if you wanted to add a user to the list you cant do it through the plesk panel, you need to log into the mailman administrator and do it. Mailman recommends this, and to not use plesk panel to create lists at all. This may be some good advice.

Also, if your domains are hosted for clients that don't have plesk access, they will want to manage their lists via mailman, as opposed to the plesk panel. You can only adjust a small % of mailman settings from plesk panel. Eventually you still need to log into mailman and fine tune it. I cant foresee giving clients instructions for both plesk and mailman, and having to create special access for clients to the plesk panel for them to manage their lists, which aren't fully synced if a list was created in mailman alone by another employee, etc..

The best thing for me atleast is to use mailman to create the lists, otherwise to keep the plesk setup as default as possible, where it differs in the mailman documentation, specifically in the config areas. This is because if you need plesk support, they will need a default setup to support it.

If we had a plugin that managed this, we can now migrate, terminate our old servers, and hopefully new development will lead the availability for plesk to sync itself to mailman in full to where you can do all mailman maintenance in mailman itself, and plesk will faithfully reflect the changes, as a viewer. If Plesk does end up deciding to add back in management functionality into mailman, i hope its after they get plesk properly syncing to mailman, so that its operating on it in full, instead of creating a tangent.

In the end, ideally, you would be able to manage all lists in mailman (priority 1), and plesk (priority 2). As far as the migrator, ideally this would just work, to where the archives are immediately available in the new migrated domain, as well as working lists.

I dont think Gnu Mailman is going anywhere. These types of binaries are goldmines to the industry, and are much needed in the open source world. If its not done on Plesk it would be done elsewhere, CPanel for instance.

So for now, were probably going to create the lists through mailman, but when things break out of the blues its straight to mailman python commands. When those cant straighten things out, its straight to plesk support with no other recourse....

If a migration module/extension is completed, we can finally get the domain off the old failing server which will probably prevent these problems for the most part.

Mailman is working fine on our newer servers as far as stability. If we can just get the migrator to work, we can have lists installed and archives auto populated.

Regards.....

Mailman is, for me, an essential component of my Plesk server. The difficulty of manually migrating mailman settings for all lists (I had to do it once before, and it was poorly documented and difficult to do without spamming list subscribers unintentionally due to reset to default settings and change of announcement lists to discussion lists) is a major obstacle to migrating from CentOS 6 to a newer underlying OS for my Plesk server. For me, migrating mailing list *settings* is more important than migrating archives. But all should be included in a Plesk migration. And, as others have noted, in the meantime, there should be a clear warning that these won't be migrated.

Additionally, until this functionality is added to Plesk, the Migration Manager should display a warning, indicating what will not be transferred, when there are mailing lists to be transferred. Otherwise, administrators and end users are surprised when a private mailing list, all of a sudden, becomes public, because the advanced settings were not transferred.

Great proposal

Currently it is not possible to migrate Mailman archives using Plesk Migrator Manager. It would be great extension to Plesk Migrator to make it possible to transfer Mailman Archives too.