"Of course" this is just the "high-level", but basic outline of execution of list migration procedure (per list) goes about like this (this is actual outline I used to walk myself through it to be reasonably sure I didn't miss a step or do significantly sub-optimal ordering of steps, the ... dump subscribers and options ... and set member options steps are the ones using the written perl WWW::Mechanize programs):
old list: save old descriptions: description info subject_prefix save start time and dump subscrbers and options (and end time is mtime) update BALUG web page (migrating) send out "last" posting to "read-only": "emergency" moderation update description on list (read-only, etc.) new list/host: create new list: add aliases before notifying list admin(s) set description: short text set tag (from initial cap) set description: web page check/set options (notably DMARC) stop exim (MTA) mass subscribe set member options start exim (MTA) update BALUG web page (new link(s)) first posting to new list
So, ... first list migration seemed go quite smoothly enough. All looks good in logs, etc. (mail generally making it out fine, not seeing any problems with mail coming in, etc.).
General plan for the remaining lists is to do a migration about every 2 or 3 days (we go up significantly in magnitude of members on each successive list) - giving a reasonable bit of time between in case any issues are detected at all.
After that, proceeding with the further steps to get us off of DreamHost.com - notably requesting the raw email archives (I figure they're more likely to do it, and less likely to screw it up, if we just ask 'em for all 3 lists archive files at the same time - and once each of those lists has effectively transitioned to "read-only" mode on ye olde DreamHost.com hosting). That and some other quite small bits to check and be sure are finally and fully sucked out'a DreamHost ... then we're nearly done (then come major DNS changes, etc. - but that becomes fully independent of DreamHost.com).
Anyway, hoping/expecting it'll all be wrapped up within this month. Optimistically, maybe even by about mid-month or so or possibly even bit before that. We'll see. Biggest variable timing bit is how fast can we get DreamHost.Com to respond once we put in our request (and will they get it correct and not screw it up the first time around).
Also, temp.balug.org and robots.txt - I've got that set presently to deny all bots. Will adjust that after archives are merge and brought over, and after lists.balug.org moves off of DreamHost.com and to the new host. In the meantime, I think bots not finding archive contents for a modest while - and especially at a temporary domain location anyway - isn't a particularly big deal. Let me know if you think otherwise. :-) (certainly a debatable point).
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: (BALUG) list migration procedure - high-level Date: Wed, 02 Aug 2017 05:21:34 -0700
"Of course" this is just the "high-level", but basic outline of execution of list migration procedure (per list) goes about like this (this is actual outline I used to walk myself through it to be reasonably sure I didn't miss a step or do significantly sub-optimal ordering of steps, the ... dump subscribers and options ... and set member options steps are the ones using the written perl WWW::Mechanize programs):
old list: save old descriptions: description info subject_prefix save start time and dump subscrbers and options (and end time is mtime) update BALUG web page (migrating) send out "last" posting to "read-only": "emergency" moderation update description on list (read-only, etc.) new list/host: create new list: add aliases before notifying list admin(s) set description: short text set tag (from initial cap) set description: web page check/set options (notably DMARC) stop exim (MTA) mass subscribe set member options start exim (MTA) update BALUG web page (new link(s)) first posting to new list