There are four approaches for migrating classic content to blocks. But before we get into that, let’s first look at the required preparation work.
Start a content audit
It’s typical for websites to amass content over the years.
Some of this content produces outcomes, and so you should keep it. Other content does not bring any results. Worse yet, it might even hurt your search engine rankings.
So before you do any work on the content, make sure to keep only relevant pages. Discard and redirect, or 401 any other pages.
With that said, let’s look at the first migration strategy.
Option 1: Do nothing
Let’s start off with the solution taking the least amount of effort: keeping the content as is.
This is a good solution because it’s low cost. All you need to do is disable the Classic Editor, and that’s it.
This approach works because of the classic block. It allows you to edit classic content using the block editor. You can even use the classic block for new content.
The idea is of course to migrate content over to blocks as time goes on. This is a manual process, done by users converting the content to blocks in the editor.
But this process will be gradual, and only when needed. Because whenever authors change content, they’ll double-check it on the frontend. So this approach is very low risk.
If you want to avoid users keeping classic content, you can use Convert to Blocks. It transforms classic content to blocks when a user opens a post in the editor.
Option 2: Bulk migrate
This solution is the complete opposite to the previous one. Because here you use a plugin to convert all classic content to blocks. I recommend Bulk Block Converter.
The biggest risk here is that malformed classic content doesn’t result in a proper set of blocks. So there needs to be follow up checks to verify key content.
I did one such migration on a client project. There were about 120.000 posts, written over years by various authors. In short the content was a mess.
The bulk conversion was a way to have a clean slate. We configured the block editor to a very paired down experience. So authors couldn’t do all the crazy things they did with the classic editor. And then we converted content to blocks, and removed anything that broke.
This is a valid strategy, but you need to double check the converted pages. The more content you have, and the less you check, the more you need to be okay with having a bit of malformed content.
Option 3: Cut off point
Here we force authors to use blocks for new content. While keeping the classic editor around for old content.
For this we look at the latest post published with the classic editor. Let’s say it has an ID of 15634. This ID will mark the cut off point for classic content.
Meaning that the next time that a user creates a new post, they can only access the block editor. Any post with ID 15634 or lower (the cut off point) gets the classic editor.
The old content can stay classic forever. Or you can convert it manually when needed.
This is a good strategy for something like a news site. For this type of site, the recent content gets lots of traffic. Older content way less. So you are optimizing the new content, while keeping old content accessible.
Option 4: Offer the choice between classic and blocks
This approach gives authors the choice how to edit classic content. They can either edit it in the classic editor, or the block editor.
This way editors can continue editing old content as usual. They can create new content using blocks. And they can manually convert classic content to blocks.
I implemented this approach on a well know fact checking site. A fact check is an evergreen piece of content. These posts can get smaller edits, to fix typos or grammatical errors. Or they can get a rewrite. Depending on the scenario, editors can choose the classic, or the block editor.
