After more than eleven years on BlogEngine.NET, ridilabs.net now runs on WordPress. The decision was not an easy one. BlogEngine served me well through hundreds of posts, but the hosting bill no longer matched what the site actually is: a personal engineering journal. Cutting that cost meant moving to a platform with cheaper, more commoditized hosting, and WordPress was the obvious destination.
Three constraints I set before touching anything
A migration without constraints turns into a redesign, and a redesign turns into six months of unfinished work. So I fixed three non negotiables up front:
- Keep the Microsoft flavored, Metro style look. The visual identity of the blog is part of what it is about, so the new theme had to carry it over rather than replace it.
- Migrate all the old content, not a curated subset. Eleven years of posts, categories, and comments move as one body. Nothing gets quietly dropped.
- Stay on ridilabs.net. The domain is the permanent address. Everything else underneath it is an implementation detail.
The real problem: BlogML is not WXR
BlogEngine.NET exports to BlogML, an XML format from the era when every blog engine shipped its own interchange schema. WordPress imports WXR, its own flavor of RSS with custom namespaces. The two describe roughly the same things, posts, authors, categories, comments, publication dates, but they disagree on almost every detail: how content is wrapped, how slugs are expressed, how a comment is attached to its parent, and how post status is encoded.
There is no maintained bridge between the two that survived the last decade. Hand editing an export with that much history in it was never realistic, so the migration became a small software project instead of a copy and paste exercise.
Building the converter
I wrote a Visual Studio project that reads a BlogML export and emits a WordPress WXR file ready for the standard WordPress importer. It is on GitHub and free to use: ridiferd/blogmltowrx.
The shape of the tool is simple. Parse the BlogML document, project each entity onto its WXR equivalent, then serialize with the namespaces the importer expects. The work that actually takes time is the mapping detail: preserving slugs so old URLs stay meaningful, keeping publication dates intact so the archive still reads chronologically, attaching comments to the right post, and translating category and tag structures that the two systems model differently.
The whole migration took about four hours. Two things made that number possible. First, vibe coding: I described the mapping I wanted and iterated on the generated converter rather than writing every XML writer by hand, which turned a weekend of plumbing into an afternoon of review. Second, the theme work was template composition rather than CSS written from zero. Neither replaced the engineering judgment about what a correct mapping looks like, but both removed the mechanical typing around it.
What this means if you read here
The address is unchanged, the archive is intact, and the look is familiar. Some deep links from the BlogEngine era may resolve differently, so if you hit something broken, tell me and I will map it. The feed and the reading experience should otherwise feel like the same site on a quieter, cheaper foundation.
If you are doing the same move
Export first and inspect the BlogML by hand before you write anything, because the edge cases in your own archive are the ones that will cost you time. Run the import into a throwaway WordPress instance before you point it at production. Verify slugs, dates, and comment counts against the source rather than trusting that the importer reported success. And treat the converter as disposable code with one job: it only has to be correct once, on your data.
The repository is open, so if you are still on BlogEngine.NET and looking at the same hosting invoice I was, feel free to fork it.
Leave a Reply