My blog is older than most of the tools I use to run it. The oldest posts started life on LiveJournal sometime in the early 2000s, got dragged thro...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I've been planning on doing the same with my DEV posts for a while, because nothing lasts forever. DEV's API lets you get the posts as markdown inside JSON, which is great, but a few of the embeds will need changing to work independently and I'll need to manually exclude certain posts which aren't particularly relevant in any other context, so I'll probably end up doing it all by hand anyway!
Managing a monorepo with multiple Astro sites often leads to tricky dependency resolution and shared component syncing. I have found that keeping the crossposting pipeline isolated from the main site builds prevents CI bottlenecks when pushing large amounts of historical content. It is also fascinating how you handle the markdown quirks and frontmatter mismatches between the local Astro setup and the dev.to parser. Do you use a custom AST transformer for the sync tool or just rely on regex for the crossposting pipeline?
that yaml unquoted timestamp edge case breaking the ruby parser on dev.to's backend is an elite catch. watch out for the fuse.js deep-index payload as transcripts scale though, client-side fetch might bottleneck later. clean setup.
keeping old URLs intact is what makes a platform migration actually succeed. most people skip it and silently lose years of backlinks.
Really impressive monorepo evolution — especially how you preserved historical integrity (full git history across all three systems) instead of collapsing everything into a “fresh start” commit.
What stands out most is the architectural clarity that emerged from consolidation: content, speaking assets, and tooling all becoming first-class, independently reasoned systems inside a single boundary rather than fragmented repos stitched together operationally.
I also like the strong emphasis on ownership vs direction in the dev.to sync model — that constraint alone removes a huge class of sync edge cases and phantom-diff problems that usually make bidirectional pipelines brittle.
The crosspost flow being deterministic and PR-driven is a particularly clean design choice. It keeps publish semantics explicit instead of implicit, which is usually where these systems start to rot.
Overall, this reads less like a migration and more like a long-term systems refactor done with discipline.
Ngl, this explains why you've been writing for over 20 years... I've only been on dev.to a short while, but I'm enjoying it, especially making posts, like the new game to LLM series, I thought I was optimizing, hosting and open sourcing the games on git, with a monorepo for the cloudrun deployment, but I never gave much thought to a repo for the posts, they're just scattered across my laptop in each project's folder. Also dont have a fixed workflow for creating posts, let alone cross-posting to multiple sites. So I think I'm gunna have to read this 1 through again over the weekend and start organizing my stuff a bit better...
Thank you for opening my eyes on this 1, I built IDEs and OS's, but I never considered organizing my posts.
This is a great read. I could relate to the timestamp edge case - I had the same issue in my current stack (obsidian -> mkdocs-material -> github -> cloudflare-pages) I've been jumping between writing on a dedicated platform (like medium) and then wanting to have my own website, and then jumping back... you know the drill. Reading your post assures me I'm (kind of) in the right mindset (although my reasoning for switching platforms / frameworks might be silly), I like how you eventually landed on your current setup. This is amazing, and almost comforting to know there is an "preferable state" to my confusion.
The line I keep coming back to is "real, verifiable ancestry, not just the files are here now, trust me," because it is the same instinct that shows up in your sync design as "ownership, not direction." Both are the same move: make the source of truth an explicit, checkable fact instead of something you assert and hope holds. git subtree gives you provenance you can walk, and the id field gives you a declared owner. Most people would have done a flat copy and a cron job and called it sync. Naming ownership as a first-class thing is the tasteful call.
One edge on the ownership model, in the spirit of the rest of it. "Git-owned once it has an id" is single-writer by marker, and a marker records who should write, not a lock that stops the other side from writing. The happy path is clean: draft on dev.to, publish, git takes over. The bite is the day you fix a typo directly in dev.to's still-live editor on an already-published post. Now both sides own it with divergent bodies, and the atomic canonical_url rewrite does not catch it because the divergence is in the content, not the metadata. Cheap guard that fits your bar: on each import or publish, compare a hash of the body against the last-synced hash, and if the non-owning side changed since the id was written, stop and flag instead of silently picking a winner. It turns "which copy is real" from a thing you find out later into a thing the tool refuses to guess.
Great idea!!
Hi Matt, I saw your post about managing content across multiple platforms and thought of Clypify, a tool that can help you streamline your content workflow. We can help you auto-publish to WordPress and Medium, saving you time and effort. Free plan at clypify.com — no card needed.
Thank you for sharing such an excellent post. I really enjoyed reading it.
I’m a Python Full-Stack Engineer with over 10 years of experience designing and building scalable software solutions for clients across a variety of industries. Along the way, I’ve learned that successful projects depend not only on strong technical execution but also on creating real business value.
With my recent contract completed, I’m exploring new opportunities to collaborate with professionals who value innovation, practical problem-solving, and long-term partnerships. I enjoy discussing ideas that combine technical excellence with sound business strategy, creating outcomes that benefit everyone involved.
I believe every connection has the potential to become something meaningful. If you're interested in exchanging ideas, exploring opportunities, or simply connecting with someone who enjoys building impactful technology, I'd be happy to hear from you.
Wishing you success in your future endeavors, and I look forward to connecting.