After six months of paternity leave, I returned in January to do a rotation with the team migrating hundreds of millions of Tumblr blogs to WordPress.com.
I hadn’t touched code in six months. Had never worked on Tumblr. And I’d spent the last five years in engineering leadership.
The prompt I got? Do a speed run project to get from zero to one site migrated… in 2 weeks.
So yea. I laughed. Then panicked.
Fortunately, I was joining a team that had already done good foundational work. The challenge was just to get something across the finish line—fast.
Taking Stock
At first I got caught up in everything that might go wrong:
- How do we migrate users?
- What legal implications, such as terms of service, are involved?
- How do we handle content moderation?
- What about the differences in how Tumblr and WordPress store and render content?
- How will we hydrate Tumblr’s APIs from this new data source?
But, the tight timeline was a gift. Because it forced me to realize that none of this was essential for migrating a single site.
We picked a Tumblr-owned blog with only one user: staff.tumblr.com. To handle content format differences, we decided to just export and migrate rendered HTML. To keep Tumblr’s APIs working, we double-wrote to both Tumblr and the migrated blog on WordPress.com.
With that framing in place, we moved on to just the things that were absolutely necessary:
- Theme
- Content
- Interactivity
Moving Forward
For each of these, I then approached them with the minimal set of requirements.
For the theme, I went to staff.tumblr.com, viewed the source, copied it into index.php, and added a quick style.css. And committed that to WordPress.com. 😂
Dirty. But it worked.
The team had already done some work exporting rendered HTML from Tumblr. We took that export and piped it into WordPress.com using WP-CLI. Now we had something to look at.
Then I started cutting up index.php into real templates and added the WordPress loop. At that point, we had a mostly working theme that we could iterate on.
For interactivity, we stepped through this one-by-one:
- Reblogging: Tumblr stores references. WordPress.com duplicates. We deferred solving this.
- Likes, reblogs, embeds: Tumblr uses iFrames, so we copied them.
- Archive pages: We quickly built a template that mimicked Tumblr production.
- Notes: We added a new endpoint on Tumblr to fetch notes, cached the result, and skipped the complexity of partial migrations.
With this approach, we were able to migrate a single site in about 2.5 weeks.
Iterating Through Weirdness
That initial migration wasn’t perfect—but it gave the team what we needed to build momentum. From there, we kept scaling and refining.
Of course, weird things came up as we iterated. 🫠 But the team stuck with it and scaled the approach from that one messy win.
Migrations were slow. As we added more content, we uncovered new edge cases—and had to migrate even more data to handle them.
Functionality needed to be rewritten as we considered more edge cases.
At times, this approach felt slower than designing the perfect system up front.
Maybe it was.
But it was real progress. And that mattered more.
The lesson?
When you’re working on something massive, don’t try to solve it all at once.
Solve one piece. Then the next. Then the next. Move fast. Build momentum.
How do you eat an elephant?
One bite at a time.
Leave a Reply