That's it, I'm pushed to the limit, worn out scraping comment shite and double double double comments, most stories can't get through the whole post processesing, several stories just won't generate at all, and for what? Why do I put up with all this?mothers, tell your children
not to do as I have done
not to spend their life in sin and misery ...
...locked into the house of no-escape proprietary methods. The whole reason why I haven't switched long time ago is simple to state, complex to enumerate, it's because I foolishly let my data get tangled in non-portable proprietary methods, and then let my data grow so large the legacy inertia was too massive to budge.

Just so you won't make the same mistakes, here's some of where I went so wrong, and what I'm going to need to do about it ... h3. crashing in the same car

Goethe said we learn nothing from history because the situation always seems different ...

The thing is, it seems like such a good idea at the time. You read the docs, try the demos, play with the tiger's tail ... just this once, y'know, it will be ok ... Like, you just do this and that and send ten dollars to the Church of the Sacred Bleeding Heart of Jesus (located somewhere in Los Angeles, California) and next week they'll say your prayer on the radio and all your dreams will come true.

What could possibly go wrong?

1. I used MT, being suckered in by the ease of setup without realizing that it wouldn't scale; now that I have fifteen hundred items and 1300 comments in this blog, it's creaking under the stress (although the other far smaller blogs under this same account are doing just fine)
2. because the only standard MT adheres to is the Trott standard, there's no recourse to other pathways. I'm dependent on them to solve problems in performance, problems in usability, and particularly the problem of the gaping hole they'd left for comment spam. Jay's blacklist is creaking under the load of 900 (optimized) perl regexen, and still so much slips through that I no longer use the one-shot delete, I just open the add page from my bookmarks and inject the patterns in batch -- did I mention MT is unable to regenerate several pages?
3. final blow: just as convenience and glam lured me into MT, I fell into the trap of Textile, the short-hand HTML notation. In retrospect, it's not the 'wiki notation' I'd hoped for and demands real HTML expertise to predict where it will fail and correct when it does, so nobody but me uses it, and I already know HTML; what's worse MT's Textile is subtly different from others, but now I have 1500 stories that need not only to be converted from one datatable set to another, but each must also be filtered to expand (or translate) these codes.

Oh, dear, where to begin, where to begin.

Jordan is a Hard Road

I naturally want to retain the old items and the relations between them, so there's going to be URL translations for items, comments, trackbacks and images. I like to keep stats (why I don't know) so there's a need to keep unique URL paths for each blog, and each of the blogs on this site serves very distince audiences, so the data, templates and stylesheets need to be distinct. Where to begin.

I've started with James Seng's MT to Drupal Migration Tool, a Swiss Army Knife that tries to preserve as much as possible through the transition. This will likely be useful regardless, but the first apparent detail is the binding of this kit to his specialized (forked) Drupal 4 Bloggers which, while it adds many features I wouldn't mind having in my core Drupal server, it is likely different enough to break things irreparably.

And then there's the paradigm shift. Drupal does do blogs, but that's not really it's designed purpose. As David Nunez put it

I think the more difficult part of adoption is the paradigm violence that must occur for the typical blogger to accept Drupal. It is fundamentally different than most blogging software. It's a superset of blogging. It's blogging on steroids. Instead of "I'll publish a stream of information every day," it's "I'll be fortifying my intricate web of information every day."

This will probably be a Good Thing for a revamped Prognosticator and may also be a boon to our band page, but I'm not quite sure how this will fit for a pretty stock-and-trade diary-journal blog like KeeMay, and I already have some problems partitioning my own information space between what I put here vs what I put here, here, here and here

I've started an off-line sandbox install of D4B just to see how far it will go. One key advantage of the Migration Tool is the direct MySQL to MySQL translation of your content; after several years, the managing and down/up/downloading dump files from TeledyN was not something I was cherishing. Nonetheless, it's going to be a long hard slog that could have been prevented.

So take a tip from a war-worn old soldier: If they offer you any technology, I don't care how snazzy it is or who endorses it or whether that's for weblogs or webservices or file formats or storage media and DRM, don't you dare sign on until you've seen the exit strategy.